A Maturity Model is used to assess the maturity and effectiveness of an organization’s use of Enterprise Architecture. The model describes the various stages of maturity and provides a structured way to evaluate where an organization stands in terms of Enterprise Architecture.
The purpose of such a model is to help organizations improve the implementation and execution of Enterprise Architecture and become more mature. It is also used to understand which areas need improvement. Evidently, by understanding the organization’s maturity level, the organization can make targeted improvements to the implementation of Enterprise Architecture to achieve better business results.
Enterprise Architecture Maturity Models
It is important to realize that there are several Enterprise Architecture Maturity Models available. Each model has its own set of evaluation criteria. It is important to select a model that is a good fit for the organization. For example, if the architect works for a fairly informal organization, do not choose a formal maturity model. Such a formal model is more likely to be intimidating than to be used and adopted. As much as possible, match the model to be used to the way the organization works, the people who work there, and the culture that prevails.
Enterprise Architecture Maturity Models are often based on the Capability Maturity Model Integration (CMMI) framework [1]. CMMI is originally a standardized model for assessing and improving the processes used in software development and other engineering disciplines. Today, the model is also regularly used to indicate the maturity of an Enterprise Architecture.
Of course, there are several ways to build a maturity model. For example, a good model to use and apply is shown in the figure below. A more detailed elaboration of this model can be found in Appendix B – Example Maturity Model of my book Getting Started with Enterprise Architecture.
Applying the method
The maturity model shown in the figure above is characterized by the use of five maturity elements (rows) against the same number of maturity levels (columns). In practice, the maturity elements in the model may vary slightly from the way they are shown here, but in essence they will boil down to the use of the themes shown in this example.
In addition to the elements presented in the model above, several additional topics can be identified [2] that can be included in a maturity model. Each of these topics is a useful addition on its own. However, the more elements that are included, the less readable the model becomes. The advice is to start small. If necessary, additional elements can be considered for inclusion in the model in the future.
What can help determine which maturity elements to include in the maturity model is to look at the stages and steps as described in the Enterprise Architecture Implementation Wheel. The named steps in the wheel, outside of Maturity, are Information, Stakeholders, Framework, Strategy, Roadmap, and Measure Progress. The Strategy and Roadmap steps can be combined into a single maturity element. When the themes of these steps are incorporated into the maturity model, a framework is created that can be built upon. Coupled with the integration of the Implementation Wheel, the maturity model provides a way to track the ongoing maturity of the Enterprise Architecture being implemented.
Maturity levels
A maturity model based on CMMI defines five levels of maturity. These are shown in the columns.
- Ad hoc. Frameworks and standards have not yet been established, and the architecture process is generally conducted in an informal manner. The organization is aware of the benefits that Enterprise Architecture can provide, but has not yet defined a process to track and monitor the evolution of the architecture process. A strategy exists, but has not yet been translated into implementation.
- Repeatable. The architecture process is formalized and there is a vision for the architecture. The need for adherence to architectural frameworks is recognized by senior management. Metrics are also being captured to evaluate the process. The organization’s strategy is beginning to be translated into concrete goals and objectives.
- Defined. The architecture framework to be used has been determined, and there is a formally defined process for adhering to the architecture process. There is a roadmap for the evolution of the architecture, and related activities are performed in accordance. Metrics are maintained and monitored for the purpose of evolving the architecture process.
- Managed. Measurement data is actively used to improve and refine the architecture process. Data is analyzed and used to drive architecture performance. The Enterprise Architecture is invariably used to inform the organization’s strategy.
- Optimal. The architecture process is mature; the organization has drivers, goals, and objectives created based on the application of Enterprise Architecture. Continuous improvements are made to the architecture process, and projects and other initiatives can no longer proceed without Enterprise Architecture input. Experiences are shared and suggestions for improving processes are discussed.
A maturity model enables an organization to identify opportunities for growth and development. I.e., by translating the activities into actionable initiatives, it becomes possible to raise the level of architectural maturity within the organization.
Elements of maturity
The maturity model used in this example contains five elements of maturity. These are shown in the rows.
- Strategy and vision. The organization has a clear strategy and vision for architecture development that is closely aligned with the organization’s goals. There are clear priorities and guidelines for the development of the architecture. The Strategy and Roadmap steps from the Enterprise Architecture Implementation Wheel can be used for this element.
- Architecture governance. The organization has experienced and competent people responsible for developing the architecture. There are roles and responsibilities for the architecture function. These are clearly defined so that the organization understands what can and cannot be expected of the architecture capability. This prevents discussions about architecture. The step Measure progress from the Implementation Wheel aligns with this element.
- Architecture method and process. The organization has standardized processes and methods for developing the architecture. The step Framework from the Implementation Wheel applies to this maturity element.
- Architecture deliverables. The organization has appropriate tools and technologies to develop, implement and manage the architecture. The Information step from the Enterprise Architecture Implementation Wheel can be used for this element.
- Business alignment. The organization has clear controls and governance for architecture development, including measurable performance indicators and quality standards. The Stakeholders step from the Implementation Wheel relates to this element.
Using the stages from the Implementation Wheel, it is possible to determine where the organization is in terms of architecture maturity. Which issues are well addressed? What issues need additional attention? By checking whether or not the items in the maturity model are satisfied, the current level per maturity element can be determined. Note that if not all of the elements for each level are satisfied, then that level is not applicable and the previous level applies.
Graphical representation
One way to visualize the current level of architectural maturity is to color the topics that are in order or realized (see the figure below). A similar approach can be used to visualize the desired level.
Current and desired level
After determining the current level of maturity, it is important to clarify what the desired level should be. The first step is to determine where the organization is now; what level of maturity the organization has reached. By asking questions regarding the elements of the maturity model, the current maturity level can be determined.
First example
For example, ask whether architecture activities are done on an ad hoc basis or formally initiated. In the former case, it is immediately clear that Strategy and vision are at the first level.
Second example
Another example of a question that could be asked is whether architecture is integrated into the strategic planning of the organization. If this is the case, then the Architecture method and process is at level 3. In some cases, further questions are needed. What is the evidence that architecture activities are formally initiated? What examples can be given to show that architecture is actually integrated into strategic planning? It is very easy to answer that everything is in order and under control. Further questioning provides the opportunity to uncover the actual state of affairs.
When introducing and implementing Enterprise Architecture in an organization, it is advisable to set a concrete goal in terms of achieving a certain level of maturity. Of course, it is great to be able to say that the organization is at level 5 after a few years of effort, but the question is whether this is realistic and effective enough.
It is wise to work in small steps. Even with small steps, an organization moves forward and the results are visible. Therefore, set the next (or possibly subsequent) level as the goal, counting from the current maturity level. If an organization is at level 1, then the next level to aim for is level 2. If an organization has some things well in place and is somewhere between level 1 and level 2, then the focus can be on achieving level 3.
The use of an architecture maturity model makes it possible to meet the requirement to demonstrate compliance. In particular, capturing the essentials ensures that sufficient evidence can be provided to auditors to demonstrate compliance with applicable laws and regulations. The maturity elements that address data capture are therefore critical.
More information
For additional information about creating a Maturity Model, please refer to Chapter 8, Sections 8.3.1.1 through 8.3.1.4, of my book Getting Started with Enterprise Architecture.
Back to
[1] ISACA, “Capability Maturity Model Integration (CMMI)”, https://cmmiinstitute.com/cmmi/intro.
[2] M. van den Berg and M. van Steenbergen, Building an Enterprise Architecture Practice. Dordrecht: Springer, 2006.