Ten Signs of Enterprise Architecture Maturity

Whether your enterprise architecture (EA) is complete, under development or de facto (i.e., no formal EA has been undertaken, but you are living with a motley assortment of databases, applications and platforms), how can you tell if it is up to snuff? One approach to evaluating what, if anything needs to be done is to assess your architecture outputs. Another approach is to assess the extent to which your architecture process is mature enough to consistently add value to the business.

Before you undertake any EA work-formal infrastructure assessment, modification of existing EA or full bore EA development-you may want to consider conducting a relatively quick, qualitative assessment of how mature (as in grown-up) your current EA process is. Here we will describe an informal approach to EA maturity assessment. This approach is characterized by demonstrable

• Quality - the repeatability and consistency of outputs;

• Usefulness - to the Business and IT;

• Linkages - integration into the core business processes.

The value in taking the time to assess the maturity of your current EA process lies in gaining a clear sense of how well your process as it exists is aligned with and important to your business. The benefit of achieving a mature EA process lies in its ability to continually and positively impact the success of the business.

Here is an overview of our EA maturity assessment approach, using ten signs that your architecture process is well on the way to maturity. They indicate the extent to which observable actions or behaviors demonstrate EA process maturity:

1. EA embraced by the business - the EA process has demonstrated support (i.e., observable actions, for example, funding) from the business leadership, the IT leadership, including the CIO, and the development organizations.

2. EA tightly linked to the business - while it is extremely important that the organization's leadership supports EA as a function, it is equally important that the EA process is business-based. We believe the ability to link the architecture directly to key business drivers is so important that in our practice, for example, the process we use requires that the outputs of business analysis are used as direct input to the creation of target architecture outputs.

3. Repeatable EA process - the creation or maintenance of architecture outputs is not dependant on specific people, but rather on the application of a repeatable process by any competent staff member. By process we mean: the combination of people, inputs, outputs, and especially, work methods that produces a product (e.g., EA blueprints) or service (e.g., project evaluation.)

4. Linkage of EA outputs to each other - the extent to which EA outputs are traceable to each other. For example, rather than creating a set of stand-alone standards, we treat architecture standards as a decomposition of architecture models.

5. EA outputs able to be tested - a mature EA process produces outputs that are able to be tested for quality. You will want to ensure, for example, that your EA models comply with your IT principles. You may want to test that your target EA outputs are prescriptive, so that analysts and developers can tell what changes they need to make and what constraints they need to honor.

6. EA outputs useable and used by development - EA outputs are able to be applied correctly, and they are being used. You may want to ask developers if they have knowledge of and access to EA outputs. If they do, ask if they provide developers a very clear picture of architecture intent. We also want to ensure that the EA isbeing implemented. It is fairly easy to tell if development is following EA technology standards. For example, if a Cray shows up on your loading dock and it is not on your list of standard platforms, you can tell pretty quickly that architecture standards were not followed. You may require a more structured process to determine if, for example, data and function standards are being implemented.

7. EA linked to project funding - a very basic test: After your architecture is built, do you know what to do with it? We are really talking about a process relationship check here. For example, if you have a set of architecture projects to implement, is there a clear process for getting them funded and into the pipeline for development?

8. EA impact measurable - we believe that establishing and measuring the achievement of business goals through architecture implementation is the best way to evaluate architecture progress. This requires setting specific architecture objectives. The objectives ought to define specific, measurable and time-bounded business results and criteria for evaluating architecture's contribution to successful achievement of them.

9. EA used as basis for decision-making - a key measure of EA maturity is the effective operation of an architecture governance process. A mature EA governance process measures the extent to which proposed development complies with and/or deviates from target architecture and provides advice and counsel for bringing non-compliant project proposals into compliance.

10. People plans linked to EA - when the EA process is truly integrated into other key business processes, the HR policies, roles and structure of the people in the organization are compatible with the EA process (e.g., there are EA job titles and descriptions.) The value of applying this test for maturity lies in identifying practices and structures in the organization that hinder implementation and addressing barriers.

Here is a simple exercise you may want to try. Begin by defining a maturity scale (e.g., in a four-anchor scale, "1" might mean not at all or never.) Then for each of the ten criteria we have briefly described here, select the most appropriate rating. Where possible, cite anecdotes or examples of why you chose each rating. If your results include many "1" and "2" ratings, you may have built a good case for why your organization needs to do some EA process work.

A maturity assessment measures how well your EA process operates as a business function - much like an ordering function or data center operations. If you want to understand, or help others understand, how well your EA process is actually performing, taking an inventory of how mature your current EA process is will be time well spent.