Background “Maturity” is a term that has become more and more prominent in business since the 1980s, when the United States Air Force funded a study at the Carnegie-Mellon Software Engineering Institute to create a model for the military to use as an objective evaluation of software subcontractors. The result was the Capability Maturity Model (CMM), published as Managing the Software Process in 1989.
Since the initial deployment of the CMM, many organizations have latched on to the concept of maturity, and developed maturity models for almost everything under the sun. As a result, the definition and application of the concept of “maturity” has often and widely diverged from the original intent of the CMM.
The CMM measures process maturity, not organizational maturity
According to the CMM, a process is mature when it consistently performs defined behaviors or actions. A more mature process is one that regularly “manages” or “optimizes” the defined behaviors or actions. As designed, the CMM works well when evaluating a vendor or a software department (i.e., groups that execute a process to deliver a defined scope).
When evaluating and measuring the maturity of an organization, however, the analysis needs to be more comprehensive than just a review of processes, and must include other operational aspects. While the CMM covers process maturity, it does not address other organizational elements like leadership, culture, and personnel skill sets. When organizational maturity models too closely imitate the scope and format of the CMM, they often exclude these other operational elements and fail to provide a complete picture.
How to measure Business Architecture maturity?
Measuring an organization’s ability to develop and manage Business Architecture should go beyond simply evaluating the process required to develop architecture. Additional perspectives, including leadership support, cultural readiness, and architect skills, must also be evaluated. A comprehensive Business Architecture Maturity Model should evaluate three main categories: Reference, Execution, and Support.
- Reference refers to the ability to define the architecture (e.g., methodology, artifacts, and integration with other methodologies)
- Execution refers to elements that enable the development of the architecture (e.g., business architects, framework owner, and metrics)
- Support refers to organizational support of developing architecture (e.g., leadership, governance, and culture)
