Architecture maturity assessments help to determine how companies can maximise competitive advantage, identify ways of cutting costs, improve quality of services and reduce time to market. These assessments are undertaken as part of the Enterprise Architecture management.
There are some methodologies for assessment of the comprehensive Enterprise Architecture maturity. Examples of these are the US Department of Commerce ACMM, the Open Group architecture maturity model, and a BSC-based Architecture Score Card presented by IFEAD. For application or technology portfolios, portfolio evaluation models can be used.
As a part of project development, assessments (in reality compliance) of architecture solutions are made against the business objectives and requirements (desired process and service structures and business models) and the constraints derived from the Enterprise Architecture context (these may be standards, principles, policies or other restrictions for solution development). Assessment and compliance of technologies are also a central part of Enterprise Architecture development projects. Finally, the development of Enterprise Architectures undergoes the scrutiny of the software development quality assurance method in use. Many IT providers have adopted a comprehensive software quality assurance approach like CMMI, or ISO/IEC 15504 (known as SPICE).
Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework, to identify the gaps between the business vision and the business capabilities. Unfortunately no sufficient assessment instruments or tools have been developed for TOGAF based assessments.
Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment.
In the following example you may observe four different phases on how to run an assessment.
The Phase 1 would include several steps:
- Planning & preparation workshop with the stakeholders. Stakeholders should represent both Business and IT
- Interviews with stakeholders based on a questionnaire related to all process areas (elements in TOGAF) or domains that have characteristics important to the development and deployment of Enterprise Architecture. Each process area could be divided into a number of practices, which are statements that describe the process area for each level of maturity, on a scale of 0 to 5. Each practice would have a set of practice indicators, evidence that the requirements for a process area to be at a given level have been met. A set of questions that will be asked in the interviews establishes whether or not the practice indicators exist and thus the level of maturity for the practice. If all the practices for a given level within a Process Area are present, then that level will be achieved. Ideally, directly relevant documentary evidence will be provided to demonstrate that the practice Indicator exists. As this is not always practical, sometimes for this exercise, only verbal evidence from subject matter experts will be considered.
- Production of a report
- Calculation of a maturity score. For the representation, we use the term maturity level or organisational maturity as described below
o CMMI for Development (Version 1.2, 2006)
o Appraisal Requirements for CMMI (ARC) (Version 1.2, 2006)
o The US Department of Commerce Enterprise Architecture Capability Maturity Model (2007)
o TOGAF® 9.1
o NASCIO Enterprise Architecture Maturity Model (Version 1.3, 2003)
We then deliver a report which includes the maturity of each process area or element. (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).
The use of radar may also be a nice way to present the results. (Example below)
- Presentation of the report to the stakeholders with strengths, weaknesses, gap analysis, recommendations
- Next steps
The Phase 2 would include several steps:
- Based on results from the Phase 1, a consensus workshop would produce a roadmap and action plan with recommendations to attain the next (required) level of maturity.
- The workshop would provide a tool to produce an objective view of the report provided in Phase 1. This would give stakeholders and the senior management team a detailed view of how well Enterprise Architecture is deployed in the organisation, it provides a full understanding of the business drivers and organisation issues and a clear view of where the stakeholders want the organisation to be. The outputs of this phase are priorities, and an action plan that is agreed, and understood by the key stakeholders in the organisation. There could also be a target radar diagram as shown below (Example).
The updated report may then look like this (extract of an example):
The Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4 similar to Phase 1.
To conduct an evaluation of an organization’s current practices against an architecture capability maturity assessment model, allows to determine the level at which the organization currently stands. It will indicate the organisation's maturity in the area of enterprise architecture and highlight the practices on which the organisation needs to focus in order to see the greatest improvement and the highest return on investment. The recommendation is that assessments should be carried out annually.