Architecture Maturity Models










PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download
.

Architecture Maturity Models

by Geoff Keston

Docid: 00011240

Publication Date: 2003

Report Type: TUTORIAL

Preview

An Architectural Maturity Model (AMM) is an analytic approach that
evaluates the present state of an organization’s infrastructure in order
to suggest how it may grow toward increased efficiency
and effectiveness. The basis of the AMM, the Capability Maturity Model
(CMM), was developed by the Software Engineering Institute (SEI), but
iterations of all sizes and costs exist and are often offered as a free
assessment tool by vendors seeking a contractual relationship.

Report Contents:

Executive Summary

[return to top of this
report]

An Architecture Maturity Model (AMM) is a series of descriptive steps
designed to help an organization progress to full efficiency and
effectiveness in its information architecture. It is essentially the
result of an evaluation of the architecture of an organization. 

 

Related
Faulkner Reports
Strategic Capabilities
Architecture Tutorial
Service Oriented
Architecture Platforms Tutorial
Service Oriented
Architecture Tutorial

The AMM and related concepts, for example the Architecture Capability
Maturity Model (ACMM), are in turn based on the higher order of Capability
Maturity Models (CMM) that were first developed and used extensively for
avionics software and for government projects but are now in more general
use.

Whether referred to as an AMM, ACMM, or CMM, maturity models are not a
specific technology. They are structured sets of elements that describe
characteristics of effective processes as currently found in the
enterprise, frequently combined with ratings and/or evaluations of those
processes. Used as benchmarks for assessing organizations in relation
to others that are comparable, maturity models provide developers and
organizations with the ability to gain control over and improve their IT
related development processes. They also provide talking points for vendor
proposals.

AMMs and CMMs can span a variety of characteristics of software, software
acquisition, systems engineering, and integrated product development.
They have proven useful to many organizations. However, the use of
multiple models can provide a challenge; multiple models must also
include a methodology for integration within and across an organization.

Description

[return to top of this
report]

An Architectural Maturity Model (AMM), a type of Capability Maturity
Model (CMM), is a tool for organizational analysis and improvement.
Typically an AMM consists of several descriptive steps (often five),
sometimes labeled both with formal names and easily grasped
descriptive nicknames (for example, “Basic, Burgeoning, Blossoming,
Beneficial, Brilliant”), each representing a stage of increasing
sophistication in corporate operations. Ordinarily the findings of the AMM
are based on information provided by the organization through
questionnaires, meetings, interviews, documentation reviews, and similar
methods.

Implicit in the AMM is the concept of change, without which the
organization will necessarily remain at its present level. Managing change
effectively within the IT environment can therefore be the determinative
factor in moving “up” the stops of an AMM. AMMs
and CMMs can serve as models by which organizations can target both
financial and human resources and better determine how to proceed in
focusing on multiple or parallel process improvement efforts.

An Architecture Maturity Model is useful in helping an IT organization
to:

  • Define a path of change in order to improve a particular function
    or functions
  • Provide benchmarks by which to measure improvement
  • Provide a framework for managing the effects of changes

An AMM addresses the issue of gauging the relevance of process
improvement. It can help provide control over the IT related
development processes of an organization by identifying the network’s
level of software or architectural maturity, based on previously developed
standards. This process of identification can be a one-time event, but
optimally the business should employ the AMM as part of a continuous,
cyclical process.

The CMM Cycle

The AMM is a form of Capability Maturity Model (CMM) first developed at
Carnegie Mellon University by the Software Engineering Institute (SEI) of
the US Department of Defense and initially made public in 1989. An AMM, or
any CMM, is used to measure the maturity of the development process or
architecture at an organization. Depending on the source and purpose of a
maturity model, it is generally accepted that the maturity of an
organization, software, or architectural process is really a continuous
cycle, which is to say that an enterprise needs continuous process
improvement. The nomenclature of the AMM varies among organizations and
vendors, public and private, but generally the stages of a CMM follow
those illustrated in Figure 1, which depicts the capability maturity model
cycle:

Figure 1. The Capability Maturity Model Cycle

Figure 1. The Capability Maturity Model Cycle

Source: Faulkner Information Services

Initial

In the Initial, or ” lowest,” phase of a CMM, processes and architectures
are usually ad hoc, and the organization’s efforts in the area being
studied may be somewhat unstable. Success depends on the competence of the
organization and of individuals within the organization and not on proven
processes. At this level there is little or no strategic planning, and
little or no formal adherence to existing standards. In spite of this ad
hoc, fundamentally chaotic environment, the Initial stage often produces
products and services that succeed, as is often seen in startups. However,
such organizations frequently exceed the budget and schedule of their
projects. Unpredictable project schedules, budget overruns, and poor
quality code are also characteristic of Initial organizations.

Managed

In the Managed phase of a CMM, some elements of architecture efforts
emerge, and processes or architectures from previous projects may be
repeated or reused. The cost of delivering software is reduced through
reuse, as ad hoc processes and chaotic lines of communication begin to
stabilize. Practices begin to emerge and project management methodologies
begin to take hold. Adherence to or the development of standards begins
here. Basic project management processes are established to track cost,
schedule, and functionality. The necessary process discipline is in place
to repeat earlier successes on projects with similar applications.

Defined

In the Defined phase of a CMM, processes are well characterized and
understood, and are documented in standards, procedures, tools, guidelines
and methods. This documentation is used to establish consistency across
the organization. Projects are established using the organization’s set of
standard guidelines. Objectives are established based on the
organization’s documented guidelines, providing criteria for
development and improvement. Cost and project management processes
are tracked through cost-benefit analysis as a determinant for
investment.

The scope of the standards, process descriptions, and procedures may vary
greatly depending on the nature of a particular project. However they are
defined, they are implemented through repeatable or reusable
experiences.

Because the activities in this phase are governed by written processes
and procedures, many organizations assume that they have reached the
highest level of maturity at this point, and are surprised to find that
further growth is possible. Some companies simply stop at this point, a
practice not possible in some bidding situations.

Quantitatively Managed

In the Quantitatively Managed phase of a CMM, precision and
predictability are the key words. Using precise measurements developed and
gained from the experiences of the previous processes, management can
effectively control software or architectural development. 

Here, all participants are sought out for buy-in, and
development/architectural processes are now part of the organization’s
culture. Investment and cost/benefit analysis are governed by the IT
architecture, process, or culture. Performance processes are monitored
using statistical and quantitative analysis and are quantifiably
predictable. This differs from the Defined phase, where processes are
evaluated on a more qualitative than quantitative basis. This stage would
be the ultimate goal of the AMM if not for the importance of continual
process improvement.

Optimizing

In the Optimizing phase of a CMM, continual process improvements are
accomplished through innovative technologies, which may be
implemented incrementally. It will be noted that continual
improvement is a tenet of many process improvement approaches, with Six
Sigma a prominent example. In this stage, processes and policies are
mandated by the organization, offering clear recognition of the value of
process and architectures. Objectives for process improvement are
quantitative and are revised with regularity to reflect changes in
business objectives. The workforce is empowered to respond with quickness
and agility when addressing changes and meeting opportunities. Processes
are defined to address causes of process variation and to change
procedures to improve performance and to meet established quantitative
process-improvement objectives.

Capability Maturity Models Integration

More than one maturity model may be used within a single organization.
Theoretically this might lead to the additional problem of how to
integrate different maturity models to produce a meaningful process
improvement result, and this possibility must be kept in mind.

Originally the Capability Maturity Models developed and supported by the
SEI included the:

  • Capability Maturity Model for Software (SW-CMM)
  • Systems Engineering Capability Model (SECM)
  • Integrated Product Development Maturity Model (IPD-CMM)

In 2000, the SEI replaced these models with the more extensive Capability
Maturity Model Integration (CMMI). CMMI is a process improvement approach
that can be used to guide process improvement across a project, a
division, or an entire organization, clarifying the disparate capability
models that each entity may be using. CMMI helps to integrate
traditionally separate organizational functions, set process improvement
goals and priorities, provide guidance for quality processes, and set a
point of reference for appraising current processes. Under the auspices of
Carnegie Mellon Institute, CMMI is frequently required in government
bidding competitions.

The use of CMMI models improves on the best practices of the
previous source models by enabling organizations to better:

  • Link management and engineering activities to business objectives
  • Expand the scope of and visibility into the product life cycle and
    engineering activities to ensure that the product or service meets
    customer expectations
  • Incorporate lessons learned from additional areas of best practice
    (e.g., measurement, risk management, and supplier management)
  • Implement more robust high-maturity practices
  • Address additional organizational functions critical to its products
    and services
  • Comply with relevant ISO standards

Current View

[return to top of this
report]

AMMs were initially developed to give the Department of Defense a
yardstick by which to assess and describe the capability of software
contractors to provide software on time, within budget, and in conformity
with acceptable standards, in order to be eligible for defense contracts.
Today, implementing CMMs in order to obtain defense contracts, and most
other government contracts, is mandatory.

Although statistics are not available for use of AMMs, CMMs have experienced increasingly widespread use. As
noted above, initially in the United States they were primarily employed for
government processes, particularly those involving defense, but numerous
non-governmental organizations now employ AMMs.

With the push by the federal government for adoption of the Federal
Enterprise Architecture (FEA) initiative, AMMs and CMMs are commonly
viewed as models by which organizations, either government or
non-government, can gauge the maturity of applications and processes, as
well as how close to FEA compliance they may be. As a tool for
standardizing outsourcing and software development work, CMMs have been
used by economic development agencies in India, Ireland, Egypt, and
elsewhere, as well as in the US.

There has been considerable discussion about the relation between CMMs
and agile programming. On the one hand, CMMs seem to place a premium on
standardized processes, since they are based on benchmarks, and this
appears to contradict the agile programming model. On the other hand,
agile programming and CMM have the same goal: the efficient design
and operation of the enterprise. The means by which those goals are
achieved may vary from situation to situation without violating the
principles of the AMM. Therefore the current opinion overwhelmingly is
that there is no basic contradiction between CMMs and agile programming.

There are various maturity models to choose from, open and commercial. A well-established option is the
Open Group’s TOGAF, which was first released in 1995. TOGAF consists of
six modules, which can be implemented together as a framework or
individually as standalone parts.

There are also two models, from IBM and
Gartner, focused on data governance.1 And there is a model for software-as-a-service architecture offered by Microsoft.2

Outlook

[return to top of this
report]

Some vendors use AMMs as tools to help them craft work
proposals. Typically an AMM uses terminology developed by the vendor,
although the principles are likely to correspond in general to those of
the CMMI, and the vendor may use the analysis to try to steer business its
way.

An AMM is well suited for bureaucratic organizations such as government
agencies, large corporations, and regulated monopolies, but it is also
useful for smaller enterprises or organizations, and their use of AMMs is
increasing. Larger organizations may employ CMM auditors who report their
results directly to the executive level, a practice encouraged by SEI but
by no means mandatory. Any rigorous assessment of processes and procedures
will benefit an organization.

CMMI has been characterized as heavily bureaucratic, emphasizing
processes over deliverables. The SEI does not release information about specific
companies that have been appraised, although appraisers are required to
file records of their final assessments with the institute. As a result,
the possibility of false claims for AMMs exists. This may be particularly
important as the outsourcing of development work increases.

Recommendations

[return to top of this
report]

An AMM is often a useful analytical tool and may help to guide the
enterprise in developing its processes and procedures. At a minimum, it
can bring perspective and an analytic viewpoint to the processes of the
organization. 

While IT departments continually look for ways to be more cost-effective, an AMM
is not primarily a device for reducing costs. An AMM is a tool
for creating more effective processes, not necessarily for creating less
expensive ones. However, as with any process improvement, cost
savings may result as well. 

Developing an AMM does not have to be expensive; vendors may offer
different prices according to the level of service obtained, so initial
estimates may be reasonable. Some vendors will offer an AMM analysis
without cost as part of the effort to obtain a contract with the
organization. Proposals that involve considerable cost should be evaluated
based on the size and complexity of the organization, since, in the case
of an AMM, price may exceed value. 

There
are also downsides of using a maturity model to consider.3 Reaching the
top level can give an organization a false sense of completing a goal,
while in fact systems should always continue to evolve.4 Also, the
cut-and-dried five-step progression depicted in many models is overly
simplified and does not present a true picture of the complex,
non-linear development of real-world systems.5

There is no substitute for due diligence concerning the viability of
an AMM claim by a potential vendor, including offshore companies. There
seems to be little or no interest in the industry’s policing itself,
and even if there were, it is not clear that such self-policing would
be effective. The enterprise should not be overly impressed by sweeping
proposals for AMMs, particularly for those whose costs are out of
proportion to the size of the enterprise, or for facile claims that a
company scores highly on the AMM. Such claims should be verified and
not taken at face value.

On the other hand, to compete for outsourced government projects, an
analysis using an AMM may sometimes be mandatory. The
increasing complexity of contractual relationships with both onshore and
offshore companies means that AMM assessments may have to be
collaborative. Again, an attitude of “buyer beware” will make the
difference between a successful venture into an AMM or any CMM, and a not
so pleasant experience.

References

[return to top of this
report]

1 Kelsey Taylor. “Data Governance Maturity Model.” HiTechNectar.

2 Mori Kabiri. “What Is
the SaaS Architecture Maturity Model?” Forbes. November 20, 2019.

3 Ben Morris. “The Case Against Maturity Models.” Benmorris.com. June 8, 2019.

4
Ibid.

5 Ibid.

[return to top of this
report]

About the Author

[return to top of this
report]

Geoff
Keston

is the author of more
than 250 articles that help organizations find opportunities in
business trends and
technology. He also works directly with clients to develop
communications strategies that improve processes and customer
relationships. Mr. Keston has worked as a project manager for a major
technology consulting and services company and is a Microsoft Certified
Systems Engineer and a Certified Novell Administrator.

[return to top of this
report]