Where do Enterprise Architecture Management Suite (EAMS) tools fall short and where do they shine? I’d like to share with you some of the takeaways I gleaned from reading a recent report from Forrester Research entitled, “The Forrester Wave: Enterprise Architecture Management Suites, Q2 2011,” which evaluates 10 EAMS vendors.

Spoiler alert: Collaboration isn’t a strong spot.

Let’s focus on the shine first. On many levels, EAMS tools are amped-up enterprise architecture (EA) tools. But there’s much more to them, as well. A good comparison might be to think of moving from a network monitoring tool to an enterprise management system that is capable of monitoring and managing networks, systems and applications all together. As for the EAMS tools, Forrester points to the addition of new IT planning and governance, risk and compliance capabilities, as part of the evolution,  as well as the ability to handle not only EA data, processes and organizational models but also EA budgets, strategies, risk and other information categories. The tools also include new capabilities such as automated data-quality checking and advanced analytics, including system or throughput simulations, according to Forrester.

Even more interesting: The research consultancy proposes that an EAMS fits squarely in the center of IT management, giving the idea some legitimacy by noting that EAMS solutions are starting to support non-EA group partners. For example, they are becoming go-to suites for CIOs, project managers, development and operations managers, risk managers, IT procurement and others. Another point: EAMS tool repositories can become central stores of strategic information about both IT and the business.

I won’t go into the specifics of each of the 10 tools # listed# in the report. (Forrester clients can access the report here if you’d like to explore that in greater depth, and others can read the executive summary.) But suffice it to say that the analyst firm sees these as the leaders of the pack. While they all impress in some way, customers still find themselves adopting more than one EAMS to fill some gaps, however.

And here’s a gap that none completely fill: Enhancing collaboration among multiple parties. These include stakeholders that enterprise architects must work with in planning, modeling, designing and implementing an architecture for the organization. That’s very surprising. We’ve got to go beyond ineffective collaboration methods, such as one recently described to me: Using virtual whiteboards to draw and capture some of the enterprise architects’ work. Moreover, I have been told by enterprise architects that many teams also still put all their knowledge into old-fashioned word processing documents … pages and pages of them!

Features such as wikis, instant collaboration, discussion forums, tagging and those virtual whiteboards are included as part of some of the toolsets, but they’re not really enough to help EA teams maintain quality content in a sustainable manner, according to Forrester. That said, the analyst firm sees some signs of positive change, with a few vendors experimenting with social computing capabilities to go beyond the old check-in/check-out document collaboration found in most repositories and knowledge management applications.

But vendors shouldn’t take all the blame. Even when collaborative functions and tools are written into apps,suites and systems, there’s a good chance that half of them are never used, a conclusion I’ve come to based on discussions I’ve had with enterprise architects. That’s especially true for busy enterprise architects, many of whom have risen from the solitary ranks of software programming. Forrester also adds that, “EA stakeholders are not naturally inclined to use an EA tool to share their knowledge for the benefit of only enterprise architects.” Forrester recommends that vendors “add metrics to measure value and reward contributors to instigate a virtuous circle — and, consequently, sustainability.”

Clearly, it’s time for collaboration to play a greater role in EA. It must support the enterprise goals, business processes and information, organizational structure and culture, and IT systems and applications. And there are a lot of stakeholders who need to be in the loop:  CIOs, IT managers, information security managers, risk analysts, business managers, IT developers, even CTOs, CFOs and yes, CEOs. Ensuring that all the components and the stakeholders are a part of the EA process takes nothing less than bona fide collaboration — across the organization, within the process, and embedded in the EA tools used along the way.

Here at Smart Architect, we’ve been exploring the intersection of enterprise architecture with the cloud from a number of perspectives, including in a blog I wrote here, “Cloud Computing and Your Very Relevant Enterprise Architecture.” It’s a topic on the minds of many, including Erik van Ommeren, who has co-authored with Martin van den Berg Seize the Cloud: A Manager’s Guide to Success with Cloud Computing, published by technology services provider Sogeti.

I recently had an opportunity to speak with Ommeren, who is Director of Innovation at Vision Inspiration Navigation Trends, the Global Research Institute for the Analysis of New Technology at Sogeti. We spoke about the influence enterprise architects have in the age of the cloud, which the book covers in great depth.

The disconnect that still exists between IT and the business in many organizations — and which creates problems in data and process integration and maintenance when business units sign up for cloud services without reference to IT — actually can be an opportunity for enterprise architects, Ommeren believes. Architects can exploit their position as intermediaries who try to coordinate long-term business and IT dimensions while supporting the short-term projects the business desires. These may include securing new marketing services or storage or any of the many options that the cloud makes so darn tantalizing and makes seem so darn easy (at least until the repercussions of ignoring corporate IT set in).

“There really is a role [for architects] to start up and engage in this business-IT dialogue,” Ommeren says. From the start, “the enterprise architect can say: We need to do this, we have thought of this relevant to the long-term, and let’s also exploit short-term opportunities, to see how they match.” There’s opportunity and even fun to be had in creatively thinking of conceptual services that should be made available to the organization — “to do the analysis of what the organization really is and does and try to describe it in such a way that it is fairly stable over time vs. being tied to a specific technology,” Ommeren posits.

In other words, be the broker who knows what services are available and who can compare internal and external available options, and their cost and benefits, Ommeren advises. “That is the space where enterprise architecture can be of value in painting and maintaining a portfolio, and setting the guidelines for selecting and using technology,” he says. Tune into helping set business-relevant boundaries, rules and regulations — e.g., let the business choose any service it wants as long as the cloud provider promises to keep data in the country and the security team gives a thumbs-up — rather than spending your energies on preparing blueprints that are quickly outdated. “Processes and principles should have priority over blueprints,” he says.

It’s more important to be part of the decision-making process than the documentation one, anyway — even – and especially -- when that might involve making exceptions to a rule in order to embrace a cloud service that will let your company be the first to gain access to a new market, for instance. That gives the enterprise architect both a forum in which to say that those exceptions must be revisited — either to bring the exceptions into the fold as is or put such solutions back under architecture’s purview — and an empowered role to make sure that happens.

As a basis for enterprise architecture in the cloud era, Ommeren and his co-author emphasize the idea of “Dynamic Architecture,” which incorporates best practices for strategic business dialogue, for architecture services as support processes, and for development with or without architecture standards (as when there’s a business case for exceptions). “All happens under the architecture — even exceptions are part of the architecture process,” he says. “The other part of the thinking is that architecture provides true services to all those involved. Architects are not the police, but they’re there to inform, help and advance.”

With the cloud proliferating in today’s enterprise, it couldn’t hurt to explore further what Ommeren and van den Berg have to say on the subject, especially since Seize the Cloud can be downloaded as a free PDF. If you have a chance to read it, we’d love to know what you think about the authors’ insights.

Is it possible to replace a living, breathing enterprise architect with a do-it-yourself architecture kit? How about with blueprints, formulas or other design templates?

Companies have been known to take stabs at it, and not without success. The Java BluePrints series of documents in the 1990s enabled bare bones, agile teams at small start-ups to build the online economy. Today, Oracle maintains them, while Microsoft offers its own set of blueprints, the Software Factory methodology, whose concept is to apply working patterns of software architecture, development, testing and release to sets of problems that cookie-cutter development teams can solve. CA Technologies offers blue-print papers and videos in the areas of data modeling and architecture, as well as virtualization and the cloud. And other vendors also have their own approaches.

These are all useful goodies for a number of reasons. But their usefulness increases, I believe, when an enterprise architect is onboard to oversee efforts to deploy these tools to automate software architecture and design processes. What the architect brings to the picture is everything from an understanding of time to market, cost and ROI considerations, to enterprisewide skill sets and global deployment experience. And let’s not forget what enterprise architects know about security, creating flexibility for tomorrow's desktops and mobile devices, and accommodating the growing desire to be green (e.g., energy and heat efficiency, recycling and so on). This all leads me to believe that a do-it-yourself architecture strategy probably won't work for all cases, all problems and all companies.

Patterns: The Enterprise Architect's Ornaments

One important thing that do-it-yourself kits or blueprints may not always account for are architectural patterns. If an enterprise architect wore medals, they would take the form of architectural patterns he or she helped define. An architecture pattern is a schema for a software system and its overall structure, whereas a design pattern is a more detailed, specific refinement that outlines deeper relationships between components. The Open Group has been overseeing work on standards for architecture patterns as part of The Open Group Architecture Framework initiative. The Object Management Group (OMG) has also done some work here. Together, they’ve defined patterns for service-oriented architecture, event-driven architecture, model-driven architecture, resource-oriented architecture, directory services, security, transactions and the list goes on.

According to the Open Group, patterns are a way of putting the building blocks of architecture into context so that they can be reused and applied in the right ways. For instance, patterns should clearly define how and when to use the building blocks, the trade-offs involved, and other related caveats or prerequisites. For each pattern, it’s recommended that you specify at least the following:

• The problem: when to apply the pattern
• Context: preconditions for the pattern, and other assumptions (i.e., multi-core servers)
• Constraints: considerations in terms of security, cost, efficiency, performance, bandwidth, power consumption, openness, portability and so on, as well as how trade-offs are made between them
• Proposed solution: in terms of implementation and deployment
• Example: where possible, provide a real-world example of the pattern at work
• Related patterns: often patterns build on, or work in conjunction with, other patterns
• Alternatives: a single solution is rarely the only solution; list alternatives and when to choose one over the other.

Some organizations have made quite a bit of progress defining architectural patterns that apply to specific problem domains. For example, the Open Geospatial Consortium , in conjunction with the OMG, has defined patterns that actually apply to a broader set of problems. These include patterns for geo-data storage and access, generic SOA and Web services, interoperability through data standards, data-binding models and so on. Martin Fowler’s book, Analysis Patterns: Reusable Object Models, and Fowler’s site are also good resources for more information on the subject.

Software Architecture with Math

If we could use mathematics to prove the value of the architectural patterns that enterprise architects define before the coding process begins, the case for their oversight of do-it-yourself tools gets even stronger. Other engineering disciplines, after all, use math extensively during the design phase, including electrical engineering, aeronautical engineering, mechanical engineering and so on. It’s the math that gives engineers like my father the confidence that his designs will fly — literally! Beyond basic math used to calculate memory requirements, server scale and database sizes, I’m not aware of anyone using math extensively in practice to define or at least prove their enterprise architectures, though. So if you’re actually doing this, or know anyone who is, I’d love to hear about it.

But I digress. What it comes down to is this question: Even if you could always rely solely on kits and patterns to the exclusion of enterprise architects, should you always? I think not — or at least, not if you care about customer satisfaction. It takes careful consideration to craft solutions that are not only profitable, but also make our customers continually happy (which, by the way, goes a long way toward driving profits).

So I think our jobs are still safe, and that we should instead embrace patterns and measurable processes. In fact, being part of the continuing contribution to the definition of patterns and other verification processes can help ensure our long-term success.

Any organization that’s been around for any length of time — be it 10 years or 10 decades — inevitably confronts change of some fairly significant magnitude. Such is the situation at the IT-ISAC (Information Technology - Information Sharing and Analysis Center), a nonprofit corporation that since 2001 has focused on cyber vulnerability management and on cooperating with national and homeland security efforts to strengthen critical IT infrastructure.

Having had the honor of both belonging to this group since its inception and more recently of being elected its president, I now also have the privilege of helping to reboot IT-ISAC for the next decade. That’s a job that will call on enterprise architecture skill sets as much it will on security and communications expertise.

Let me explain a little about “what” is changing and the “why” behind it. I’ll start with the latter. It remains important, of course, to understand and address product vulnerabilities. But that’s also a difficult prospect at a cross-organizational collaborative level, considering the risks of disclosure before solutions are available. Not only that, but product vulnerability is just one concern in a world of threats that also includes malware, criminal activity, exploits and other attacks on internal IT environments and the customers they support. Changes in IT service delivery and IT service consumption, including a growing array of mobilized apps, add to corporate risk profiles. And, as cloud computing grows and creates infrastructure vendors from some unexpected sources, so too do the opportunities for threats that may have an impact on these services and their users.

Second, while national infrastructure security remains a focus for IT-ISAC, today organizations are interconnected by their reliance on technologies without regard to national borders. We can’t ignore that.

In sum, the threat has become more complex while vulnerability disclosure and management processes have become more mature. This is propelling the IT-ISAC to refocus on threats to the cyber infrastructure and individual networks:

• Threats to one entity generally are threats to all, and the net of discussion must widen to encompass more participants in individual companies and more international companies with operations across the globe. To address this, we are creating specific communities of interest from the member population at large so that they can more rapidly share and analyze pertinent threats and act to contain them.
• A more globally encompassing IT-ISAC also will take steps to ensure that, even as industry-related information will be free to cross national borders, anything related to national security interests will be appropriately controlled.

Enterprise Architecture Practices Will Help Drive Change at  the IT-ISAC

In other words, we are designing, building, and running a new IT-ISAC. We can talk for hours about what we want the next decade to be, but to effect meaningful change with the highest probable outcome of success requires planning that change and creating mechanisms to enable it. And isn’t the essence of architecture to understand the mission’s larger goals and to build a phased plan to get there — a plan that supports repeatable change as necessary, based on processes and standardized methodologies?

I’m pleased to say there’s great support from the IT-ISAC board for the direction we’re heading. I’m proud to be affiliated with such a luminous group of leaders, which includes some of the most recognized CIOs in the industry. Together we are looking to enhance the strong bonds that already exist among the organization’s members by creating new connections and adding even greater value. As I continue to meet with all our member companies, I look forward to hearing their thoughts on achieving our goals — and to using what I know of enterprise architecture practices to help deliver those outcomes.

Change Comes to the IT-ISAC, and Enterprise Architecture Practices Will Help Drive It

Any organization that’s been around for any length of time — be it 10 years or 10 decades — inevitably confronts change of some fairly significant magnitude. Such is the situation at the IT-ISAC (Information Technology - Information Sharing and Analysis Center), a nonprofit corporation that since 2001 has focused on cyber vulnerability management and on cooperating with national and homeland security efforts to strengthen critical IT infrastructure.

Having had the honor of both belonging to this group since its inception and more recently of being elected its president, I now also have the privilege of helping to reboot IT-ISAC for the next decade. That’s a job that will call on enterprise architecture skill sets as much it will on security and communications expertise.

Let me explain a little about “what” is changing and the “why” behind it. I’ll start with the latter. It remains important, of course, to understand and address product vulnerabilities. But that’s also a difficult prospect at a cross-organizational collaborative level, considering the risks of disclosure before solutions are available. Not only that, but product vulnerability is just one concern in a world of threats that also includes malware, criminal activity, exploits and other attacks on internal IT environments and the customers they support. Changes in IT service delivery and IT service consumption, including a growing array of mobilized apps, add to corporate risk profiles. And, as cloud computing grows and creates infrastructure vendors from some unexpected sources, so too do the opportunities for threats that may have an impact on these services and their users.

Second, while national infrastructure security remains a focus for IT-ISAC, today organizations are interconnected by their reliance on technologies without regard to national borders. We can’t ignore that.

In sum, the threat has become more complex while vulnerability disclosure and management processes have become more mature. This is propelling the IT-ISAC to refocus on threats to the cyber infrastructure and individual networks:

• Threats to one entity generally are threats to all, and the net of discussion must widen to encompass more participants in individual companies and more international companies with operations across the globe. To address this, we are creating specific communities of interest from the member population at large so that they can more rapidly share and analyze pertinent threats and act to contain them.
• A more globally encompassing IT-ISAC also will take steps to ensure that, even as industry-related information will be free to cross national borders, anything related to national security interests will be appropriately controlled.

Enterprise architecture’s influence will be a requirement for the IT-ISAC to be successful at sharing information in its new construct, properly organizing it and creating action from it, as we focus to threats, create discussion among smaller and more aligned groups, and expand internationally. To get to the more agile state we envision, we need to re-engage with old constituents and engage with new ones, both within and outside of existing member organizations. We need to build consensus on what communities of interest should address so that we can better drive member value . And we need to make sure that our means for sharing information, as well as for limiting it when called for, operates in fact as much as it does in theory.

In other words, we are designing, building, and running a new IT-ISAC. We can talk for hours about what we want the next decade to be, but to effect meaningful change with the highest probable outcome of success requires planning that change and creating mechanisms to enable it. And isn’t the essence of architecture to understand the mission’s larger goals and to build a phased plan to get there — a plan that supports repeatable change as necessary, based on processes and standardized methodologies?

I’m pleased to say there’s great support from the IT-ISAC board for the direction we’re heading. I’m proud to be affiliated with such a luminous group of leaders, which includes some of the most recognized CIOs in the industry. Together we are looking to enhance the strong bonds that already exist among the organization’s members by creating new connections and adding even greater value. As I continue to meet with all our member companies, I look forward to hearing their thoughts on achieving our goals — and to using what I know of enterprise architecture practices to help deliver those outcomes.

Any organization that’s been around for any length of time — be it 10 years or 10 decades — inevitably confronts change of some fairly significant magnitude. Such is the situation at the IT-ISAC (Information Technology - Information Sharing and Analysis Center), a nonprofit corporation that since 2001 has focused on cyber vulnerability management and on cooperating with national and homeland security efforts to strengthen critical IT infrastructure.

Having had the honor of both belonging to this group since its inception and more recently of being elected its president, I now also have the privilege of helping to reboot IT-ISAC for the next decade. That’s a job that will call on enterprise architecture skill sets as much it will on security and communications expertise.

Let me explain a little about “what” is changing and the “why” behind it. I’ll start with the latter. It remains important, of course, to understand and address product vulnerabilities. But that’s also a difficult prospect at a cross-organizational collaborative level, considering the risks of disclosure before solutions are available. Not only that, but product vulnerability is just one concern in a world of threats that also includes malware, criminal activity, exploits and other attacks on internal IT environments and the customers they support. Changes in IT service delivery and IT service consumption, including a growing array of mobilized apps, add to corporate risk profiles. And, as cloud computing grows and creates infrastructure vendors from some unexpected sources, so too do the opportunities for threats that may have an impact on these services and their users.

Second, while national infrastructure security remains a focus for IT-ISAC, today organizations are interconnected by their reliance on technologies without regard to national borders. We can’t ignore that.

In sum, the threat has become more complex while vulnerability disclosure and management processes have become more mature. This is propelling the IT-ISAC to refocus on threats to the cyber infrastructure and individual networks:

• Threats to one entity generally are threats to all, and the net of discussion must widen to encompass more participants in individual companies and more international companies with operations across the globe. To address this, we are creating specific communities of interest from the member population at large so that they can more rapidly share and analyze pertinent threats and act to contain them.
• A more globally encompassing IT-ISAC also will take steps to ensure that, even as industry-related information will be free to cross national borders, anything related to national security interests will be appropriately controlled.

Enterprise architecture’s influence will be a requirement for the IT-ISAC to be successful at sharing information in its new construct, properly organizing it and creating action from it, as we focus to threats, create discussion among smaller and more aligned groups, and expand internationally. To get to the more agile state we envision, we need to re-engage with old constituents and engage with new ones, both within and outside of existing member organizations. We need to build consensus on what communities of interest should address so that we can better drive member value . And we need to make sure that our means for sharing information, as well as for limiting it when called for, operates in fact as much as it does in theory.

In other words, we are designing, building, and running a new IT-ISAC. We can talk for hours about what we want the next decade to be, but to effect meaningful change with the highest probable outcome of success requires planning that change and creating mechanisms to enable it. And isn’t the essence of architecture to understand the mission’s larger goals and to build a phased plan to get there — a plan that supports repeatable change as necessary, based on processes and standardized methodologies?

I’m pleased to say there’s great support from the IT-ISAC board for the direction we’re heading. I’m proud to be affiliated with such a luminous group of leaders, which includes some of the most recognized CIOs in the industry. Together we are looking to enhance the strong bonds that already exist among the organization’s members by creating new connections and adding even greater value. As I continue to meet with all our member companies, I look forward to hearing their thoughts on achieving our goals — and to using what I know of enterprise architecture practices to help deliver those outcomes.