The relation in between ITIL, Cobit, Togaf and CMMI
ABSTRACT
IT management is strongly influenced by
the major process frameworks ITIL, COBIT, and CMMI.However, these
frameworks are inconsistent with important tenets of Business Process
Management thinking. Examples of this inconsistency are provided,
including an analysis ofITIL’s Value Network advocacy.
Implications and consequences and an alternate approach are
discussed.
IT
organizations in our country, as in all other areas, too frequent
changes taking place. Each new management wants to perform a new IT
management according to their own experience.
So a set
of standards in this regard, is there a list of the best on? Outside
on how this is managed in the world ?
In fact,
there are solutions in different ways. IT Infrastructure Library
(ITIL), ISO 20000, best practices and standards such as Cobit we have
too much to shed light on this issue content.
In my
opinion ,ITIL candidate managers of the future, to take the COBIT
training, enter the ISO 20000 compliance process of the company to
provide competitive advantage will be the most important criteria.
What is ITIL?
While working in the Project Portfolio Office of a bank in Ireland I became ITIL Foundation in IT Service Management certified. The Foundation Level of ITIL is the first stage in learning the key concepts, structure, terminology and processes of ITIL.
ITIL stands for Information Technology Infrastructure Library, and it is a trademark of the United Kingdom’s Office of Government Commerce. Its purpose is to give descriptions of important IT practices and to provide checklists, tasks and procedures that can be adopted and adapted by organizations to the degree that they choose. As such, ITIL is not a framework that must be rigidly adhered to or complied with; organizations can use as many of ITIL’s tools as they care to depending on their size, goals or needs.
ITIL best practices can be found in a series of reference books. Since ITIL’s inception in 1989 the number of ITIL references grew to over 30 volumes; however, in 2001, in order to make ITIL more accessible and affordable, the number of references was trimmed down to seven core books for ITIL v2, and in 2007 it was trimmed even further, to the current five publications of ITIL v3. The five core version 3 titles are:
• Service Strategy: Aligning business and IT
• Service Design: Guidance on the production and maintenance of IT policies
• Service Transition: Guidance and process activities for the transition of services in the operational business environment
• Service Operation: Delivery and control activities to achieve operational excellence on a day-to-day basis
• Continual Service Improvement: The process elements involved in identifying and introducing service improvements.
ITIL v3 refined the principles and processes within ITIL v2, and where ITIL v2 was very process-focused, ITIL v3 revolves around a service lifecycle approach to help IT departments provide business value to organizations. Though there are several key differences between the versions the core tenets behind the practices and processes are the same.
ITIL has been adopted by thousands of organizations worldwide, including:
• NASA
• Microsoft
• IBM
• Procter & Gamble
• HP
• Shell
• UK National Health Service
• HSBC
• The Walt Disney Company
• Müller Dairy.
For more examples of companies who have used ITIL to achieve business benefits, see our case studies and white papers.
ITIL is also supported by services from a wide range of providers including examination institutes, accredited training providers and consultancies, software and tool vendors and well known service providers such as IBM, Telefonica, HP and British Telecom (BT).
What is COBIT?
The COBIT framework is published by the IT Governance Institute and the Information Systems Audit and Control Association (ISACA). The goal of the framework is to provide a common language for business executives to communicate with each other about goals, objectives and results. The original version, published in 1996, focused largely on auditing. The latest version, published in 2013, emphasizes the value that information governance can provide to a business’ success. It also provides quite a bit of advice about enterprise risk management.
The name COBIT originally stood for “Control Objectives for Information and Related Technology,” but the spelled-out version of the name was dropped in favor of the acronym in the fifth iteration of the framework.
COBIT 5 is based on five key principles for governance and management of enterprise IT:
Principle 1: Meeting Stakeholder Needs
Principle 2: Covering the Enterprise End-to-End
Principle 3: Applying a Single, Integrated Framework
Principle 4: Enabling a Holistic Approach
Principle 5: Separating Governance From Management
The relationships between these components are illustrated by a so-called CobiT cube
HOW DOES THE TOGAF WORK ?
The Open Group Architecture Framework, or TOGAF gives software architects a structured approach for organizing and governing their software technology design, development and maintenance.
The Open Group Architecture Framework, or TOGAF, is intended to provide a structured approach for organizations seeking to organize and govern their implementation of technology, particularly software technology. In that sense, its objective is to employ an encompassing conceptual framework to try to ensure that software development projects meet business objectives, that they are systematic and that their results are repeatable.
TOGAF was created and is maintained by The Open Group, an independent industry association. It builds on an earlier framework known as TAFIM, or Technical Architecture Framework for Information Management, originally devised by the U.S. Defense Dept. In early 2009, The Open Group released TOGAF version 9. The Open Group and others commonly lead TOGAF certification and educational programs today. Typically, enterprise architects lead use of TOGAF within organizations.
Like its TAFIM forerunner and many other frameworks, TOGAF owes a debt to the work of John Zachman, who created the Zachman Framework, a related schema to facilitate discussion between different software development stakeholders and improve software project and program outcomes. This and similar frameworks seek to effectively organize requirements gathering,to make sure what is built is what is needed. Zachman’s landmark work in the 1980’s while at IBM, brought context to the development process without endorsing a specific software language or methodology. Like TOGAF today, it clarified terms and roles, focusing on the ”What, How, When, Who, Where and Why” of technology implementation.
The basic TOGAF 9 document contains descriptions of an architecture development method and related techniques, an architecture content framework, an enterprise continuum, TOGAF reference models and a capability framework. Version 9 creates a model for extensibility, among other enhancements.
TOGAF need not be used ”whole hog.” While the basic TOGAF document runs to many pages, a pocket-book version is available too. Experienced professionals can focus on the aspects of TOGAF that work best for their organization as they pursue business benefits derived from software innovation.
TOGAF has enjoyed considerable adoption in organizations of diverse character. Its use is seen as a potential systematization of efforts – in the wake of high-profile failures – by governments, businesses and others to apply structured enterprise architecture principles to the still somewhat ”black arts” of software development and IT operations. TOGAF can be used with – or without – service-oriented architecture (SOA), UML and various frameworks, methodologies and tools of modern software development.
What is CMMI?
The Capability Maturity Model Integration, or CMMI, is a process model that provides a clear definition of what an organization should do to promote behaviors that lead to improved performance. With five “Maturity Levels” or three “Capability Levels,” the CMMI defines the most important elements that are required to build great products, or deliver great services, and wraps them all up in a comprehensive model.
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.
CMMI is comprised of a set of “Process Areas.” Each Process Area is intended be adapted to the culture and behaviors of your own company. The CMMI is not a process, it is a book of “whats” not a book of “hows,” and does not define how your company should behave. More accurately, it defines what behaviors need to be defined. In this way, CMMI is a “behavioral model” and well as a “process model.”
Organizations can be “Rated” at a Capability or Maturity Level based on over 300 discreet “Specific” and “Generic” Practices. Intended to be broadly interpreted, the CMMI is not a “Standard” (ala ISO), so achieving a “Level” of CMMI is not a certification, but a “rating.”
DETAILS
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.
CMMI-DEV commands the largest market share, followed by CMMI-SVC, and then CMMI-ACQ.
SIMILARITIES
Components: CIs and BBs are both discrete components—hardware, software, locations, roles, services, etc.—each with a unique set of attributes.
Relationships: Both are expressed not only in terms of their own attributes, but are most valuable when relationally modeled in respect to other components.
Abstractions: Both make use of abstraction, composition, and decomposition to express “low level” components and their relationship to “high level” components.
States: Some configuration management systems (CMS) are able to manage transitional states between the current state and previous transitions or even proposed future states. This is similar in concept to the transitioning of a BB from a current to future state. Though, the implementation of this is dependent on the ITSM and CMS, CIs definitely support the idea of states.
DIFFERENCES
Single vs. Multiple Perspectives One of the biggest differences between a CI and a BB is the framework that manages them. Since ITIL is primarily a service management framework, CIs are typically represented in a service model. Because of this, I would imagine that there is almost never a CMDB dedicated to managing the relationships between organizational goals and a process, nor is data typically modeled in a CMDB at all. Therefore, I believe you could consider ITIL’s service models to be a single service management view of the broader set of views required to model EA. This means that only the CIs required to model this view are housed in the CMDB.
Operational vs. Strategic Functions
Since the CMDB typically only manages CIs related to service management, it is particularly helpful to those performing day-to-day service management activities. Consider a strategy map dashboard that shows strategic goals and their relationship to one another, and rolls up health information for each goal. This would be another operational view, supported by EA modeling, which would not fit into a typical CMDB and therefore is not a candidate CI.
Service Management vs. Enterprise Architecture Context
In summary, I think the biggest difference between CIs and BBs are their context. The systems that attempt to support this context do not take into account other uses. While the CIs in a CMDB are relegated to only those required to model the service management view, this does not have to be the case. Nor is it true that there shouldn’t be some collaboration between CMDB and EA repository vendors to support a dual purpose system, where BBs are able to be made into CIs in support of the IT service management view.
The Capability Maturity Model Integration, or CMMI, is a process model that provides a clear definition of what an organization should do to promote behaviors that lead to improved performance. With five “Maturity Levels” or three “Capability Levels,” the CMMI defines the most important elements that are required to build great products, or deliver great services, and wraps them all up in a comprehensive model.
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.
CMMI is comprised of a set of “Process Areas.” Each Process Area is intended be adapted to the culture and behaviors of your own company. The CMMI is not a process, it is a book of “whats” not a book of “hows,” and does not define how your company should behave. More accurately, it defines what behaviors need to be defined. In this way, CMMI is a “behavioral model” and well as a “process model.”
Organizations can be “Rated” at a Capability or Maturity Level based on over 300 discreet “Specific” and “Generic” Practices. Intended to be broadly interpreted, the CMMI is not a “Standard” (ala ISO), so achieving a “Level” of CMMI is not a certification, but a “rating.”
DETAILS
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.
CMMI-DEV commands the largest market share, followed by CMMI-SVC, and then CMMI-ACQ.
SIMILARITIES
Components: CIs and BBs are both discrete components—hardware, software, locations, roles, services, etc.—each with a unique set of attributes.
Relationships: Both are expressed not only in terms of their own attributes, but are most valuable when relationally modeled in respect to other components.
Abstractions: Both make use of abstraction, composition, and decomposition to express “low level” components and their relationship to “high level” components.
States: Some configuration management systems (CMS) are able to manage transitional states between the current state and previous transitions or even proposed future states. This is similar in concept to the transitioning of a BB from a current to future state. Though, the implementation of this is dependent on the ITSM and CMS, CIs definitely support the idea of states.
DIFFERENCES
Single vs. Multiple Perspectives One of the biggest differences between a CI and a BB is the framework that manages them. Since ITIL is primarily a service management framework, CIs are typically represented in a service model. Because of this, I would imagine that there is almost never a CMDB dedicated to managing the relationships between organizational goals and a process, nor is data typically modeled in a CMDB at all. Therefore, I believe you could consider ITIL’s service models to be a single service management view of the broader set of views required to model EA. This means that only the CIs required to model this view are housed in the CMDB.
Operational vs. Strategic Functions
Since the CMDB typically only manages CIs related to service management, it is particularly helpful to those performing day-to-day service management activities. Consider a strategy map dashboard that shows strategic goals and their relationship to one another, and rolls up health information for each goal. This would be another operational view, supported by EA modeling, which would not fit into a typical CMDB and therefore is not a candidate CI.
Service Management vs. Enterprise Architecture Context
In summary, I think the biggest difference between CIs and BBs are their context. The systems that attempt to support this context do not take into account other uses. While the CIs in a CMDB are relegated to only those required to model the service management view, this does not have to be the case. Nor is it true that there shouldn’t be some collaboration between CMDB and EA repository vendors to support a dual purpose system, where BBs are able to be made into CIs in support of the IT service management view.
RELATIONS
· In conlusion , we end up with COBIT is an IT governance framework and supporting toolset developed by ISACA. ISACA view ITIL as being complementary to COBIT. They see COBIT as providing a governance and assurance role while ITIL providing guidance for service management.
· While TOGAF adds structure for enterprise architecture, processes and techniques, COBIT puts TOGAF into context by relating architectural processes to all other IT processes. And COBIT, through RACI charts, adds responsibilities for TOGAF, helping organizations implement TOGAF and connect it to broader IT processes. To complete the circle, COBIT also adds key performance indicators for TOGAF.
· TOGAF should not just make an association, but be explicit in business architecture, application architecture, data architecture and technical architecture domains regarding the added benefits. These benefits and risks of open source can then “cascade” into the broader IT governance and management COBIT framework.
· In terms of TOGAF, ITIL provides the target architecture, which should be confronted with the baseline architecture of a specific organization,
· Probably the most important relationship between ITIL and TOGAF is that there is a strong relationship between the processes (although these relationships are not clearly identified in ITIL). In particular, the first builds on the results of the latter. An enterprise architecture describes services that are needed at a high level and these services are designed in the Service Design stage in ITIL.
· Both TOGAF and ITIL provide guidance in the design of services, albeit at a different level of detail. Also, design in ITIL is focused on IT services while enterprise architecture has a much broader focus (also looking at non-IT services).
· ITIL is more focused on service management and provides guidance on how to develop and implement effective solutions. COBIT provides an overall, high level governance framework which is applicable to most organizations but is not specific about certain aspects of the business like IT service management or information security.
· As ITIL covers particular areas in more detail, it can be mapped to COBIT to enhance the framework and build a hierarchy of processes.
· COBIT can be used to shape ITIL processes to the business needs and measure the success of ITIL implementation.
· CMMI for services and CMMI for acquisitions are complementary to COBIT, in that these aspects are not adequately covered by COBIT.
· Both CMMI and COBIT include a maturity model, however the CMMI standards include goals and procedures which are not part of the COBIT maturity model
· According to relation between Togaf and ITIL see the figure below:
· CobiT addresses “what is to be achieved,” while ITIL addresses “how to achieve it.”
· Both CMMI and ITIL are process maturity frameworks that follow a similar and structured approach.
· Both emphasize development of processes to improve product development and customer satisfaction and support the coordination of multi-disciplinary activities related to a project.
· Although both CMMI and ITIL are similar in structure, the amount of duplication is, however, small and there is no contradiction between the two models, making it possible to apply both CMMI / ITIL models simultaneously in an organization.
· CMMI is the de facto quality standard for software development, integration, deployment, and maintenance processes in organizations and ITIL is the first choice of organizations for standards related to operations and the infrastructure side of IT.
· Implementation of CMMI / ITIL also aids organizations in reducing the cost of quality, improving turnaround times, and arriving at a precise estimate of efforts required that helps in costing products.
· Unlike CMMI, ITIL is not descriptive and orders the processes in sets. CMMI for instance, recommends requirement analysis but does not specify how to do a requirement analysis. ITIL on the other hand, provides specifics on how to undertake the requirement analysis.
· CMMI is a descriptive approach that orders process areas along a maturity model with maturity levels. A CMMI model is not a process but a description of effective process characteristics.
· While CMMI is focused toward software development, maintenance, and product integration, ITIL is broader in scope and provides a framework for IT service management and operations including a hardware life cycle.
· CMMI is geared specifically to software development organizations and focuses on continuous improvement, whereas ITIL addresses IT operations issues such as security, change and configuration management, capacity planning, troubleshooting, and service desk functions.
· While the application of CMMI helps the organization gain competency and expertise in software or product development, ITIL applications help align the entire IT process and resources of the organization to business processes.
· The most important relationship between COBIT and TOGAF, is that enterprise architecture is one of the processes described in COBIT. Actually, when you look at the description of enterprise architecture in COBIT 5 you see that they have looked at TOGAF closely and included most of the TOGAF Architecture Development Method in the description of the process.
· COBIT seems to cover all the TOGAF phases and activities.
· The heart of COBIT is a (high-level) description of all IT processes, which are based on and aligned with various other process frameworks, including TOGAF.
REFERENCES
·http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
.http://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework
·http://en.wikipedia.org/wiki/ITIL
·http://en.wikipedia.org/wiki/COBIT
·https://www.isaca.org/Knowledge-Center/cobit/Documents/COBIT4.pdf
·http://blogs.interfacett.com/itil-cobit-pmbok-babok-togaf-5-tools-
·http://en.wikipedia.org/wiki/ITIL
·http://en.wikipedia.org/wiki/COBIT
·https://www.isaca.org/Knowledge-Center/cobit/Documents/COBIT4.pdf
·http://blogs.interfacett.com/itil-cobit-pmbok-babok-togaf-5-tools-
Thanks for providing this information
YanıtlaSilServiceNow Training
Best ServiceNow Online Training in Hyderabad