ITIL is an IT
Service Management framework that aligns IT with the needs of the business.
ITIL key areas of focus include Services, Lifecycle Phases, Processes, Roles,
and Functions. No doubt, ITIL has made its way to being the most popular and
well known Service Management solution, and has proven its utility thus far.
Although early adopters of ITIL were generally large corporations, it is
finally escaping the “it’s for big companies only” curse, and more small to
mid-sized businesses are finding the practices useful. ITIL is a great starting
point for IT Service Providers who are just beginning to drive process
discipline, as well as provides structure and accountability around an already
mature organization. The biggest advantage is how ITIL uses Continual Service
Improvement to provide a constant feedback mechanism to help you ensure that
what you are delivering is in line with customer expectations. I pick this as a
good overall framework that allows you to cover all axioms mentioned above.
ITIL, formerly known as the Information Technology Infrastructure Library,
is a set of practices for IT service management (ITSM) that focuses
on aligning IT services with the needs of business. In its current form (known
as ITIL 2011 edition), ITIL is published as a series of five core volumes, each
of which covers a different ITSM lifecycle stage. Although ITIL underpins ISO/IEC 20000 (previously BS15000),
the International Service Management Standard for IT service management, there
are some differences between the ISO 20000 standard and the ITIL framework.
ITIL describes
processes, procedures, tasks, and checklists which are not
organization-specific, but can be applied by an organization for establishing
integration with the organization's strategy, delivering value, and maintaining
a minimum level of competency. It allows the organization to establish a
baseline from which it can plan, implement, and measure. It is used to
demonstrate compliance and to measure improvement.
Since July 2013,
ITIL has been owned by AXELOS Ltd, a
joint venture between HM Cabinet
Office and Capita Plc. Axelos licenses
organisations to use the ITIL intellectual property, accredits licensed
Examination Institutes, and manages updates to the framework.
Overview of ITIL v2
The eight ITIL
version 2 books and their disciplines are:
The IT service management sets
1. Service Support
2. Service Delivery
Other
operational guidance
3. ICT infrastructure management
4. Security management
5. Application management
6. Software asset management
To
assist with the implementation of ITIL practices a further book was published
(Apr 9, 2002) providing guidance on implementation (mainly of Service
Management):
7. Planning to implement
service management
And
this has more recently (Jan 26, 2006) been supplemented with guidelines for
smaller IT units, not included in the original eight publications:
8. ITIL small-scale
implementation
Service support
The Service Support ITIL
discipline focuses on the User of the IT services
and is primarily concerned with ensuring that they have access to the
appropriate services to support the business functions.
To a business,
customers and users are the entry point to the process model. They get involved
in service support by:
·
Asking for changes
·
Needing communication, updates
·
Having difficulties, queries
·
Real process delivery
The service desk
functions are the single contact-point for end-users' incidents. Its first
function is always to document ("create") an incident. If there is a
direct solution, it attempts to resolve the incident at the first level. If the
service desk cannot solve the incident then it is passed to a 2nd/3rd level
group within the incident management system. Incidents can initiate a chain of
processes: incident management, problem management, change management, release
management and configuration management. This chain of processes is tracked
using the configuration management database (CMDB), - ITIL refers to
configuration management system (CMS), which
records each process, and creates output documents for traceability (quality
management). Note - CMDB/CMS does not have to be a single database. The
solution can be Federated.
Service delivery
The service delivery discipline
concentrates on the proactive services the ICT must deliver to provide adequate
support to business users. It focuses on the business as the customer of
the ICT services (compare with: service support).
The discipline consisted of the following processes:
·
Service level management
·
Capacity management
·
IT service continuity management
·
Availability management
·
Financial management
ICT infrastructure management
Information and
Communication Technology (ICT) management processes
recommend best practice for requirements analysis, planning, design, deployment
and ongoing operations management and technical support of an ICT
infrastructure.
The infrastructure
management processes describe those processes within ITIL that directly relate
to the ICT equipment and software that is involved in providing ICT services to
customers.
·
ICT design and planning
·
ICT deployment
·
ICT operations
·
ICT technical support
These disciplines are
less well understood than those of service management and therefore often some
of their content is believed to be covered 'by implication' in service
management disciplines.
ICT
design and planning
ICT design and planning
provides a framework and approach for the strategic and technical design and
planning of ICT infrastructures. It includes the necessary combination of
business (and overall IS) strategy, with technical design and architecture. ICT
design and planning drives both the procurement of new ICT solutions through
the production of statements of requirement ("SOR") and invitations
to tender ("ITT")
and is responsible for the initiation and management of ICT Programmes for
strategic business change. Key outputs from design and planning are:
·
ICT strategies, policies and plans
·
the ICT overall architecture &
management architecture
·
feasibility studies, ITTs and SORs
·
business cases
ICT
deployment management
ICT deployment provides
a framework for the successful management of design, build, test and roll-out
(deploy) projects within an overall ICT programme. It includes many project management disciplines
in common with PRINCE2, but has a broader focus to include the necessary
integration of release management and both functional and non functional
testing.
ICT
operations management
ICT operations
management provides the day-to-day technical supervision of the ICT
infrastructure. Often confused with the role of incident management from
service support, operations has a more technical bias and is concerned not
solely with incidents reported by users, but with events generated by or
recorded by the infrastructure. ICT operations may often work closely alongside
incident management and the service desk, which are not-necessarily technical,
to provide an 'operations bridge'. Operations, however should primarily work
from documented processes and procedures and should be concerned with a number
of specific sub-processes, such as: output management, job scheduling, backup
and restore, network monitoring/management, system monitoring/management,
database monitoring/management storage monitoring/management. Operations are
responsible for the following:
·
a stable, secure ICT infrastructure
·
a current, up to date operational
documentation library ("ODL")
·
a log of all operational events
·
maintenance of operational monitoring
and management tools.
·
operational scripts
·
operational procedures
ICT
technical support
ICT technical support
is the specialist technical function for infrastructure within ICT. Primarily
as a support to other processes, both in infrastructure management and service
management, technical support provides a number of specialist functions:
research and evaluation, market intelligence (particularly for design and
planning and capacity management), proof of concept and pilot engineering,
specialist technical expertise (particularly to operations and problem
management), creation of documentation (perhaps for the operational
documentation library or known error database). There are different levels of
support under the ITIL structure, these being primary support level, secondary support level and tertiary support level,
higher-level administrators being responsible for support at primary level.
The Known Error
Database (KEDB) database contains all known error records. This database is
created by problem management and used by incident management and problem
management, and as part of service knowledge management systems.
Planning
to implement service management
The ITIL discipline –
planning to implement service management attempts to provide
practitioners with a framework for the alignment of business needs and IT
provision requirements. The processes and approaches incorporated within the
guidelines suggest the development of a continuous service improvement program
(CSIP) as the basis for implementing other ITIL disciplines as projects within
a controlled program of work. Planning to implement service management focuses
mainly on the service management processes, but also applies generically to
other ITIL disciplines. Components include:
·
creating vision
·
analysing organization
·
setting goals
·
implementing IT service management
Small-scale
implementation
ITIL Small-scale
implementation provides an approach to ITIL framework
implementation for smaller IT units or departments. It is primarily an
auxiliary work that covers many of the same best practice guidelines as planning
to implement service management, service support, and service delivery but
provides additional guidance on the combination of roles and responsibilities,
and avoiding conflict between ITIL priorities.
Related Frameworks
A number of frameworks
exist in the field of IT Service Management alongside ITIL.
Descendants
Microsoft Operations Framework
The Microsoft Operations Framework (MOF)
is based on ITIL v2. While ITIL deliberately aims to be platform-agnostic, MOF
is designed by Microsoft to provide a common management framework for its products.
Microsoft has mapped MOF to ITIL as part of their documentation of the
framework.
FITS
The British Educational
Communications and Technology Agency (BECTA) used ITIL as
the basis for their development of Framework for ICT Technical Support (FITS).
Their aim was to develop a framework appropriate for British schools, which
often have very small IT departments. FITS became independent from BECTA in
2009 and is now maintained and supported by The FITS Foundation. FITS is now
used in excess of a thousand schools in the UK, Australia and Norway as the
standard for ICT Service Management in the Education sector (Video: What
people are saying).
Other Frameworks
The process framework
of the ISO/IEC
20000 standard
(previously BS 15000) is largely equivalent that of the Service
Support and Service Delivery parts
of ITIL Version 2. While it is not possible for an organization to be
certified as being ITIL compliant, certification of an organization is
available for ISO/IEC 20000.
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.
The Business Process Framework (eTOM) published
by the TeleManagement Forum offers a framework aimed at telecommunications
service providers. In a joined effort, TM Forum and itSMF developed
an Application Note to eTOM (GB921) that shows how the two frameworks can be
mapped to each other. It addresses how eTom process elements and flows can be
used to support the processes identified in ITIL.
IBM Tivoli
Unified Process (ITUP) is aligned with ITIL, but
is presented as a complete, integrated process model compatible with IBM's
products.
FitSM is
a standard for lightweight service management. Its process framework is quite
similar to that of ISO/IEC 20000 and the Service Support and Service
Delivery parts of ITIL version 2, but adopts Service
Portfolio Management from later ITIL versions. FitSM contains several
parts, including samples and templates for core ITSM documents, that are
published under Creative Common licenses.
What Is COBIT
Today,
COBIT is internationally recognized as the “go to” solution for IT governance,
with aspects in security, quality and compliance. Its focus is not necessarily
on how to execute a process, rather what should be done to ensure proper
control of that process. Therefore, you won’t technically implement COBIT
processes from the bottom up, but use it as a tool to help you control
processes from top down as a part of a larger governance initiative. This is a
very constructive and useful tool. Starting out as a tool designed for IT
auditors to assist in the control of IT, it has grown into a model to help
companies meet compliance and statutory requirements as well. It helps you
understand IT systems, and guides decisions around the level of security and
control that is necessary to protect assets through the leverage of an IT
governance model. More specifically, it bridges the gap among control
requirements, technical issues, and business risks rather than focusing on the
actual process (i.e. ITIL) and enables policy development and good IT control
practices. Generally speaking, COBIT is the most broad of all IT related
frameworks and bodies of knowledge today. I pick this as the starting point to
most of my initiatives since it tells me what to do rather than how to do it.
As with ITIL, it covers all of the axioms.
Control
Objectives for Information and Related Technology (COBIT)
is a framework created by ISACA for information technology (IT)
management and IT governance. It is a
supporting toolset that allows managers to bridge the gap between
control requirements, technical issues and business risks.
Overview
ISACA first released
COBIT in 1996; ISACA published the current version, COBIT 5, in 2012.
COBIT aims "to research,
develop, publish and promote an authoritative, up-to-date, international set of
generally accepted information technology control objectives for
day-to-day use by business managers, IT professionals and
assurance professionals".
COBIT, initially an acronym for
"Control objectives for information and related technology" (though
before the release of the framework people talked of "CobiT" as
"Control Objectives for IT), defines a set of generic processes for the
management of IT. The framework defines each process together with process
inputs and outputs, key process-activities, process objectives, performance
measures and an elementary maturity model.
The framework supports governance of
IT by defining and aligning business goals with IT goals
and IT processes.
COBIT provides a set of recommended
best practices for governance and control process of information systems and
technology with the essence of aligning IT with business. COBIT 5 consolidates
COBIT4.1, Val IT and Risk IT into a single framework acting as an enterprise
framework aligned and interoperable with TOGAF and ITIL.
The COBIT Framework
The business orientation of COBIT
consists of linking business goals to IT goals, providing metrics and maturity
models to measure their achievement, and identifying the associated
responsibilities of business and IT process owners.
The process focus of COBIT 4.1 is
illustrated by a process model that subdivides IT into four domains (Plan and
Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate)
and 34 processes in line with the responsibility areas of plan, build, run and
monitor. It is positioned at a high level and has been aligned and harmonized
with other, more detailed, IT standards and good practices such as COSO, ITIL, BiSL, ISO 27000, CMMI, TOGAF and PMBOK. COBIT acts as an
integrator of these different guidance materials, summarizing key objectives
under one umbrella framework that link the good practice models with governance
and business requirements.
The COBIT 4.1 framework
specification can be obtained as a complimentary PDF at the ISACA
download website. (Free self-registration may be required.)
COBIT 5 was released in April 2012. COBIT
5 consolidates and integrates the COBIT 4.1, Val IT 2.0 and Risk IT frameworks,
and draws from ISACA's IT Assurance Framework (ITAF) and the Business
Model for Information Security (BMIS). It aligns with frameworks and
standards such as Information Technology Infrastructure Library (ITIL), International
Organization for Standardization (ISO), Project Management
Body of Knowledge (PMBOK), PRINCE2 and The Open Group
Architecture Framework (TOGAF).
What IS TOGAF
Never heard of TOGAF? Neither had I until a few
years ago when a client asked me what an Architecture Review Board (ARB) does.
After a few quick minutes of searching, TOGAF came up time and again. This
hidden gem is an enterprise architecture framework that represents a set of
tools, methods, and vocabulary that satisfies a full approach in planning,
designing, implementing, and governing enterprise architecture. The TOGAF
topics incorporate Domains, Architecture Development Method (ADM) and
Enterprise Continuum. Domains (or pillars) include Business Architecture,
Applications Architecture, Data Architecture, and Technical Architecture. The
ADM is an iterative cycle used to manage the execution of architecture planning
activities. The Enterprise Continuum is akin to a repository of all
organizational architecture assets.
The Open
Group Architecture Framework (TOGAF) is a framework for enterprise architecture which
provides an approach for designing, planning, implementing, and governing an
enterprise information technology architecture. TOGAF has been a
registered trademark of The Open
Group in the United States and other countries since 2011.
TOGAF is a high level approach to
design. It is typically modeled at four levels: Business, Application, Data,
and Technology. It relies heavily on modularization, standardization, and
already existing, proven technologies and products.
Overview
An architecture framework is a set of
tools which can be used for developing a broad range of different architectures. It
should:
·
describe a
method for defining an information system in terms of a set of building blocks
·
show how the
building blocks fit together
·
contain a
set of tools
·
provide a
common vocabulary
·
include a
list of recommended standards
·
include a
list of compliant products that can be used to implement the building blocks
TOGAF is such an architecture
framework.
The ANSI/IEEE Standard 1471-2000 specification
of architecture (of software-intensive systems) may be stated 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."
However TOGAF has its own view,
which may be specified as either a "formal description of a system, or a
detailed plan of the system at component level to guide its
implementation", or as "the structure of components, their
interrelationships, and the principles and guidelines governing their design
and evolution over time."
The Architecture Development Method
(ADM) is core of TOGAF which describes a method for developing and managing the
lifecycle of enterprise architecture.
What is CMMI
Capability
Maturity Model Integration (CMMI) is a process improvement training and appraisal
program and service administered and marketed by Carnegie Mellon University and
required by many DoD and U.S.
Government contracts, especially in software development. Carnegie Mellon University claims
CMMI can be used to guide process improvement across a project, division, or an
entire organization. CMMI defines the following maturity levels for processes:
Initial, Managed, Defined, Quantitatively Managed, Optimizing. Currently
supported is CMMI Version 1.3. CMMI is registered in the
U.S. Patent and Trademark Office by Carnegie Mellon University.
Overview
Characteristics
of the Maturity levels.
CMMI currently addresses three areas
of interest:
1. Product and service development —
CMMI for Development (CMMI-DEV),
2. Service establishment, management, —
CMMI for Services (CMMI-SVC), and
3. Product and service acquisition —
CMMI for Acquisition (CMMI-ACQ).
CMMI was developed by a group of
experts from industry, government, and the Software Engineering Institute (SEI)
at Carnegie Mellon University. CMMI models
provide guidance for developing or improving processes that meet the business
goals of an organization. A CMMI model may also be used as a framework for
appraising the process maturity of the organization. By
January of 2013, the entire CMMI product suite was transferred from the SEI to
the CMMI Institute, a newly created organization at Carnegie Mellon.
CMMI originated in software
engineering but has been highly generalized over the years to embrace other
areas of interest, such as the development of hardware products, the delivery
of all kinds of services, and the acquisition of products and services. The
word "software" does not appear in definitions of CMMI. This
generalization of improvement concepts makes CMMI extremely abstract. It is not
as specific to software engineering as its predecessor, the Software CMM (CMM,
see below).
COBIT vs ITIL
COBIT and
ITIL have been used by information technology professionals in the IT service
management (ITSM) space for many years. Used together, COBIT and ITIL provide
guidance for the governance and management of IT-related services by
enterprises, whether those services are provided in-house or obtained from
third parties such as service providers or business partners.
Enterprises need to govern and manage their
information and related technology assets and resources, and those arrangements
customarily include both internal and external services to satisfy specific stakeholder
needs. COBIT 5 aims primarily to guide enterprises on the implementation,
operation and, where required, improvement of their overall arrangements
relating to governance and management of enterprise IT (GEIT). ITIL provides
guidance and good practice for IT service providers for the execution of IT
service management from the perspective of enabling business value.
COBIT 5 describes the principles and enablers
that support an enterprise in meeting stakeholder needs, specifically those
related to the use of IT assets and resources across the whole enterprise. ITIL
describes in more detail those parts of enterprise IT that are the service
management enablers (process activities, organizational structures, etc.).
Generally speaking:
· COBIT is broader than ITIL in its scope of
coverage (GEIT). It is based on five principles (meeting stakeholder needs;
covering the enterprise end to end; applying a single, integrated framework;
enabling a holistic approach; and separating governance from management) and
seven enablers (principles, policies and frameworks; processes; organizational
structures; culture, ethics and behavior; information; services, infrastructure
and applications; people, skills and competencies).
· ITIL focuses on ITSM and provides much more
in-depth guidance in this area, addressing five stages of the service life
cycle: service strategy, service design, service transition, service
operation and continual service improvement.
Also, COBIT and ITIL are well aligned in their
approach to ITSM. The COBIT 5 Process Reference Model, as documented in COBIT 5:
Enabling Processes, maps closely to the ITIL v3 2011 stages.
The distinction between the two is sometimes
described as “COBIT provides the ‘why’; ITIL provides the ‘how.’” While catchy,
that view is simplistic and seems to force a false “one or the other” choice.
It is more accurate to state that enterprises and IT professionals who need to
address business needs in the ITSM area would be well served to consider using
both COBIT and ITIL guidance. Leveraging the strengths of both frameworks, and
adapting them for their use as appropriate, will aid in solving business
problems and supporting business goals achievement.
COBIT
is a framework for the Governance and Management of the Enterprise IT covering
the Enterprise End-to-End including the business processes from the board of
directors to the IT operation levels, enabling a holistic approach based on 7
enablers :
- Principles, Policies & frameworks),
- Processes,
- Organizational structures
- Culture, Ethics & Behavior of the
Enterprise stakeholders (including the Board, Employees, Management, etc)
- Information,
- IT (Services, applications, infrastructure)
- People, skills & competencies (HR
management)
while ITIL is a framework of best practices in
IT Service Management (covering the IT side only) and focused on processes only
which doesn't allow any holistic approach.
ITIL could be seen as the way to manage the IT
services accross their lifecycle while COBIT is about how to Govern the
Enterpise IT in order to generate the maximum creation of value by the
business, enabled by IT investments while optimizing the risks and the
resources.
This is definitely two very different things
which are complementary but with a huge difference in terms of scope and
objectives.
CMMI
And ITIL
· Application
The basic difference between
CMMI and ITIL lies in application. 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.
·
Structure
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.
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.
·
Similarities
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.
COBIT
And CMMI
- COBIT—COBIT was originally released as an IT process and control framework linking IT to business requirements. It was initially used mainly by the assurance community in conjunction with business and IT process owners. With the addition of management guidelines in 1998, COBIT was used increasingly as a management framework, providing management tools such as metrics and maturity models to complement the control framework. With the release of COBIT® 4.0 in 2005, it became a more complete IT governance framework.
- Capability Maturity Model® Integration
(CMMI) for Development—CMMI is a process improvement capability maturity
model for the processes controlling development, implementation,
acquisition and maintenance of systems and software products and services.
It consists of best practices that address development and maintenance
activities that cover the product life cycle from conception through
delivery and maintenance. This latest iteration of the model represents an
integration of bodies of knowledge that address software engineering,
systems engineering, hardware and design engineering, and acquisition. The
model is used mainly by organisations engaged in relatively large and
complex software and systems engineering projects to develop and maintain
products and services. CMMI-assessed capabilities meet supplier
qualifications for US government contracts. In 2006, the SEI published
CMMI for Development V1.2.
Working
With COBIT, CMMI, TOGAF And ITIL
IT
management has become an integral part of every business today. Not a single
business can survive without an effective IT management system. This is largely
because most business operations today rely on IT systems. There are three
major frameworks that influence IT management today. These frameworks include
ITIL, CMMI, and COBIT. Even though these frameworks are so important, they are
incompatible with the necessary the doctrine of Business Process Management
philosophy. An example of this incompatibility is the analysis of the ITIL
value network support. It is therefore important to understand the implication
of this incompatibility and its consequences. Understanding why this
inconsistency occurs will help you to find an alternative approach.
For starters,
these frameworks serve to define broad sections of information technology
practice. Moreover, their profound influence is being experienced globally. In
most cases, these frameworks are used as criteria for offering contracts,
assessing maturity, evaluating risk and performance. It is also worthwhile to
point out that these frameworks work to define as well as stabilize the IT
terminology and utilize it to describe the common IT practice. The IT industry
is always under serious scrutiny with most critics challenging the ability of
IT to offer consistent services. They also challenge the capability of
information technology to manage itself appropriately. That’s why it is
critical to have a clear understanding of how these three frameworks work.
When it comes to
BPM (business process management), there is a lot of literature associated with
it. This literature includes understanding how to recognize, establish and
improve different business processes. It is also important to note that there
is always a considerable overlie between BPM and other continuous step up
techniques like the Lean and Six Sigma. BPM has always been employed in the
management of IT systems. The other two terms use the word process defiantly,
and that is why they are normally called process frameworks. Hence, they place
themselves for inspection from BPM’s point of view.
COBIT, on the
other hand, is the short form of Control Objective for Information Technology.
This framework uses a somewhat different direction in defining its processes.
For instance, it is known to always start with verbs. But these processes are
not really crisp. CMMI is known to be somewhat a meta-process. It contains a
set of criteria that may be applied to all processes. It is open to all
processes. Its processes are similar to COBIT and ITIL.
What is the difference between a TOGAF building block
and an ITIL CMDB configuration item?
Since we are in the process of implementing an
ITIL-compliant ITSM system, there is increasing interest in topics such as CMDB
and configuration items (CIs), but the more I consider the question, the more I
am drawn into this topic: Truly, what is the difference? Or, are there any
differences at all? Let’s look at some definitions:
·
A Configuration Management Database (CMDB), according to ITIL v3, is a database used to store
configuration records throughout their life cycle. The configuration management
system maintains one or more CMDBs, and each CMDB stores attributes of CIs and
relationships with other CIs.
·
A Configuration Item (CI), according to ITIL v3, is any component that needs to be managed in order
to deliver an IT service. Information about each CI is recorded in a
configuration record within the configuration management system and is
maintained through its life cycle by configuration management. CIs are under
the control of change management. CIs typically include IT services, hardware,
software buildings, people, and formal documentation such as process
documentation and SLAs.
·
A Building Block (BB), according to TOGAF v9, represents a (potentially reusable) component of
business, IT, or architectural capability that can be combined with other
building blocks to deliver architectures and solutions. Building blocks can be
defined at various levels of detail, depending on what stage of architecture
development has been reached. For instance, at an early stage, a building block
can simply consist of a name or an outline description. Later on, a building
block may be decomposed into multiple supporting building blocks and may be
accompanied by a full specification. Building blocks can relate to
“architectures” or “solutions.”
Without claiming to be an expert in ITIL or TOGAF, I
have attempted to outline similarities and differences that I believe exist at
first glance. There are definitely several ways to look at the nature of the
data and metadata that populate an ITIL CMDB or a TOGAF meta model-based
architecture repository, but since I’m still learning to apply both knowledge
areas, I’ll leave my assessment at only the surface level.
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.
References
http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Mapping-Mapping-of-CMMI-for-Development-V1-2-With-COBIT.aspx
http://architectureandgovernance.com/content/cis-and-bbs-itil-meets-togaf
http://blogs.interfacett.com/itil-cobit-pmbok-babok-togaf-5-tools-to-improve-your-it-department
http://en.wikipedia.org/wiki/ITIL
http://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework
http://en.wikipedia.org/wiki/COBIT
http://blogs.technet.com/b/cdnitmanagers/archive/2014/04/06/cobit-versus-itil.aspx
http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
Hiç yorum yok:
Yorum Gönder