ITIL and CMMI synergies

CMMI has been developed by the Carnegie Mellon University – Software Engineering Institute. It consists of best practices that address the development and maintenance of products and services covering the product life cycle from conception through delivery and maintenance.

A product can be an airplane, a digital camera, a drug or a software package available from a commercial retailer. It can also be a Service such as those defined into IT Service Management. CMMI integrates bodies of knowledge that are essential when developing products, but that have been addressed separately in the past, such as software engineering, systems engineering, and acquisition.

CMMI:
- Emphasizes the development of processes to improve product development and customer services in organizations.
- Provides a framework from which to organize and prioritize process improvement activities (product, business, people, technology)
- Supports the coordination of multi-disciplined activities that may be required to successfully build a product
- Emphasizes the alignment of process improvement efforts objectives with organizational business objectives

A CCMI model is not a process but describes the characteristics of effective processes. CCMI models should be used in conjunction with a company’s IT processes found in Service Management (ITIL), COBIT, Project Management (SDLC/Prince 2), Enterprise Architecture (TOGAF), Quality (ISO 9000), Security Management (ISO 27001). CMMi allows companies to assess their practices and compare them to those of other companies. The CMMi measures process maturity, progresses through five levels: Level 1 (initial), 2 (managed), 3 (defined), 4 (predictable) and 5 (optimizing).

CMMi is an important component of an IT Governance framework and has to be considered as a project.

Implementing CMMI and ITIL improves the Software Development Process and Software Quality and reduces the Cost Of Quality (COQ). In addition is time to market reduced and precision in estimation of effort and cost enhanced.

ITIL can combine with CMMI to cover all of IT, but doesn't address the development of quality management systems. Also it is not geared to software development processes and its use is highly dependent on interpretation. While CMMi is the de facto quality standard for software development processes, ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT Services.

ITIL and CMMI best apply to different parts of the IT organization:

- Use CMMI in application development
- Use CMMI in ICT Infrastructure projects
- Use ITIL in IT operations and services

CMMi is very detailed. It is geared specifically to software development organizations, and focuses on continuous improvement, not just on maintaining a certification. It also can be used for self-assessment.

However it doesn't address IT operations issues, such as security, change and configuration management, capacity planning, troubleshooting and service desk functions. This is why ITIL is used. CMMi sets goals, but doesn't say how to meet them. (For example, CMMI says to do requirements analysis but doesn't say how to do requirements analysis.) This is why we would use a Project Management methodology.

Important observations

The focus for CMMi is software development, integration, deployment and maintenance, while the focus for ITIL is service management/operations. In reviewing, the touch points between the two , the amount of duplication is small in comparison to the number of interfaces and touch
points. This suggests the need for:

- strongly synchronized work efforts
- clear definition of interfaces, roles, and responsibilities
- participation from both efforts at a level appropriate to the density of the touch points (e.g., joint process action team membership, subject matter expert guidance, and/or process reviewer)
- By identifying the touch points between the groups, and promoting best practices using the CMMI and ITIL in their respective areas, the organization can leverage expertise and experience from within and from without .
- The most significant touch point should be documented in the area of Configuration and Change Management. There is no contradiction between the two models (CMMI and ITIL), so the teams should develop a unified process (‘the what’), with targeted procedures (‘the how’).
- In CMMI, the Process Areas are ordered along a Maturity Model with maturity levels. The ITIL processes are ordered in sets.

Enterprise Architecture and change management

An Enterprise Architecture should be fully revised on an annual basis to incorporate new or changed standards, evaluate new technologies and realign with changing business priorities. Architecture will never be "complete" in the sense that it should be constantly reviewed and revised, and related efforts realigned. As the business grows and evolves, so should the architecture governing its systems and processes. Just like the business itself, the architecture must remain dynamic and able to change with the demands of the business environment.

An Enterprise Architecture core team (EACT) or one if its domain teams may propose amendments in mid-cycle. Such amendments must be approved by an EA Governance Board, which will issue an EA amendment bulletin. All amendments must be incorporated into the EA through the next revision cycle.

The EACT is responsible for creating EA and revising it each year as recommended in TOGAF. Industry analysts and subject matter experts should be involved as needed in the process.

The EA is updated at least on an annual basis to:

1 Incorporate amendments that were previously approved
2 Incorporate new technical standards, patterns and services, information, solutions, and business processes
3 Evolve the future-state road maps to reflect changes in business strategy

The structured architecture creation/revision process should be defined by the EACT and approved by the EA Governance Board.

An Architecture review and approval process should be designed.

The FEAF defines the external component of the Framework representing an external stimulus, which causes the enterprise architecture to change. The architecture drivers consist of two
sub-components: business and design drivers, but this does not specify precisely the process.

Phase H of TOGAF ADM is referring to a change management process which could be related to the ITIL Change Management process or PRINCE 2. Obviously this would make perfectly sense to “re-use” the ITSM Change Management process for architecture changes.

One of the activities in Change Management is the Change Advisory Board (CAB) Meetings (to be noted that this committee should have also a member from the Enterprise Architecture team). There should be some synergies with the EA Governance Board as well. The approval from the architects should be a pre-requisite before submitting an RFC to the CAB when needed.

However the EA Change Management process could slightly differ as stakeholders could be different. The EAGB, the IT executive management team and the EACT being the main actors in the EA Change management process.

To be noted that shortly a white paper will be published by the Open Group on the integration between TOGAF and ITIL.