What is Enterprise Architecture Maturity Model

What is Enterprise Architecture Maturity Model?

8-10 minutes

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.