Analyse in Relation between ITIL,COBIT,CMMI and TOGAF


Analysing The Relation in Between ITIL, Cobit, Togaf and CMMI

The relation of enterprise architecture with some wellknown  management practices in each of these areas:

1.IT Governance:COBIT

2.IT Service Delivery and Support:ITIL

3.IT Implementation:CMMI

4.A framework for developing  an enterprise architecture:TOGAF

1.ITIL(IT Infrastructure Library)

ITIL is a public(operational)  framework that describes Best Practice in IT service management.It provides a framework for the governance of IT, the ‘service wrap‘, and focuses on the continual measurement and improvement of the quality of IT service delivered, from both a business and a customer perspective. This focus is a major factor in ITIL‘s worldwide success and has contributed to its prolific usage and to the key benefits obtained by those organizations deploying the techniques and processes throughout their organizations.

Some of these benefits include:

  • increased user and customer satisfaction with IT services
  • improved service availability, directly leading to increased business profits and revenue
  • financial savings from reduced rework, lost time, enhanced resource management and usage
  • shorter time to market for new products and services
  • improved decision making and optimized risk.

ITIL was published between 1989 and 1995 by Her Majesty‘s Stationery Office (HMSO) in the UK on behalf of the Central Communications  andTelecommunications Agency (CCTA).Its early use was principally confined to the UK and Netherlands. A second version of ITIL was published as a set of revised books between 2000 and 2004.


The initial version of ITIL consisted of a library of 31 associated books covering all aspects of IT service provision. This initial version was then revised and replaced by seven, more closely connected and consistent books (ITIL V2) consolidated within an overall framework. This second version became universally accepted and is now used in many countries by thousands of organizations as the basis for effective IT service provision. In 2007, ITIL V2 was superseded by an enhanced and consolidated third version of ITIL, consisting of five core books covering the service lifecycle.

The five core books cover each stage of the ITIL Service Lifecycle from the initial definition and analysis of business requirements in Service Strategy and Service Design, through migration into the live environment within Service Transition, to live operation and improvement in Service Operation and Continual Service Improvement.



ITIL Life Cycle

All service solutions and activities should be driven by business needs and requirements. Within this context they must also reflect the strategies and policies of the service provider organization, as indicated in below:



The diagram illustrates how the service lifecycle is initiated from a change in requirements in the business.

These requirements are identified and agreed within the Service Strategy stage within a Service Level Package (SLP) and a defined set of business outcomes. This passes to the Service Design stage where a service solution is produced together with a Service Design Package (SDP) containing everything necessary to take this service through the remaining stages of the lifecycle.

  • Structure of ITIL

The current version of ITIL (Version 3)  provides a Service Lifecycle structure and is organized into five high-level core disciplines described in five core books:

  1. Service Strategy
  2. Service Design
  3. Service Transition
  4. Service Operation
  5. Continual Service Improvement

ITIL V3 is best understood as seeking to implement feedback-loops by arranging processes in a circular way. Also, that the old structure of Version 2 was replaced, but most processes and function are still available in V3.

The figure below shows an overview of the 5 core disciplines and their related processes and functions


The core processes of IT service management are described within two ITIL documents: Service Support and Service Delivery.

The processes of Service Support are:

  • Incident management
  • Problem management
  • Configuration management
  • Change management
  • Release management

The key practices of Service Delivery are:

  • Service level management
  • Financial management for IT services
  • Capacity management
  • IT service continuity management
  • Availability management
  • ITIL (IT Infrastructure Library) is the most widely accepted set of best practices in the IT service delivery domain and is complementary to COBIT.


Control Objectives for Information and Related Technology (CobiT) is the most holistic, internationally recognized framework aimed at achieving organizational information technology goals and objectives, developed and maintained since 1996 by IT Governance Institute – an organization tightly cooperating with Information Systems Audit and Control Association (ISACA). Being a model of IT governance and information systems audit and control, CobiT is designed to provide effectiveness and efficiency while mitigating the risks connected with the use of IT based solutions.

The framework is fully process-oriented and measurement driven. Its structure provides a definition and measurement tools for assessing IT related organizational control objectives. CobiT evolved as a set of good practices, which confirms its business applicability.

2.1 Structure of COBIT

The CobiT framework, on its highest level, constitutes a three-dimensional structure consisting of:

(1) Business requirements (information criteria): effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability

(2) IT resources: applications, information, infrastructure, people and

(3) IT processes (structured into domains, processes and people)

The relationships between these components are illustrated by a so-called CobiT cube


All  processes are grouped within four domains (each abbreviated by two capital letters):

PO :Plan and Organise,

AI :Acquire and Implement,

DS :Deliver and Support

ME :Monitor and Evaluate.

The PO domain includes 10 processes responsible for the definition, realization and communicating of IT strategy across the organization. These processes are the following: PO1 Define a Strategic IT Plan, PO2 Define the Information Architecture, PO3 Determine Technological Direction, PO4 Define the IT Processes, Organisation and Relationships, PO5 Manage the IT Investment, PO6 Communicate Management Aims and Direction, PO7 Manage IT Human Resources, PO8 Manage Quality, PO9 Assess and Manage IT Risks,PO10 Manage Projects.

All domain groups 7 processes aimed at implementing and procuring the necessary means and resources for implementing IT strategy. AI domain includes the following processes: AI1 Identify Automated Solutions, AI2 Acquire and Maintain Application Software, AI3 Acquire and Maintain Technology Infrastructure, AI4 Enable Operation and Use, AI5 Procure IT Resources, AI6 Manage Changes, AI7 Install and Accredit Solutions and Changes.

The main goal of the DS domain is to deliver defined IT services and is made up of the following 13 processes: DS1 Define and Manage Service Levels, DS2 Manage Third-party Services, DS3 Manage Performance and Capacity, DS4 Ensure Continuous Service, DS5 Ensure Systems Security, DS6 Identify and Allocate Costs, DS7 Educate and Train Users, DS8 Manage Service Desk and Incidents, DS9 Manage the Configuration, DS10 Manage Problems, DS11 Manage Data, DS12 Manage the Physical Environment, DS13 Manage Operations.

    The last ME domain is designed to assess the quality and compliance of all processes with their control requirements over time. It includes the following 4 processes: ME1 Monitor and Evaluate IT Performance, ME2 Monitor and Evaluate Internal Control, ME3 Ensure Compliance With External Requirements and ME4 Provide IT Governance.

2.2 Functional Patterns of Cobit

Each process of every CobiT domain is explained by the following description:

  1. Information criteria affected by the process (primary, secondary or not addressed);
  2. Control objectives fulfilling defined process goals by critical success factors (CSFs) and measured by key goal indicators (KGIs) and key performance indicators (KPIs) and list of supporting activities (sub-processes);
  3. IT resources used by the process;
  4. IT governance focus areas: strategic alignment, value delivery, risk management, resource management and performance management – each marked if it is primary, secondary or not addressed;
  5. Management guidelines including listing of other CobiT processes constituting input and output of the process, RACI chart, describing who is responsible/accountable/consulted and/or informed when performing a specific activity and a detailed chart of goals and metrics.


Information delivered to the core business processes has to fulfill certain criteria, which are summarily characterised as follows:

  • Quality requirements:

Effectiveness:Deals with information being relevant and pertinent to the business process as well as being delivered in a timely, correct, consistent and usable manner

– Efficiency: Concerns the provision of information through the optimal (most productive and economical) use of resources

  • Security requirements:

Confidentiality: Concerns the protection of sensitive information from unauthorised disclosure – Integrity: Relates to the accuracy and completeness of information, as well as to its validity in accordance with business values and expectations

Availability: Relates to information being available when required by the business process now and in the future. It also concerns the safeguarding of necessary resources and associated capabilities.

  • Fiduciary requirements:

Compliance:Deals with complying with those laws, regulations and contractual arrangements to which the business process is subject, i.e., externally imposed business criteria, as well as internal policies

– Reliability:Relates to the provision of appropriate information for management to operate the entity and exercise its fiduciary and governance responsibilities


COBIT defines, the resources used by IT as follows:

  • Applications are automated user systems and manual procedures that process the information.
  • Information is the data (in all their forms) input, processed and output by the information systems in whatever form is used by the business.
  • Infrastructure is the technology and facilities (hardware, operating systems, database management systems, networking, multimedia, etc., and the environment that houses and supports them) that enable the processing of the applications.
  • People are the personnel required to plan, organise, acquire, implement, deliver, support, monitor and evaluate the information systems and services. They may be internal, outsourced or contracted as required.

2.3 Intersections with Other Frameworks

CobiT as the most holistic IT/IS framework concentrates more on “what”to do than on “how” to do it. For this reason it delegates “how-to-do” related issues to other tools, frameworks and methodologies.

There are various documents within the CobiT library describing the mapping of CobiT concepts and structure to other frameworks and standards. These documents include mapping CobiT to: ITIL,  CMMI, TOGAF and others. Below are some main concepts connected with CobiT mapping to other frameworks mentioned in this document: ITIL and CMMI are described.


– Mapping CobiT Processes to ITIL


Mapping CobiT Information Criteria and IT Resources to ITIL


-Mapping CobiT IT Governance Focus to ITIL

CobiT interlaces with ITIL primarily in DS and AI domains; however processes from other domains are also significant to a certain degree. Also other concepts like information criteria, information resources and IT governance focus are mapped to some extent.

CobiT/CMMI mapping is concerned with some concepts pertaining to process improvement for development activities, the implementation, acquisition and maintenance of systems and software products. CobiT also widely utilizes original CMMI concept e.g. maturity models.

CMMI maps all processes of the All domain and some processes of remaining domains. Also other concepts like information criteria and information resources are mapped to some extent. The following pictures describe CobiT/CMMI mapping in a greater detail.                             

– Mapping CobiT Processes to CMMI

-Mapping CobiT Information Criteria and IT Resources to CMMI

 Neither ITIL nor CMMI are CobiT alternatives but rather frameworks that help to fulfil CobiT requirements at a lower level.


TOGAF(The Open Group Architecture Framework)  is an architecture framework. TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

ISO/IEC 42010:2007 defines “architecture” as:

“The fundamental organization of a system, embodied in its components, their relationships to each     other and the environment, and the principles governing its design and evolution.”

TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology. In TOGAF, “architecture” has two meanings depending upon the context:

  1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:

  • The Business Architecturedefines the business strategy, governance, organization, and key business processes.
  • The Data Architecturedescribes the structure of an organization’s logical and physical data assets and data management resources.
  • The Application Architectureprovides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
  • The Technology Architecturedescribes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

3.1.Architecture Development Method

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.

All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.

Phases within the ADM are as follows:

  • The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles.
  • Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development.
  • Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision.
  • Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision.
  • Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision.
  • Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.
  • Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.
  • Phase G: Implementation Governance provides an architectural oversight of the implementation.
  • Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
  • Requirements Management examines the process of managing architecture requirements throughout the ADM.

Using TOGAF with Other Frameworks

Two of the key elements of any enterprise architecture framework are:

  • A definition of the deliverables that the architecting activity should produce
  • A description of the method by which this should be done

With some exceptions, the majority of enterprise architecture frameworks focus on the first of these – the specific set of deliverables – and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).

Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.

As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.

In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP. Guidelines for adapting the TOGAF ADM in such a way are given in

As a generic framework and method for enterprise architecture, TOGAF provides the capability and the collaborative environment to integrate with other frameworks. Organizations are able to fully utilize vertical business domains, horizontal technology areas (such as security or manageability), or application areas (such as e-Commerce) to produce a competitive enterprise architecture framework which maximizes their business opportunities.

The Benefits:

A successful enterprise architecture offers your business many benefits and opportunities:

  • The architecture supports both the business strategy and the business model.
  • The architecture is flexible enough to respond to new market requirements and changes.
  • The architecture guarantees an optimum basis for business intelligence.
  • The complexity of the architecture and therefore of the IT is reduced.
  • The advantages and disadvantages of various architectures are known.

Business Needs and Challenges:

  • Infrastructure and Security
  • Business Technology
  • Technology Transformation
  • Cost Optimization
  • Global Sourcing
  • CloudComputing



The Capability Maturity Model Integration (CMMI) project is a collaborative effort to provide models for achieving product and process improvement. The primary focus of the project is to build tools to support improvement of processes used to develop and sustain systems and products. The output of the CMMI project is a suite of products, which provides an integrated approach across the enterprise for improving processes, while reducing the redundancy, complexity and cost resulting from the use of separate and multiple capability maturity models (CMMs).

The CMMI helps us understand the answer to the question “how do we know?”

  • How do we know what we are good at?
  • How do we know if we’re improving?
  • How do we know if the process we use is working well?
  • How do we know if our requirements change process is useful?
  • How do we know if our products are as good as they can be?

The CMMI also helps us identify and achieve measurable business goals, build better products, keep customers happier, and ensure that we are working as efficiently as possible.

Background of CMMI

The CMMI was developed at the Software Engineering Institute at Carnegie Mellon University with representation from defense, industry, government, and academia, and is now operated and maintained by the CMMI Institute, an operating unit of CMU. It is the successor of the popular Software CMM, or SW-CMM. The are multiple “flavors” of the CMMI, called “Constellations,” that include CMMI for Development (CMMI-DEV), CMMI for Services (CMMI-SVC), and CMMI for Acquisition (CMMI-ACQ). The three Constellations share a core set of sixteen Process Areas. There is also a “People CMM,”  or P-CMM, that exists outside of the three CMMI Constellations.


              There are five Maturity Levels in the CMMI


The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the appraisal method that is employed by a Certified SCAMPI Lead Appraiser to help your team “achieve a level.” There are three different types of appraisals, called “Classes” and they are SCAMPI A, SCAMPI B, or SCAMPI C. The SCAMPI A is the only appraisal method that results in a Maturity or Capability Level Rating. A SCAMPI C is typically used as a gap analysis and data collection tool, and the SCAMPI B is often employed as a User Acceptance or “test” appraisal. The results of a SCAMPI A Appraisal are published on the CMMI Institute Website known as “PARS” and is available for viewing by the public. Only a Certified SCAMPI Lead Appraiser can conduct a SCAMPI A Appraisal.


There are three classes of Appraisals – only the “Class A” results in a “Rating”

CMMI Architecture

The CMMI for Development has twenty-two process areas, and the CMMI for Services has twenty-four. The CMMI can be used in either the “staged” or “continuous” representation. The staged representation, which groups process areas into five “maturity levels,” is the most common choice, but an organization can also pick and choose the Process Areas that make the most sense for them to work on by using the “continuous representation.”

There is no difference in content between these two representations. When choosing “Staged” an organization follows a pre-defined pattern of process areas that are organized by “Maturity Level.” When choosing continuous, they pick process areas based on their interest in improving only specific areas. In the Continuous representation, Process Areas are organized by “Category.”

Within the Process Areas in the CMMI, there are multiple “Specific Goals ” and Specific Practices.” These practices define the expected behaviors of projects and organizations.

There are also twelve “Generic Practices ” that provide guidance for organizational excellence including behaviors such as setting expectations, training, measuring quality, monitoring process performance, and evaluating compliance.


The are twenty-two Process Areas in the CMMI for Development

Organizational Progression

While every organization is different, it is typical to start your CMMI and performance improvement journey with a gap analysis, or “SCAMPI C” Appraisal. The SCAMPI C will give you a practice-by-practice analysis of the entire scope of CMMI, and a set of observations and recommendations for addressing any weaknesses.

This is often followed by “Introduction to CMMI” training, or other training for key individuals, followed by some level of effort to write, modify, align, adopt, or remove process assets. These organizational assets may include process definitions, templates, work instructions, newsletters, reports, training, policies, methods, tools, and more.

When your team is ready to proceed, one or more formal appraisals are conducted – ultimately culminating in a “SCAMPI A” Appraisal and a successful CMMI Rating!


Organizations typically cycle through a series of Appraisal, Training, and Consulting events