Home �   ITIL�  Index

ITIL v3: Bridging the Gap Between IT and Business

May 29, 2008

Augusto Perazzo,Glen Willis

This represents a paradigm shift within IT service management. In the past, ITIL has never explicitly questioned the relevance of a given service but was mostly focused on supporting it in the most cost effective manner. Imagine for instance that you are hired to manage a Barber and Beauty shop. From an ITIL perspective there are two ways you can approach this. In the v2 way, you would roll up your sleeves, inherent a bunch of existing services and look at how you can deliver these services in the most efficient way.

However, following the v3 philosophy, you would first catalogue all existing services, understand your customer and make sure that the services you provide are in line with their needs. That insight would lead you to modify some of the existing services, retire services that are no longer relevant and introduce new services accordingly. Furthermore, ITIL v3 would encourage you to continue to monitor the relevance of your services amidst shifts in consumer tastes.

Which way would you rather approach this if it were your business?

Aligning the IT Service Portfolio to the Business Strategy

Business strategy concerns which opportunities, market segments, products and services the organization will focus upon and how it will gain advantage over competitors in meeting customer needs. Once those are defined then it is time to rally the troops to execute the strategy. However, before execution can begin organizations must decide on the best organizational structure, business processes, systems and services to support it. IT strategy—including which IT services and IT applications are needed—becomes just another component of the greater business strategy.

The Service Deign phase in ITIL v3 provides guidance on how to build a portfolio of services that are aligned with the business strategy. Whereas the Service Strategy phase is concerned with understanding the why and elaborating on what is needed, Service Design is concerned with how to make it happen.

Furthermore, Service Design assesses feasibility of developing such services and that IT possesses the right capacity to meet growing business demands. But above all, Service Design goes beyond the infrastructure requirements and takes a holistic view of how processes, people and platforms, managed internally or by an outside vendor, comes together to best support the overall business strategy.

Organizations should take advantage of the guidance provided in Service Design to ensure that all IT services are created with the ultimate end goal in mind: to enable business strategy and innovation at the most cost effective manner.

New and existing services must pass the following test: the service is relevant under the overall business strategy and it can be provided in the most cost effective manner. If a service is relevant but its cost is prohibitive, e.g., it is not in line with business benefits, then the service should be redesigned and optimized.

Bridging the Gap Between Development and Operations

Unfortunately IT organizations are mainly divided into two groups: engineering/application development and operations/maintenance groups. In this arcane IT world, the app-dev guys are expected to “understand” the business needs, create new and slick applications to support it and toss it over to the operations guys. The latter group then becomes responsible for making sure, sometimes in a miraculous way, that the new app is up and running 24/7 and are charged with day-to-day user support.

Many conflicts have emerged in such a disconnected world. Apps are developed with too little consideration of operational requirements and are built over platforms that are hard to integrate into the live infrastructure. Furthermore, operations staff is poorly trained on how to support user needs and the original creators of the application are often too busy with the next big thing to provide any timely guidance and relief to the ops team. At the end, one group blames the other for production issues but forgets the real losers: the people you are building the app for in the first place.

One of the reasons that IT groups were artificially isolated from each other can be linked to incompatible cultural perspectives. App-dev groups are used to thinking in terms of software development life cycles (SDLC). No matter which SDLC has been used, be it waterfall models or more iterative processes such as RUP and Agile, they all incorporate the concept of phases, going from understanding business and users requirements, designing and building an app to fulfill those needs, to transitioning it to the live environment.