The Essential EA Toolkit (Part 1)

In order to be effective, Enterprise Architecture teams need “tools” in their toolkit, and I don’t mean technologies like System Architect or Troux. Rather, I am referring to a few deliverables that create enormous value for your business and can be realized as simple drawings, processes and existing collaboration applications. 

This four part post presents for your consideration some of the more effective tools I’ve identified:

1. A Business Capability Model
2. A Standards Repository based on a Reference Architecture
3. An Architecture Governance Process
4. A Strategic Blue Print and an Enterprise Roadmap.

Tool 1 - A Business Capability Model

A recurring theme of this blog is the creation of business value through simple, easily consumed deliverables, which requires a common language in order to develop a pool of shared meaning (see Who’s On First?). The moment a team realizes that it has to be able to talk to the business but does not know how is one of the bigger “a ha” milestones in EA maturation. A Business Capability Model provides a foundation for this type of communication. It is a simple “nested boxes” diagram that represents the “capabilities” a business has or desires. Here is an example, shown with some Strategy overlays:

You may notice that much of the model looks similar to a corporate organization chart, however the model is different - it is purely based on capabilities and not company divisions or locations. It may have some boxes that correlate to corporate divisions, but some do not. The best example is “Customer Engagement”. 


Since many divisions deal with customers in some form or fashion, Customer Engagement is something an Enterprise must be able to do well across organizational boundaries. When no single executive has accountability for the Capability except the CEO, getting things done at a working level becomes challenging. One solution is to assign the single accountability; however that may not always be practical. 


The Business Capability Model helps align executive stakeholders when it is not by creating a set of “lenses” for describing the architecture in ways that are immediately useful to the business. Because the model is based on Capabilities, vice divisions, it drives enterprise thinking; especially in those Capabilities that are share functions with more than one department. 


Continuing the Customer Engagement example, a set of “Customer Engagement” architecture deliverables can be created that clearly communicate enterprise strategy, provide a basis for cross divisional alignment and set expectations for investment.

Here are some practical uses of the model:

• As implied, Architecture deliverables can be cast in terms of a Capability providing different views of the Enterprise Architecture to different stakeholders. For example, executives concerned with customer interactions, such as Marketing and Distribution, can focus on the Customer Engagement roadmap while those in Manufacturing and Purchasing may not pay as much attention. See The Quantum of Integration for more on the power of Views in architecture.
• Strategy overlays, as show above, are a useful way to identify required investment. For example, the strategy to “Open Web sales channels by improved segmentation…”, show as a red line, impacts the Marketing, Distribution and Customer Engagement capabilities. Further drill down into these, specifically identifying functions that must be enabled or improved, can yield an appropriate set of IT investments focused on delivering the strategy.
• Capabilities can be used to classify investments as part of a roadmap. For example, capturing a qualitative estimate of the % contribution of an investment to driving Capabilities allows analysis of corporate investment against strategy. Picture a pie chart of total investment by strategy as “gut check” tool for executives.
• Applications can be analyzed by Capability in a similar fashion to process and investments. An analysis of applications and planned investments by Capability can produce useful decision aids as organizations make budget decisions.

In developing the Business Capability Model, there are a few traps to avoid:

• Avoid overcomplicating the model. Shoot to have no more than 15 components and go one level deep to begin with. Since the model is used for communications to the business, ensure that it is something a business executive can look at and digest without a lot of explanation. Go for the “I get it” expression.
• Ensure the business buys into the model, and preferably helps IT develop it. The model is a combination of architecture “purity” and business pragmatism. Many early attempts at such a models gave names to the boxes that no business person understood. We architects may get it, but this is not a tool for us. In my personal experience, it took three or four attempts over as many years before we landed on a model that the business accepted.

After you have a working model and are using it to effectively deliver value to the business, take next steps like decomposing the first level components into functions and defining relationships between the components according to business process that cross capability boundaries.

Next week, I’ll continue this discussion with Tool 2 - A Standards Repository and a Reference Architecture.