Figure 6.

Integrated CMMI Products illustrates the relationship across

the CMMI products and systems. This integrated approach was designed to
reduce the "stove piping" of CMMI Performance Solution components.

Figure 6. Integrated CMMI Products

A CMMI architecture provides a flexible performance improvement model and

structure that can adapt to meet short- and long-term needs. The
architecture and substructures can accommodate existing and future models
and content.

The CMMI architecture is designed to minimize the size and complexity of the
model, yet not lose the ability to have extensive explanatory material for
advanced users who want an in-depth understanding of a topic area. This is
accomplished by providing an electronic format with links to external
informative material. This allows the informative material to be updated to
accommodate technical changes without having to update the core model.

This approach makes it possible for end users to design a view of the model
to meet their organization's performance improvement needs. This enables
the CMMI to be effective for a wide range of organizations, such as when the
model is used as a part of a supplier selection process only a subset of model
components may be critical for a specific supplier selection. The organization
can construct a custom view that fits those priorities, so they and their
potential suppliers know what is expected.

Historically, CMMI models focused separately on key process issues for

development, services, and suppliers. However, businesses rarely focus on
only one domain, for example, besides developing a product, a development
organization may also provide help desk services to end users. CMMI
provides a platform to integrate all applicable domains and views and is
extendable based on organizational and market needs. This integrated and
holistic approach to performance improvement allows organizations to focus
on the areas of improvement that they find most relevant.

The format of the PA content follows a common modular structure. Figure 7.

CMMI Model Structure shows the high-level overview of the modular
structure of the CMMI.

Figure 7. CMMI Model Structure

At the highest level, the CMMI is a container of PAs and composed of five
components, described in Figure 8. CMMI Component Structure.

Figure 8. CMMI Component Structure

This architecture provides a core model that contains material that applies to
any context, along with additional helpful information for organizations
wishing to understand and adopt the model, or use it in a specific context,
such as agile development, security, safety, etc. This modularization allows
the model to be extended and updated with new examples, technologies,
and methods without having to update the entire model.

View

Views may be subject to change over time. A view is a window into the
model which allows an organization or project to focus on what is important
to them or their organization. There are predefined views that an
organization can select. Or if none of the predefined views meet business
needs, organizations can construct their own custom view as shown
in Figure 9. CMMI Component Structure-Views. For example:

 An organization may be operating under two application domains,

software development and help desk services. The organization could
then choose the predefined views of CMMI Development (CMMI-DEV)
and CMMI Services (CMMI-SVC). And, if security was important to the
organization, CMMI Security (CMMI-SEC) could be easily included with
the other two model domains.

 An organization wanting to improve their work planning and

management capability could choose a view for the Planning and
Managing Work Capability Area (refer to Figure 11. Planning and
Managing Work Capability Area View) to help them manage and
improve their work planning performance

For more information regarding model views, refer to Appendix B: Predefined

Model Views – Maturity and Capability Levels.

Figure 9: CMMI Component Structure - Views

Constructing a view consists of selecting what CMMI components to include
in the view.

Domains

A domain is an organizing principle in the CMMI, including both the model

and appraisal method. Domains are functionally similar groupings of PAs that
are applicable or tailored to an organization's primary capabilities, e.g.,
development for systems engineering or product development. A domain is a
type of view within CMMI. The list of current domains in CMMI are defined
in Figure 10. Domain Descriptions.

Figure 10: Domain Descriptions

 Domain Capability Description

Data Governing and managing data and data quality

Development (DEV) Creating products or solutions, including hardware and

software, and their related components

People (PPL) Developing, retaining, and enabling the workforce to

accomplish objectives

Safety (SAF) Providing and maintaining safe products, services, and

other solutions

Security (SEC) Identifying and strengthening critical defenses and

increasing resilience against threats

Services (SVC) Building and delivering an intangible solution comprised

of activities or work

Suppliers (SPM) Managing a company, organization, or person that

supplies or provides products, services, or other
solutions

Virtual (VRT) Delivering products, services, or other solutions from

remote locations

Capability Area

A Capability Area is a group of related PAs that can provide improved

performance in the skills and activities of an organization or project. A
Capability Area view is a subset of the CMMI that describes a predefined set
of PAs that make up a specific Capability Area. Capability Areas are a type of
a view. Figure 11. Planning and Managing Work Capability Area
View illustrates a view of the Planning and Managing Work Capability Area.

Figure 11. Planning and Managing Work Capability Area View

Categories for Capability Areas

Categories are logical groups or views of related Capability Areas that

address common problems encountered by businesses when producing or
delivering solutions. One of the lessons learned from industry experience is
that creating small groups of similar topics in a list makes them easier to
understand and remember. Incorporating this approach into the CMMI
Performance Solutions ecosystem makes training and adoption more
effective. Additionally, the categories match a typical performance
improvement path, moving from doing simple tasks, to managing them to be
more efficient, to enabling them to be more effective, and finally to
continually improving them to achieve better performance. Categories are
types of views.

The categories are:

 Doing – Capability Areas for producing and delivering quality solutions

 Managing – Capability Areas for planning and managing

implementation of solutions

 Enabling – Capability Areas for supporting solution implementation and

delivery

 Improving – Capability Areas for sustaining and improving performance

Figure 12. Categories and Associated Capability Areas shows how the
Capability Areas are organized into the categories.

Figure 12. Categories and Associated Capability Areas

These category views help to prioritize, organize, and plan resources while
focusing attention on the most critical issues facing the business.

For example:

 Customer satisfaction is both a primary objective and a challenge for

most organizations. The Doing Category provides several sets of best
practices to consistently produce and deliver solutions that satisfy the
customer.
  For organizations that want to improve their planning capabilities, or
that have problems consistently planning and managing the work, the
Managing Category provides several sets of best practices to help
resolve these issues.

 Organizations typically have challenges in addressing complexity and

managing change. The Enabling Category provides a clear set of
approaches to control, decide, and communicate how complexity and
change are being addressed.

 Many organizations recognize a need to improve performance but lose

momentum and focus once marginal gains have been achieved. The
Improving Category enables effective and sustainable performance
improvement.

Practice Area (PA)

A PA is a set of practices that collectively describe the critical activities

needed to achieve a defined intent and value. PAs are composed of:

 Practice Area Name & Icon

 Required PA Information

o Intent - to explain what results and accomplishments are

expected as an outcome of the PA

o Value – business value achievable by adopting practices in the PA

o Additional Required Information - remaining description of the PA

which is important and useful to better understand the meaning
of the PA intent and required information and may not be present
for every PA. In some cases, this section includes required
information specific to a selected view when applicable.

 Explanatory PA Information

o Practice Summary

o Additional Information

o Related Practice Areas – The PAs reflected in this section

represent common relationships, but are not intended to be
reflective of all possible relationships

o Context Specific Information, if applicable

  Practice Groups

o Organizing structure for practices within a PA to support

understanding and implementation

o Practice groups allow for different ways of organizing similar

information and practices. For example, practice group levels can
be used to show increasing capability for performance and
organizational standardization. In other examples, practices may
be grouped by logical function, theme, or thread, e.g., ISO uses
clauses and sub clauses, which are similar organizing concepts
as practice groups.

Figure 13. Practice Area Organization shows a summary view of how

CMMI PAs are organized.

Figure 13. Practice Area Organization

Practice Group

Within PAs, the practices are organized into a set of practice group levels
labeled Level 1, Level 2, etc. which provide a path for performance
improvement.
Each practice group level builds on the previous levels by adding
new functionality or sophistication resulting in increased capability.

Figure 14. Practice Group Level Characteristics provides a brief

definition of the practice group levels.

Figure 14. Practice Group Level Characteristics

Each practice group level:

 Builds on the practices at lower levels

 Represents an increase in functionality and capability

 May add new functionality

Practice group levels include the following characteristics:

 Practice Group Level 1

o Processes are performed, but may not be recorded in a process

description

o Basic practices that describe an initial approach to addressing

the intent of the PA

o Not a complete set of practices to meeting the full intent of the

PA

o What you would expect to see from an organization or project

just starting the journey towards improvement

o Starts to focus on performance issues

 Practice Group Level 2

o Processes are performed in accordance with a recorded project

or work level process description

o Simple, but complete set of practices that address the full intent
of the PA

o Does not require the use of organizational assets or standards

o The intent of the set of practices can be met in various ways

based on the project

o Identifies and monitors project performance objectives

 Practice Group Level 3

o Processes are performed and managed in accordance with a

recorded organizational level process description

o Uses organizational standards and includes tailoring of processes

to address unique project and work characteristics

o Uses and contributes to organizational assets

o Manages both project and organizational performance

 Practice Group Level 4

 o Processes are performed, managed, and analyzed statistically
and quantitatively in accordance with a recorded organizational
level process description

o Use of statistical and other quantitative techniques to predict if

quality and process performance objectives will be achieved

o Understands special cause of variation statistically and manages

progress against quality and process performance objectives

 Practice Group Level 5

o Processes are optimized statistically and quantitatively in

accordance with a recorded organizational level process
description

o Use of statistical and other quantitative techniques to optimize

performance and enhance the achievement of objectives
including business, measurement and performance, and quality
and process performance objectives

o Understands common cause of variation, statistically and

manages improvement against quality and process performance
objectives

The order of the practices in each PA and group does not imply or require a
sequential order as performed in a process. Processes that meet the intent of
the PAs and practices may be performed iteratively, in parallel, or in any
other order that best meets the needs of an organization's business.

Practices

Similar to the structure of the PAs, the practices in the CMMI consists of:

1. Required Practice Information:

 Practice statement

 Value statement: Business value of using this component

 Additional required material that further describes the scope and intent
of the practice and supports clear and consistent understanding and
interpretation

2. Explanatory Practice Information:

 Additional Explanatory Information

  Example Activities

 Example Work Products

 Related Practice Areas, as needed

 Context Specific Information (there may be multiple context instances):

o Context specific identifier and description

o Additional informative material

Figure 15. Practice Area Versus Practice Structure provides a summary

of required and explanatory information for Practice Areas and practices.

Figure 15. Practice Area Versus Practice Structure

Language Conventions: In the CMMI Performance Solutions ecosystem,

when the term "or" appears, it is used in the inclusive sense, and can mean
both "and" as well as "or":

 "and" as in "manage plans and activities" can mean managing both

plans AND managing activities

 "or" as in "manage risks or opportunities" can mean managing either

risks OR opportunities OR both

Certain words in the CMMI Performance Solutions ecosystem have special

meaning. When applicable, that term is included in the glossary. Otherwise,
the common English meaning, e.g., Webster or Oxford dictionary applies.
Additional Content Characteristics

For more effective identification, recall, and learning, each PA includes an

identification icon used for multiple purposes, including:

 Showing relationships

 Training

 Online selection buttons or tiles

 Sorting and grouping practices

 Memory aides

For each icon, there are three primary elements:

 The shape and color of the outline of the icon, e.g., square, triangular
which denotes the Capability Area associated with the PA

 Within the shape, a unique pictorial icon representing the intent of the
PA

 The acronym for the PA

For example, Figure 16. Example Icon, DAR is the icon for Decision
Analysis and Resolution (DAR), included in the Supporting Implementation
Capability Area. For more information about Capability Areas, refer
to Appendix A: Core Practice Areas, Categories, and Capability Areas..

Figure 16. Example Icon, DAR

Figure 17. Model Content Relationships shows the complete set of

relationships between the categories, Capability Areas, and PAs.

Figure 17. Model Content Relationships

Explanatory Versus Context Specific

The CMMI does not imply any specific methodology, work product type, or
implementation and is not a recipe or a "one size fits all" checklist. The
model is not a set of implementable processes. This means that each project
or organization must understand how to implement their processes to
address their unique situation. Organizations with different disciplines,
different business activities, and different organizational structures or sizes
should apply the model practices within their own contexts. Practice
statements are designed and written to be clear, unambiguous, and
applicable to any context. The informative material, including the context
specific sections, helps with this understanding, and must not be ignored.

Within the CMMI there are two types of informative

material: "explanatory" and "context specific".

The "Explanatory Information" section contains information describing a

model component and applies to all contexts. Explanatory information
material aids users in understanding the intent and business value. The
example activities and work products are neither prescriptive nor exhaustive.
Consider other work products and activities that meet the intent of the
practice when implementing processes. The explanatory information may
include six areas of information:

 Additional Explanatory Information

 Example Activities

 Example Work Products

 Related Practice Areas

 External links or information e.g., training, templates, example assets

 Context Specific – refer to additional details below

The "Context Specific" section contains information that is relevant for a

specific industry, methodology, or discipline. The Context Specific
information includes:

 Context Tag; provides identifier

 Context; provides explanation of industry methodology or discipline

  Explanatory information

Examples of contexts include:

 Agile Development

 Data

 Development

 DevSecOps

 People

 Security

 Safety

 Services

 Suppliers

Additionally, the architecture supports adding other context specific

informative material, including implementation guidance for domains such
as:

 Information Technology

 Cybersecurity

 Healthcare, e.g., medical devices, pharmaceuticals, healthcare

providers

 Telecommunications

 Aerospace

 Finance

 Transportation

 Education

 Government

 Hospitality

 Consulting

The architecture also works with and supports other methodologies,

standards, or models such as:
 AS9100

 Automotive SPICE

 COBIT

 ISO

 ITIL

 Kanban

 Lean

 NIST