Enterprise Architecture: A Maturity Model Based on Benefits Realization

Building a city without a plan will likely result in confusion, increased expenditures, and sub-optimal results. Similarly, in order to build an effective and efficient IT plan across an agency or multiple government agencies, it is critical to develop a master plan. This master plan is called enterprise architecture (EA).

EA, when used as a best practice, can allow the federal government (and commercial organizations) to best manage complex IT and meet their business goals and objectives. Building IT according to a master plan leads to a more cost-effective process, lower risk IT investment, and the ability to leverage commonalities throughout federal agencies. This blueprint ultimately helps agencies perform optimally, while saving money over time.

Due to the millions of dollars lost to high-profile IT modernization failures in the mid-nineties, the federal government searched for a solution that would allow agencies to be operationally agile and seamlessly share information. In 1996, Congress recognized EA as a best practice when it passed the 1996 Clinger-Cohen Act mandating enterprise architecture for federal agencies.

Over time, agencies have recognized the importance of implementing EA to ensure efficient operations. The General Accounting Office (GAO) began to assess federal IT investments from an EA perspective and started by looking for agencies to initiate and move forward with EA programs.

In the federal space, agencies have adopted EA in various forms. The Office of Management and Budget (OMB) now mandates EA as part of the funding process for IT investments. This creates additional incentive for agencies to adopt enterprise architecture to help define their investments. OMB is essentially tying EA to funding thus giving EA credibility in this space.

Although EA is federally mandated for agencies, its adoption and implementation has been slow and uneven. The potential benefits have been blurred because the definition of EA has a variety of meanings to different stakeholders. This distortion has largely contributed to the agencies’ inability to clearly see the benefits in adopting EA. For example, some stakeholders think that EA is synonymous with the current IT assets of the enterprise such as the IT inventory or software license list. Others see EA as simply the models and work products, e.g., the Zachman or DODAF framework. Furthermore, many view the EA as a transition plan from the current architectural state to a new target state.

While all of these items are part of an EA program, they are not individually EA. The focus on one single element does not lead an organization to the ultimate benefits of EA.

Enterprise Architecture Benefits Realization Maturity Model™

The Enterprise Architecture Benefits Realization Maturity Model™ truly views enterprise architecture through a benefits prism. It is designed to help organizations focus their EA programs on understanding the maximum potential benefits. It also helps define and work through the various stages of organizational maturity required to achieve these benefits.

By using this model, organizations quickly understand the benefits of enterprise architecture and can proactively understand what benefits to expect. By understanding the benefits, organizations are able to justify moving forward with EA programs focused in the areas that will achieve the maximum benefit for their organizations.

Maturity Models

There are many IT maturity models in use today. Perhaps the best-known model is SEI’s[1] software capability maturity model (CMM). This model identifies five stages that organizations move through and can be assessed against in the systems development area.

The GAO and OMB have also developed EA maturity/assessment models[2]. These maturity/assessment models are focused primarily on the appropriate processes to support an enterprise architecture program. The GAO and OMB model’s process-based and results-based approaches are applicable to agencies. The GAO and OMB use these regularly to assess the EA progress of federal agencies. The GAO’s EA model basis is similar in concept to that of the SEI CMM with the presumption that when appropriate processes are followed and in place, results will improve.

The Enterprise Architecture Benefits Realization Maturity Model™ gives a different perspective and is complementary to the GAO’s EA maturity model. This model looks at the various levels of benefits that an organization can achieve through implementing EA. By using this model, organizations are assessed by the benefits they achieve as opposed to processes they follow. Finally, this model gives an organization a road map for its enterprise architecture efforts.

Characteristics of the Benefits Realization Model

The benefits realization model has a number of characteristics that are important to understand in order to use the model effectively. First, all organizations embarking on an EA program will go through four defined stages. The pace at which organizations go through the stages will vary depending on organizational knowledge and expertise, the desire to achieve the benefits associated with each level, and level of maturity of the organization. Therefore, the pace at which benefits are realized will vary by organization.

At the different levels in the model, different questions are addressed.

File 719

Level one questions are basic: “What IT systems do I have?” or “Where is my critical data stored?”

Level two questions take a closer look at business objectives: “How should applications be logically architected to achieve my business mission?” or “What are my critical data entities?”

Level three questions narrowly focus on architectural transition: “Which IT projects should I execute?” or “What IT systems should I plan to retire?”

Level four questions focus on performance: “Will my target vision for IT in this area improve the performance of critical processes?”

The benefits for organizations accumulate from one level to the next. At level one, opportunities are identified; at level two, an architecture vision is created and architectural decisions are made based on leveraging those opportunities; at level three, investment decisions are made based on constructing the architectural vision; and at level four, architectural decisions are validated to predict and, ultimately, achieve performance gains.

In moving from one level to the next, higher levels of organizational management expertise are required. Higher-level organizational motivation is required to achieve each level because stages are more complex and more demanding across the enterprise. At level one, organizations need to share basic information about their IT, which tends to be nonthreatening. At level two, organization components need to share their vision and compromise their individual vision for the benefit of the overall enterprise. At level three, decisions are made about the optimal investment level for the organization. Finally, at level four, organizations need to determine the need for performance gains and how that can be leveraged through architecture.

Benefits Realization Model Overview

The Enterprise Architecture Benefits Realization Maturity Model™ has four maturity levels. These levels are consistent with the types of benefits that are achieved through enterprise architecture.

Level one is the informational level where the enterprise architecture is providing information to the entire enterprise.

Level two is decisional with regard to the architecture vision.

Level three is decisional with respect to IT investments.

Level four is termed performance-enhancing for its focus on improving the performance of the organization.

If an organization has not implemented EA, it has not achieved any organizational benefits. Therefore, this organization is considered to be at “level zero.” This illustrates the four benefit levels of the benefits realization model:

File 720

Level 1: Informational

The informational level is the base level of the benefits realization model. Organizations realizing benefits at this level are typically in the early stages of enterprise architecture programs. The benefits achieved at this level are the identification of opportunities for improvement within the organization. These opportunities are identified by gathering information about the organization’s IT in an accessible location where analysis can be performed. Typically, organizations that are beginning architecture programs do not have a knowledge base where fundamental information about organizational business and IT is stored and known by the organization.

Organizations operating at this level use EA as an umbrella for gathering information about information technology and related business information. This information typically includes business activities, critical data, the locations and content of data stores, applications and IT systems, technologies, products and standards, and organizational context information. By having all of this information together in one place, it can be assessed as a cohesive whole, and opportunities for leveraging commonality can be identified. Hence, the benefits achieved by an organization operating at this level are the identification of opportunities and the initial breakdown of organizational barriers that could prevent gathering of IT and business information in a single knowledge base.

Level 2: Decisional—Architecture Vision

The decisional–architecture vision level is the second level of the benefits realization model. It develops an architectural vision of the future that leverages that commonality learned in level one and links the architecture vision to business goals and objectives. At this level, the target architecture is developed, technical standards are identified, and the future architectural vision of the enterprise is communicated to all stakeholders. Once the target architecture is developed, it can then be used to make architectural decisions in the enterprise. These decisions are framed by the target architecture, architectural principles, and high-level technical standards. The benefits achieved at this level include IT and organizational decisions that are aligned with the future vision, implementation of technical standards, and an architecture that is aligned with the business goals. Organizations operating at this level begin to move toward leveraging commonality and achieving economies of scale associated with moving toward a common vision.

Level 3: Decisional—IT Investments

The decisional–IT investment level is the third level and involves taking the target architecture that was developed at level two and ensuring that investment decisions are made by the organization to achieve the architectural vision. At this level, the architectural vision “comes to life” by integrating the architectural vision and the IT investment process of the organization.

Additionally, at this level, organizations have developed transition plans that identify all of the projects necessary to move from the current state to the target architecture vision. These projects typically include infrastructure, application development, data consolidation and cleansing, business process reengineering, and organizational change management. These are the types of projects necessary to move from an “as is” state to a target vision. The transition plans also include tangible decisions to move and evolve from current IT projects that are underway to projects that build the target architecture. This transition plan typically includes planning system retirements. The benefits achieved at this level are financial and organizational. Benefits may include the decision to select IT investment projects, plan system retirements, and leverage commonality by managing IT transition investments as a portfolio, all of which lead to more effective and efficient IT for the enterprise and implementing the architecture vision.

Level 4: Performance Enhancing

The performance enhancing level is the fourth level of the benefits realization model. This level involves proactively planning architectural direction based on business performance improvements to be achieved by implementing the target vision. At this level, the architectural vision is assessed proactively to increase the probability that business performance improvements will be obtained. Organizations operating at this level need to have in place an enterprise-wide performance management program. As part of this program, performance measures for the organization are linked to overall higher-level performance goals for the enterprise. With a program like this in place, specific business process performance targets are typically identified. When implementing enterprise architecture at a mature organization in the performance management area, the architectural vision can be validated through modeling against the performance targets. The modeling can indicate whether the architectural vision is likely to deliver the performance enhancements that are most important for the organization. The benefits that can be obtained at this level are the proactive knowledge and ultimate ability to perform business processes faster, better, or cheaper. By improving business processes in this way, an organization can deliver higher value for stakeholders and customers. At this level, architectural decisions and investments are made from the standpoint of the performance improvements that will result from those architectural decisions.


There is much confusion in the enterprise architecture marketplace about the purpose and benefit of enterprise architecture. Many different definitions of enterprise architecture exist and organizations perform many activities under the guise of enterprise architecture. The Enterprise Architecture Benefits Realization Maturity Model™ clarifies and focuses the benefits of enterprise architecture and brings structure to the many activities that are occurring under the EA umbrella. The benefits realization model paints a picture of the desired benefits, leveraging the concept of Stephen Covey’s[3] “begin with the end in mind.” With the desired benefits in mind and understanding of the maturity model framework, organizations can productively achieve the benefits that can accrue from an enterprise architecture effort. As enterprise architecture evolves, it is anticipated that the benefits associated with this model will remain stable. Different tools and techniques will be developed, and different methodologies and approaches will be attempted. But the bottom line will remain to achieve benefits for the organization commensurate with the EA effort. The Enterprise Architecture Benefits Realization Maturity Model™ can remain a focal point for enterprise architecture for many years into the future.

[1]. Carnegie Mellon University; Software Engineering Institute, 2004.

[2]. GAO Report, “Information Technology: Enterprise Architecture Use Across the Federal Government Can Be Improved.”

[3]. Stephen R. Covey, The Seven Habits of Highly Effective People: Powerful Lessons in Personal Change, August 1990.

File 721

Ira Sachs is senior technical director at High Performance Technologies, Inc. (www.hpti.com). He as more than  20 years experience in enterprise architecture, information systems development, capital planning, strategic planning, business and software process analysis and reengineering, financial systems, and program management.

An Interesting (and much needed) Model

Ira Sachs hits the nail on the head with his views on typing maturity models to EA. As he cites, the Government now has requirements to have supporting architectures (actually templates that list some architecture data is the current version) for investment requests. That is a start, there is no mention of the QUALITY of the archiectures in the Governmnet guidance, other than to state that started projects get 'points', completed projects get more points, and non-starters get no points toward the annual 'grade'.

The maturity model takes all this to another level is describes how a quality architecture can answer questions for management in analysis and decision-making, and also ensure that needed, completed, data is available for analysis and review. I hope he will continue to flesh out this maturity model, and that we will see more of it in the near future.