Architecture Maturity Models

togaf-tm-sm

Chapter 51                             <<< Previous | Next >>>

51.1 Overview | 51.2 Background | 51.3 US DoC ACMM Framework | 51.4 Capability Maturity Models Integration (CMMI) | 51.5 Conclusions

This chapter provides techniques for evaluating and quantifying an organization’s maturity in enterprise architecture.

51.1 Overview

Organizations that can manage change effectively are generally more successful than those that cannot. Many organizations know that they need to improve their processes in order to successfully manage change, but don’t know how. Such organizations typically either spend very little on process improvement, because they are unsure how best to proceed; or spend a lot, on a number of parallel and unfocused efforts, to little or no avail.

Capability Maturity Models (CMMs) address this problem by providing an effective and proven method for an organization to gradually gain control over and improve its change processes. Such models provide the following benefits:

  • They describe the practices that any organization must perform in order to improve its processes.
  • They provide a yardstick against which to periodically measure improvement.
  • They constitute a proven framework within which to manage the improvement efforts.
  • They organize the various practices into levels, each level representing an increased ability to control and manage the development environment.

An evaluation of the organization’s practices against the model – called an “assessment” – determines the level at which the organization currently stands. It indicates the organization’s ability to execute in the area concerned, and the practices on which the organization needs to focus in order to see the greatest improvement and the highest return on investment. The benefits of CMMs to effectively direct effort are well documented.

51.2 Background

The Software Engineering Institute (SEI) – www.sei.cmu.edu operated by Carnegie Mellon University – developed the original CMM (Capability Maturity Model) for Software (SWCMM) in the early 1990s, which is still widely used today. This CMM provided a framework to develop maturity models in a wide range of disciplines.

The increasing interest in applying these techniques to other fields has resulted in a series of template tools which assess:

  • The state of the architecture processes
  • The architecture
  • The organization’s buy-in to both

The main issues addressed by these models include:

  • Process implementation and audit
  • Quality measurements
  • People competencies
  • Investment management

They involve use of a multiplicity of models, and focus in particular on measuring business benefits and return on investment.

A closely related topic is the Architecture Skills Framework (see 52. Architecture Skills Framework), which can be used to plan the target skills and capabilities required by an organization to successfully develop and utilize enterprise architecture, and to determine the training and development needs of individuals.

51.3 US DoC ACMM Framework

51.3.1 Overview

As an example of the trend towards increased interest in applying CMM techniques to enterprise architecture, all US federal agencies are now expected to provide maturity models and ratings as part of their IT investment management and audit requirements.

In particular, the US Department of Commerce (DoC) has developed an enterprise Architecture Capability Maturity Model (ACMM)1 to aid in conducting internal assessments. ACMM Version 1.2 was published in December 2007. The ACMM provides a framework that represents the key components of a productive enterprise architecture process. The goal is to enhance the overall odds for success of enterprise architecture by identifying weak areas and providing a defined evolutionary path to improving the overall architecture process.

The ACMM comprises three sections:

  1. The enterprise architecture maturity model
  2. Enterprise architecture characteristics of operating units’ processes at different maturity levels
  3. The enterprise architecture CMM scorecard

The first two sections explain the Architecture Capability maturity levels and the corresponding enterprise architecture element and characteristics for each maturity level to be used as measures in the assessment process. The third section is used to derive the Architecture Capability maturity level that is to be reported to the DoC Chief Information Officer (CIO).

51.3.2 Elements of the ACMM

The DoC ACMM consists of six maturity levels and nine architecture elements. The six levels are:

0
None
1
Initial
2
Under development
3
Defined
4
Managed
5
Measured

The nine enterprise architecture elements are:

  1. Architecture process
  2. Architecture development
  3. Business linkage
  4. Senior management involvement
  5. Operating unit participation
  6. Architecture communication
  7. IT security
  8. Architecture governance
  9. IT investment and acquisition strategy

Two complementary methods are used in the ACMM to calculate a maturity rating. The first method obtains a weighted mean enterprise architecture maturity level. The second method shows the percentage achieved at each maturity level for the nine architecture elements.

51.3.3 Example: Enterprise Architecture Process Maturity Levels

The following example shows the detailed characteristics of the enterprise architecture maturity levels as applied to each of the nine elements. For example, Level 3: Defined, point number 8 (Explicit documented governance of majority of IT investments) shows Maturity Level 3’s state for Element 8 (Architecture Governance).

Level 0: None

No enterprise architecture program. No enterprise architecture to speak of.

Level 1: Initial

Informal enterprise architecture process underway.

  1. Processes are ad hoc and localized. Some enterprise architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
  2. Enterprise architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.
  3. Minimal, or implicit linkage to business strategies or business drivers.
  4. Limited management team awareness or involvement in the architecture process.
  5. Limited operating unit acceptance of the enterprise architecture process.
  6. The latest version of the operating unit’s enterprise architecture documentation is on the web. Little communication exists about the enterprise architecture process and possible process improvements.
  7. IT security considerations are ad hoc and localized.
  8. No explicit governance of architectural standards.
  9. Little or no involvement of strategic planning and acquisition personnel in the enterprise architecture process. Little or no adherence to existing standards.
Level 2: Under Development

Enterprise architecture process is under development.

  1. Basic enterprise architecture process is documented based on OMB Circular A-130 and Department of Commerce Enterprise Architecture Guidance. The architecture process has developed clear roles and responsibilities.
  2. IT vision, principles, business linkages, Baseline, and Target Architecture are identified. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model (TRM) and Standards Profile framework established.
  3. Explicit linkage to business strategies.
  4. Management awareness of architecture effort.
  5. Responsibilities are assigned and work is underway.
  6. The DoC and operating unit enterprise architecture web pages are updated periodically and are used to document architecture deliverables.
  7. IT security architecture has defined clear roles and responsibilities.
  8. Governance of a few architectural standards and some adherence to existing Standards Profile.
  9. Little or no formal governance of IT investment and acquisition strategy. Operating unit demonstrates some adherence to existing Standards Profile.
Level 3: Defined

Defined enterprise architecture including detailed written procedures and TRM.

  1. The architecture is well defined and communicated to IT staff and business management with operating unit IT responsibilities. The process is largely followed.
  2. Gap analysis and Migration Plan are completed. Fully developed TRM and Standards Profile. IT goals and methods are identified.
  3. Enterprise architecture is integrated with capital planning and investment control.
  4. Senior management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards.
  5. Most elements of operating unit show acceptance of or are actively participating in the enterprise architecture process.
  6. Architecture documents updated regularly on DoC enterprise architecture web page.
  7. IT security architecture Standards Profile is fully developed and is integrated with enterprise architecture.
  8. Explicit documented governance of majority of IT investments.
  9. IT acquisition strategy exists and includes compliance measures to IT enterprise architecture. Cost benefits are considered in identifying projects.
Level 4: Managed

Managed and measured enterprise architecture process.

  1. Enterprise architecture process is part of the culture. Quality metrics associated with the architecture process are captured.
  2. Enterprise architecture documentation is updated on a regular cycle to reflect the updated enterprise architecture. Business, Data, Application, and Technology Architectures defined by appropriate de jure and de facto standards.
  3. Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated enterprise architecture. Periodic re-examination of business drivers.
  4. Senior management team directly involved in the architecture review process.
  5. The entire operating unit accepts and actively participates in the enterprise architecture process.
  6. Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/standards.
  7. Performance metrics associated with IT security architecture are captured.
  8. Explicit governance of all IT investments. Formal processes for managing variances feed back into enterprise architecture.
  9. All planned IT acquisitions and purchases are guided and governed by the enterprise architecture.
Level 5: Optimizing

Continuous improvement of enterprise architecture process.

  1. Concerted efforts to optimize and continuously improve architecture process.
  2. A standards and waivers process is used to improve architecture development process.
  3. Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of enterprise architecture.
  4. Senior management involvement in optimizing process improvements in architecture development and governance.
  5. Feedback on architecture process from all operating unit elements is used to drive architecture process improvements.
  6. Architecture documents are used by every decision-maker in the organization for every IT-related business decision.
  7. Feedback from IT security architecture metrics are used to drive architecture process improvements.
  8. Explicit governance of all IT investments. A standards and waivers process is used to make governance-process improvements.
  9. No unplanned IT investment or acquisition activity.

51.4 Capability Maturity Models Integration (CMMI)

51.4.1 Introduction

The capability models that the SEI is currently involved in developing, expanding, or maintaining include the following:

  • CMMI (Capability Maturity Model Integration)
  • IPD-CMM (Integrated Product Development Capability Maturity Model)
  • P-CMM (People Capability Maturity Model)
  • SA-CMM (Software Acquisition Capability Maturity Model)
  • SE-CMM (Systems Engineering Capability Maturity Model)
  • SW-CMM (Capability Maturity Model for Software)

As explained in this chapter, in recent years the industry has witnessed significant growth in the area of maturity models. The multiplicity of models available has led to problems of its own, in terms of how to integrate all the different models to produce a meaningful metric for overall process maturity.

In response to this need, the SEI has developed a Framework called Capability Maturity Model Integration (CMMI), to provide a means of managing the complexity.

According to the SEI, the use of the CMMI models improves on the best practices of previous models in many important ways, in particular enabling organizations to:

  • More explicitly link management and engineering activities to business objectives
  • Expand the scope of and visibility into the product lifecycle and engineering activities to ensure that the product or service meets customer expectations
  • Incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
  • Implement more robust high-maturity practices
  • Address additional organizational functions critical to its products and services
  • More fully comply with relevant ISO standards

CMMI is being adopted worldwide.

51.4.2 SCAMPI Method

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the appraisal method associated with CMMI. The SCAMPI appraisal method is used to identify strengths, weaknesses, and ratings relative to CMMI reference models. It incorporates best practices found successful in the appraisal community, and is based on the features of several legacy appraisal methods. It is applicable to a wide range of appraisal usage modes, including both internal process improvement and external capability determinations.

The SCAMPI method definition document2 describes the requirements, activities, and practices associated with each of the processes that compose the SCAMPI method.

51.5 Conclusions

This section has sought to introduce into TOGAF the topic of CMM-based methods and techniques for use in relation to enterprise architecture.

The benefits of using CMMs are well documented. Future versions of TOGAF may include a maturity model to measure adoption of TOGAF itself.

Footnotes
  1. Refer to ocio.os.doc.gov/ITPolicyandPrograms/Enterprise_Architecture/DEV01_003735.
  2. Available at www.sei.cmu.edu/publications/documents/01.reports/01hb001.html.

return to top of page

<<< Previous Home Next >>>