ITIL Framework Service Transition Section

Prepared By: Enes AÇIKOĞLU and Kerem CAN

The Goals Of Service Transition

“Aligning the new or changed service with the organisational requirements and organisational  operations”

• Plan and manage the capacity and resources required to package, build, test and deploy a release into production
• Provide a consistent and rigorous framework for evaluating the service capability and risk profile before a new or changed service is released
• Establish and maintain the integrity of all identified service assets and configurations
• Provide good quality knowledge and information to expedite effective decisions about promoting a release
• Provide efficient, repeatable build and installation mechanisms to deploy releases to test and production
• Ensure that the service can be managed, operated and supported in accordance with service design

Other Objectives Include:

• Align the new or changed service with the organisation requirements and business operations
• Ensure that customers/users can use the new or changed service in a way that maximises value to the organisation operations
• Plan and manage resources so that transitions come in on time, cost and quality
• Ensure minimum impact on current services
• Increase customer, user and service support satisfaction

Value to the organisation/business of service transition

Creates value for the business by improving:

• The ability to adapt quickly to new requirements
• The success rate of changes and releases for the organisation
• The predictions of service levels and warranties for new and changed services
• Confidence in the degree of compliance with the organisation requirements during change
• Clarity of plans so the business can link their organisation change plans to transition plans

All the above give competitive edge and help the agility and flexibility and the organisation. 

The Scope Of Service Transition

The scope of service transition includes the management and coordination of the processes, systems and functions to package, build, test and deploy a release into production and establish the service specified in the customer and stakeholder requirements.
The following activities are excluded from the scope of service transition best practices:

• Minor modifications to the production services and environment, for example, replacement of a failed PC or printer, installation of standard software on a PC or server, new user
• Ongoing continual service improvements that do not significantly impact the services or service provider’s capability to deliver the services, for example, request fulfilment activities driven from service operations

Service Transition Processes

• Knowledge Management
• Change Management
• Release And Deployment Management
• IT Service Asset And Configuration Management
• Service Validation And Testing

1. Knowledge  Management

Why have knowledge management?
An organisations ability to deliver a quality service or process rests, to a significant extent, on its ability to respond to circumstances. To enable this to happen, those involved must have a sound understanding of the situation, the options, consequences and benefits. An example of this knowledge in the service transition phase may include:

• Identity of stakeholders
• Acceptable risk levels and performance expectations
• Available resource and time scales

The quality and relevance of the knowledge rests in turn on the accessibility, quality and continued relevance of the underpinning data and information available to service staff.

The Objectives Of Knowledge Management

“The goal of knowledge management is to enable organisations to improve the quality of management decision-making by ensuring that reliable and secure information and data is available throughout the service lifecycle”
The primary purpose is to improve efficiency by reducing the need to rediscover knowledge. This is achieved by:

• Enabling the service provider to be more efficient and improve the quality of the service, reduce costs, increase satisfaction
• Ensuring staff have a clear and shared understanding of the value that their services provide to customers and how they are realised
• Ensuring that, as required, service provider staff have adequate information on –
• Who is currently using the service they are providing
• The current states of consumption
• Service delivery constraints
• Difficulties faced by customers, realising the expected benefits from services

The above diagram is a very simplified illustration of the relationship of the three levels, with data being gathered within the CMDB, and feeding through the CMS into the SKMS as information to support the informed decision making process.

Value To The Organisation Of Knowledge Management

Knowledge management is especially significant within service transition since relevant and appropriate knowledge is one of the key service elements being transitioned. Examples where successful transition rests on appropriate knowledge management include:

• User, service desk, support staff and supplier understanding of the new or changed service, including knowledge of errors signed off before deployment, to facilitate their roles within that service
• Awareness of the use of the service, and the discontinuation of previous versions
• Establishment of the acceptable risk and confidence levels associated with the transition, g. measuring, understanding and acting correctly on results of testing and other assurance results

Effective knowledge management is a powerful asset for people in all roles across all stages of the service lifecycle. It is an excellent method for individuals and teams to share data, information and knowledge about all facets of an IT service. The creation of a single system for knowledge management is recommended.

The Activities Of Knowledge Management

Knowledge identification capture and maintenance – Specifically knowledge management will identify and plan for the capture of relevant knowledge and the consequential information and data that will support it.
Knowledge transfer – This is the activity through which one unit (e.g. group or department) is affected by the experiences of another. The form of knowledge transfer must suit those who will use it, examples of criteria/examples that can be used are:

• Learning styles
• Knowledge visualisation
• Driving behaviour
• Seminars, webinars and advertising
• Journals and newsletters

The transfer of knowledge can be observed through changes in the knowledge or performance or recipients, and at an individual or unit level.
Data and information management – Knowledge rests on the management of the information and data that underpins it. For this process to be efficient it requires answers to some key input questions, such as how the data and information will be used, what conditions will need to be monitored, what data is available, what are the associated costs, legislative and requirements etc.
Establishing data and information requirements – Often, data and information is collected with no clear understanding of how it will be used and this can be costly. Efficiency and effectiveness are delivered by establishing the requirements for information.
Establishing data and information management procedures – When the requirements have been set up, data and information management to support knowledge management can be established. This will include, defining procedures required to maintain the data and information, procedures for access, storage (including backup and recovery), retrieval, rights and responsibilities etc.
Evaluation and improvement – As with all processes, the capture and use of data and information to support knowledge management and decision making requires attention to ongoing improvement.
The service improvement plan, produced by the Service Level Manager, will use the following relevant input:

• Measurements of the use made of the data transactions
• Evaluate usefulness of the data and information
• Identification of any data or information (or registered users) that is no longer to the organisation’s knowledge requirements

The Terminology Of Knowledge Management

SKMS: Service knowledge management System
CMS: Configuration Management System
KEDB: Known Error Database
DML: Definitive Media Library. The secure library in which the definitive authorised versions of all media CIs are stored and protected. The DML should include definitive copies of purchased software (along with license documents or information), as well as software developed on site.
Prepared By: Hıdır ERBAY

2. Change  Management

Why Have Change Management?

Change is inevitable, and the rate of change in technology is increasing and the organisation’s processes and business models constantly have to adapt to the economic climate, competitive pressures, and the opportunity to create through change and innovation. Change management, as a discipline in distributed computing is usually somewhat lacking. Yet, change management for IT operations is critical to improving availability, performance and throughput. Strong operational change management reduces errors, as well as planned and unplanned downtime.
Changes arise for a variety of reasons:

• Proactively, g. seeking organisational benefits such as reducing costs or improving services or increasing the ease and effectiveness of support
• Reactively as a means of resolving errors and adapting to changing circumstances

Changes should be managed to:

• Optimise risk exposure (supporting the risk profile required by the organisation)
• Minimise the severity of any impact and disruption
• Be successful at the first attempt

Such an approach will deliver direct financial benefit for the organisation by delivering early realisation of benefits (or removal of risk), with a saving of money and time.
To make an appropriate response to all requests for change entails a considered approach to assessment of risk and business continuity, change impact, resource requirements, change authorisation and especially to the realisable organisation benefit. This considered approach is essential to maintain the required balance between the need for change and the impact of the change.

The Objectives Of Change Management

The goal of the change management process is to ensure that standardised methods and procedures are used for efficient and prompt handling of all changes, in order to minimise the impact of change related Incidents upon service quality, and consequently to improve the day to day operations of the organisation.
Other objectives include:

• Respond to changing business requirements
• Minimise impact/risk of implementing changes
• Ensure all changes are approved at the appropriate level with the business and IT
• Implement changes successfully
• Implement changes in times that meet business needs
• Use standard processes to record all changes

Not every change is an improvement, but every improvement is a change!

The Scope Of Change Management

Addition, modification or removal of:

• Any service or configuration Item or associated documentation Including
• Strategic, tactical and operational changes Excluding
• Business strategy and process
• Anything documented as out of scope

The Activities Of Change Management

Activities undertaken will involve:

• Change logging and filtering/acceptance
• Does the RFC (request for change) have enough, quality, information
• Unique identification number
• Filter out impractical RFC s and provide feedback to issuer
• Managing changes and the change process
• Prioritise RFCs (based on risk assessment))
• Categorise RFCs (e.g. minor, significant or major impact)
• Chairing the CAB (Change Advisory Board) and the ECAB

(Emergency Change Advisory Board)

• Assess all RFCs (but not all during the meeting!! CAB is a consulting body)
• Impact and resource assessment
• Approval based on financial, business and technical criteria
• The Forward Schedule of Change (FSC)

• Coordinate the change
• Supported by release management, change management coordinates the building, testing and implementation of the change
• Reviewing and closing RFCs
• Management reporting

Emergency changes follow the same steps, but usually in a different order. The ECAB approves an emergency change immediately and the building, testing and implementation are done before the paperwork, which is usually completed retrospectively, but don’t forget the documentation!

The change process

The Value To The Organisation Of Change Management

• Prioritising and responding to organisation and customer/user change proposals
• Implementing changes that meet the customers’ agreed service requirements while optimising costs
• Contributing to meet governance, legal, contractual and regulatory requirements
• Reducing failed changes and therefore service disruption, defects and rework
• Delivering change promptly to meet business timescales
• Tracking changes through the service lifecycle
• Contributing to better estimations of the quality, time and cost of change
• Assessing the risks associated with the transition of services
• Aiding productivity of staff through minimising disruptions due to high levels of unplanned or emergency change and hence maximising service availability
• Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful implementations of corrective changes

The Terminology Of Change Management

Normal change
A change that follows all of the steps of the change process.
Standard change
A pre-approved change that is low risk, relatively common and follows a procedure or work instruction, e.g. password reset or provision of standard equipment to a new employee. RFC’s are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request.
Emergency change
A change that must be introduced as soon as possible. e.g. to resolve a major incident or implement a security patch. The change management process will normally have a specific procedure for handling emergency changes.
Requests for change
Every change to the IT Infrastructure has to go through change management. A Request for Change (RFC ) is formally issued for every change request.
The Change Manager
Responsible for the change management process.
Change Advisory Board (CAB)
A dynamic group of people (depending on the change) that approve changes with medium to high priority, risk and impact.
CAB/EC
CAB Emergency Committee approves and authorises changes with high urgency, risk and impact.
Change models
Some organisations use change models prior to implementation to estimate the impact of the change. Change management and capacity management work together on this.
FSC
The Forward Schedule of Change (FSC) contains details of all approved changes and their proposed implementation date.
Prepared By: Recep ÇOBAN

3. Release and Deployment Management

Why Have Release And Deployment Management

The goal of release and deployment management is to deploy releases into production and enable effective use of the service in order to deliver value to the organisation/customer/user.
The objectives of release and deployment management. The objective of release and deployment management is to build, test and deliver the capability to provide the services specified by service design. This includes the processes, systems and functions to package, build, test and deploy a release into production and prepare for service operation.
Other objectives include:

• To provide clear and comprehensive plans enabling change projects to align their activities
• To ensure that the hardware and software being changed is traceable, secure and that only correct, authorised and tested versions are installed
• To ensure that master copies of all software are secured in the Definitive Media Library (DML)
• To ensure that release packages are built, installed, tested and deployed efficiently
• To ensure that skills and knowledge are transferred to operations and support staff
• To ensure that new or changed services meet the utility, warranty and service levels
• Minimise unpredicted impact
• To communicate and manage expectations of the customer during the planning and rollout of new releases

The Scope Of Release And Deployment Management

The scope of release and deployment management includes the processes, systems and functions to package, build, and test and deploy a release into production and establish the service specified in the service design package before final handover to service operations.

The Value To The Organisation Of Release And Deployment Management

Effective release and deployment management enables the service provider to add value to the organisation by:

• Delivering change, faster and at optimum cost and minimised risk
• Assuring that customers and users can use the new or changed service in a way that supports the organisation goals
• Improving consistency in implementation approach across the organisation change, service teams, suppliers and customers

Release and deployment management activities

• Release policy and planning
• Release design, build and configuration
• Release testing and acceptance
• Deployment and planning
• Extensive testing to predefined acceptance criteria
• Sign off of the release for implementation
• Communication, preparation and training
• Audits of hardware and software prior to and following the implementation of changes
• Installation of new or upgraded hardware
• Storage of controlled software in both centralised and distributed systems
• Release, deployment and the installation of software

Release units
A release unit describes the portion of a service or IT infrastructure that is normally released together according to the organisation’s release policy. The unit may vary, depending on the type(s) or item(s) of service asset or service component, such as software and hardware.
The objective is to decide the most appropriate release unit level for each service asset or component. An organisation may, for example, decide that the release unit for critical applications is the complete application in order to ensure that testing is comprehensive. The same organisation may decide that a more appropriate release unit for a website is at the page level.
The following factors should be taken into account when deciding the appropriate level for release units:

• The ease and amount of change necessary to release and deploy a release unit
• The amount of resources and time needed to build, test, distribute and implement a release unit
• The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure

Release And Deployment Options

Big bang – The new or changed service is deployed to all user areas in one operation. This will often be used when introducing an application change and consistency of service across the organisation is considered important.
Phased – The service is deployed to a part of the user base initially, and then this operation is repeated for subsequent parts of the user base via a scheduled rollout plan.
Push – Is used where the service component is deployed from the centre and pushed out to the target locations.
Pull – Used for software releases, where the software is made available in a central location, but users are free to pull the software down to their own location at a time of their choosing or when a workstation restarts.
Automation – Helps to ensure repeatability and consistency. The time required to provide a well designed and efficient automated mechanism may not always be available or viable.
Manual – Important to monitor and measure the impact of many repeated manual activities, as they are likely to be inefficient and error prone.

The Terminology Of Release And Deployment Management

Release – A collection of authorised changes to an IT service.
Release unit – The portion of the IT infrastructure that is released together, e.g. major release: major roll out of new hardware and/or software; minor release: a few minor improvements and fixes to known errors. Emergency fix: a temporary or permanent quick fix for a problem or known error.
Definitive Spares (DS) – (previously known as DHS) Physical storage of all spare IT components and assemblies maintained at the same level as within the live environment. These can then be used when needed for additional systems or in the recovery from incidents (details are recorded in the CMDB, controlled by release management).
Definitive Media Library (DML) – (previously known as the DSL) the secure library in which the definitive authorised versions of all media CIs are stored and protected. The DML should include definitive copies of purchased software (along with license documents or information) as well as software developed on site.
CMDB – Configuration Management Database.
Prepared By:Güldestan YALÇINKAYA

4. Service Asset and Configuration Management

Why have service asset and configuration management

This process ensures the integrity of service assets and configurations in order to support the effective and efficient management of the IT organisation.
The main reason for configuration management is to gather the information needed (in a non-duplicated manner) about the IT components and how they relate to each other. The reason for this is to ensure that the relevant information is available for all the other processes to ensure that detailed impact and risk analysis can take place.

The Objectives Of Service Asset And Configuration Management

• Account for all the IT assets and configurations within the organisation and its services
• Provide accurate information on configurations and their documentation to support all the other service management processes
• Provide a sound basis for incident management, problem management, change management and release management
• Verify the configuration records against the infrastructure and correct any exceptions
• Plan, identify, control, record, report, audit and verify service assets and configuration items
• Account for manage and protect the integrity of service assets and configuration items throughout their lifecycle
• Provide accurate information to support business and service management
• Ensure the integrity of those items by creating and maintaining an accurate Configuration Management System (CMS) as part of the Service knowledge management System (SKMS)

The Value To The Organisation Of Service Asset And Configuration Management

Optimising the performance of service assets and configurations improves the overall service performance and optimises the costs and risks caused by poorly managed assets, e.g. service outages, fines, correct licence fees and failed audits. SACM provides visibility of accurate representations of a service, release or environment that enables:

• Better forecasting and planning of changes
• Changes and releases to be assessed, planned and delivered successfully
• Incidents and problems to be resolved within the service level targets
• Service levels and warranties to be delivered
• Better adherence to standards, legal and regulatory obligations
• More business opportunities as able to demonstrate control of assets and services
• Changes to be traceable from requirements

The Activities Of Service Assets And Configuration Management

Configuration management  planning
A configuration management plan should define:

• The purpose, scope and objectives of configuration management
• Related policies, standards and processes that are specific to the support group
• Configuration Management roles and responsibilities
• CI (Configuration Item) naming conventions
• The schedule and procedures for performing Configuration Management activities: configuration identification, control, status accounting, configuration audit and verification
• Interface control with third parties, g. Change Management, suppliers
• Configuration management systems design, including scope and key interfaces

Configuration  identification

• CIs are the components used to deliver a The CIs include software, documentation and SLA’s
• Also identify the relationship between CI’s and the attributes for every CI

Control of CI’s
The objective of configuration control is to ensure that only authorized and identifiable CI’s are recorded in the CMDB upon receipt.
Configuration status accounting

• Status reports should be produced on a regular basis, listing, for all CI’s under control, their current version and change Status accounting reports on the current, previous and planned states of the CI’s should include:

• Unique identifiers of constituent CI’s and their current status, e.g. under development, under test, live
• Configuration baselines, releases and their status
• Latest software item versions and their status for a system baseline/application
• The person responsible for status change, e.g. from under test to live
• Change history/audit trail
• Open problems/RFC ’s

Configuration verification and audit

• Service desk staff, while registering incidents, can do daily verification
• Configuration audits should be considered at the following times:
• Shortly after implementation of a new configuration management system
• Before and after major changes to the IT infrastructure
• Before a software release or installation to ensure that the environment is as expected
• Following recovery from disasters and after a return to normal (this audit should be
• included in contingency plans)

At random intervals

• In response to the detection of any unauthorised CI’s
• At regular intervals

Configuration Management Database (CMDB)

• Backup, administration, housekeeping

Prepared By:Aykut YÜKSEK

5. Service Validation and Testing

Why Have Service Validation And Testing?

The goal of service validation and testing is to assure that a service will provide value to organisation.
The underlying concept to which service validation contributes is quality assurance – establishing that the service design and release will deliver a new or changed service or service offering that is fit for the purpose and fit for use. Testing is a vital area within service management and has often been the unseen underlying cause of what was taken to be inefficient service management processes.
If services are not tested sufficiently then their introduction into the operational environment will bring rise in:

• Incidents – failures in service elements and mismatches between what was wanted and what was delivered impact on business support
• Service desk calls for assistance – services that are not functioning as intended are inherently less intuitive causing higher support requirements
• Problems and errors – that are harder to diagnose in the live environment
• Costs – since errors are more expensive to fix in production than if found in testing
• Services – that are not used effectively by the users to deliver the desired value

The Objectives Of Service Validation And Testing

The objectives are:

• Provide confidence that a release will create a new or changed service or service offerings that deliver the expected outcomes and value for the customers within the projected costs, capacity and constraints
• Validate that a service is fit for purpose – it will deliver the required performance with desired constraints removed
• Assure a service is fit for use – it meets certain specifications under the specified terms and conditions of use
• Confirm that the customer and stakeholder requirements for the new or changed service are correctly defined, and remedy any errors or variances early in the service lifecycle as this is considerably cheaper than fixing errors in production

The Value To The Organisation Of Service Validation And Testing

Service failures can harm the organisation and can result in outcomes such as:

• loss of reputation
• loss of money
• loss of time

The key value to the business and customers from service testing and validation is in terms of the established degree of confidence that a new or changed service will deliver the value and outcomes required of it and understanding the risks. Successful testing depends on all parties understanding that it cannot give, indeed should not give, any guarantees but provides a measured degree of confidence. The required degree of confidence varies depending on the customer’s business requirements and pressures of an organisation.

The V model

The V Model concept of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trail and assessment.
The left hand side represents the specification of the service requirements down to the detailed service design.
The right hand side focuses on the validation and test activities that are performed against the specifications defined on the left hand side, there is direct involvement by the equivalent party on the right hand side.
It shows that service validation and acceptance test planning should start with the definition of service requirements, e.g. customers who sign off the agreed service requirements will also sign off the service acceptance criteria and test plan.

The Terminology Of Service Validation And Testing

Validation
The activity that ensures a new or changed IT service, process, plan or other deliverable meets the needs of the business. Validation ensures that business requirements are met even though these may have changed since the original design phase.
Acceptance
Formal agreement that an IT service, process, plan or other deliverable is complete, accurate reliable and meets its specified requirements. Acceptance is usually preceded by evaluation or testing and is often required before proceeding to the next stage of a project or process.
Test
The activity that verifies that a CI, IT service, process etc., meets its specification or agreed requirements.
Evaluation
Responsible for assessing a new or changes IT service to ensure that risks have been managed and to help determine whether to proceed with the change.
Fit for purpose
Describes whether the process, CI, IT service etc., is capable of meeting its objectives or service levels.
Fit for use
Meets certain specifications under the specified terms and conditions of use.

References

•  https://www.axelos.com/ 
•  https://www.ucisa.ac.uk/
•  http://aykutyuksek.blogspot.com.tr/
•  https://hidirerbay.wordpress.com/
•  http://en.it-processmaps.com/
•  http://en.wikipedia.org/wiki/

The relation in between ITIL, Cobit, Togaf and CMMI

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?

---

COBIT is a framework for developing, implementing, monitoring and improving information technology (IT) governance and management practices.
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.

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).

·   Both ITIL and COBIT help organizations to manage IT from a business perspective and achieve business goals while measuring progress and ensuring effective IT governance.
·   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:

·   ITIL goes into further detail and gives better guidance on the core service management topics; COBIT can be used as an umbrella to include other IT aspects like information architecture, system development, portfolio / programme / project management, risk management, security management and many other things.
·   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-