What is Enterprise Architecture Maturity Model?

Organizations that can manage change effectively are generally more successful than those that cannot. Many organizations know that they need to improve their IT-related development 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 unfocussed efforts, to little or no avail.

Origin of Capability Maturity Model (CMMs)

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 1986s, which is still widely used today. This CMM provided a framework to develop maturity models in a wide range of disciplines.

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 IT-related development processes.

• 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.

Levels of Maturity Model?

The benefits of capability maturity models are well documented for software and systems engineering. Their application to enterprise architecture has been a recent development, stimulated by the increasing interest in enterprise architecture in recent years, combined with the lack of maturity in this discipline.

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 maturity 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 various practices are typically organized into 5 levels, each level representing an increased ability to control and manage the development environment. The 5 levels are:

Level 0: None

No IT architecture program. No IT architecture to speak of.

Level 1: Initial

Informal IT architecture process underway.

1. Processes are ad-hoc and localized. Some IT architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
2. IT 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 IT architecture process.
6. The latest version of the operating unit’s IT architecture documentation is on the web. Little communication exists in the IT 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 in strategic planning and acquisition personnel in the enterprise architecture process. Little or no adherence to existing standards.

Level 2: Managed

The IT architecture process is under-managed.

1. The basic IT architecture process is documented based on OMB Circular A-130 and the Department of Commerce IT 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 IT 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. The operating unit demonstrates some adherence to the existing Standards Profile.

Level 3: Defined

Defined IT 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 plans are completed. Fully developed TRM and Standards Profile. IT goals and methods are identified.
3. IT architecture is integrated with capital planning and investment control.
4. The senior management team is aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards.
5. Most elements of the operating units show acceptance of or are actively participating in the IT architecture process.
6. Architecture documents updated regularly on the DoC IT architecture web page.
7. IT security architecture Standards Profile is fully developed and is integrated with IT architecture.
8. Explicitly documented governance of the 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: Quantitatively Management

Managed and measured the IT architecture process.

1. The IT architecture process is part of the culture. Quality metrics associated with the architecture process are captured.
2. IT architecture documentation is updated on a regular cycle to reflect the updated IT architecture. Business, Data, Applications, and Technology Architectures defined by appropriate de jure and de facto
3. Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated IT 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 IT architecture process.
6. Architecture documents are updated regularly, and frequently reviewed for the 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 feedback into IT architecture.
9. All planned IT acquisitions and purchases are guided and governed by the IT architecture.

Level 5: Optimizing

Continuous improvement of the IT architecture process.

1. Concerted efforts to optimize and continuously improve the architecture process.
2. A standard and waivers process is used to improve the architecture development process.
3. Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of IT 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.

Conclusions

The topic of capability maturity model-based methods and techniques, as a widely used industry standard that is mature enough to consider for use in relation to enterprise architecture.

The benefits of capability maturity models are well documented for software and systems engineering. Their application to enterprise architecture has been a more recent development, stimulated by the increasing interest in enterprise architecture, combined with the lack of maturity in the discipline of enterprise architecture.