American “ITIL” – Winning The Metadata Contest

Old metadata campaigners understand the difficulty in establishing a metadata management program within their IT organization.  After all, metadata management and enterprise architecture strategies frequently look like attempts to “solve world hunger” by “boiling the ocean” (sorry for the mixed metaphors) yet promise little immediate payback.  On the other hand, how many metadata firedrills will it take before establishing an ongoing IT knowledge management framework begins to make sense?  In other words, how many times do we have to be right before anyone listens. 

IT Fire Drills

Let’s list a few examples:

1. Data warehouses that aren’t used because nobody documented what the data means and where it came from.
2. Merger and Acquisitions that don’t work because nobody really knows what all the systems do, what infrastructure runs each system, how data moves between systems, and how do we combine all this stuff anyway.
3. Inability to meet regulatory compliance (i.e. GLBA, PCI) because we really don’t have a list of all the files and databases, let alone which ones contain consumer data.
4. Expanding the length of a primary key field called X by Y number of bytes begets a project that cost Z millions of dollars (fill in X, Y and Z as appropriate for your organization).
5. Outsourcing arrangements that don’t work because your organization has been running on the efforts of individual “heroes” rather than documenting IT knowledge and standardizing processes.
6. And last but not least, let us not forget the mother of all metadata fire drills – Y2K.  How many organizations scrambled to build application metadata repositories and then let all that work slip away after the crisis had past.

What is the common thread in all of these examples – millions of dollars wasted because the organization lacks a reference library of all IT assets and their relationships.

ITIL

So what does “ITIL” (Information Technology Information Library) have to do with all this?  For many of you, especially in the data management field, we probably need to start with what is ITIL.  At the simplest level, ITIL is a set of books (literally) that define best practices for IT processes.  The idea of defining IT best practices in a set of books is the brainchild of the OGC (“Office of Government Commerce”) which is a part of the British Government.  Here’s a quote from their website http://www.itil.co.uk/ –

ITIL® (the IT Infrastructure Library) is the most widely accepted approach to IT service management in the world. ITIL® provides a cohesive set of best practice, drawn from the public and private sectors internationally. It is supported by a comprehensive qualifications scheme, accredited training organisations, and implementation and assessment tools. The best practice processes promoted in ITIL® support and are supported by, the British Standards Institution’s standard for IT service Management (BS15000).

 The ITSMF is an international user group dedicated to promoting IT Service Management best practices and is the vehicle for IT organizations to get involved in the “movement”.  Here’s a quote from the US chapter website http://www.itsmfusa.org

itSMF USA is the United States chapter of the ITSMF international organization which has over 40 chapters. Based on the ITIL framework which was developed in the 1980s, IT Service Management has expanded to support and promote other Service Management frameworks such as ISO20000, COBIT, IS17799, PRINCE2, Six Sigma and many others. itSMF USA is a member driven organization organized in Local Interest Groups (LIGs) and one Student-Special Interest Group (S-SIG) located in over thirty-five major metropolitan areas of the country.

While ITIL covers many IT related processes, of most interest is the “Service Support” and “Service Delivery” books that define the processes listed below.

This article will not detail these processes as most are fairly self evident and the websites listed above contain a wealth of information on the topic. 

CMDB

What is important to know however, is that while ITIL is all about process best practice, the processes are enabled by a metadata repository called the CMDB (configuration management database).  The CMDB is an integrated database that underlies all of the Service Support and Service Delivery processes.  It provides not only a catalog of IT assets (i.e. hardware and software components) but how they relate to one another.  Furthermore (enterprise architects start paying attention), the CMDB also contains a model of all business services, and how those services are supported by the underlying application systems, and how those application systems are supported by the underlying infrastructure.  One of the fundamental principles of ITIL is a focus on moving IT organizations towards managing “services” versus “systems” (i.e. is the “Order Entry”  website up versus is server xyz up).  This requires not only the recording of physical assets in the CMDB, but a conceptualization of the business itself in terms of business services and the automated systems that support those services.  In short, an ontology of the organization enabling impact analysis, where-used analysis, and visualization of the complex relationships between business services, applications, and infrastructure.

The subtitle of this article states that ITIL will re-energize metadata management in the IT organization.  Why is it that ITIL will succeed where past metadata management efforts have floundered?  There are three simple reasons – ROI, ROI, and ROI.  There’s a reason why ITIL is widely implemented in Europe and taking off in America – it works.  Implementing ITIL best practice processes will reduce IT support costs and improve service delivery.  And the secret sauce of ITIL isn’t the process; it’s the integrated knowledge repository called the CMDB that enables process integration and optimization.  Simply put – the ROI contained within an ITIL implementation will fund the creation of the IT knowledge management framework, now called the CMDB. 

All of the above not withstanding, the term “metadata” does not appear in any of the ITIL documentation (nor do ITIL consultants use this term).  While ITIL puts forward a far reaching vision for IT knowledge management, it is hidden inside a vague description of the CMDB itself, and how the ITIL processes are enabled by the CMDB.  The ITIL documents themselves do not provide much prescriptive how-to information on building the CMDB and that is where all you old metadata campaigners come in – run (don’t walk) down to your data center operations area and find out where they are in their ITIL implementation and volunteer your services to help out.

Hopefully this article has peaked your interest in exploring ITIL and the opportunity it presents.  Traditional metadata management efforts are fraught with danger and have experienced high failure rates.  The ITIL CMDB effort will be no less challenging, but has the distinct advantage of the process improvement business model and ROI.  Future articles will delve deeper into the subject by exploring the following areas:

1. The CMDB meta-model as (loosely) defined by ITIL starts out simply enough but presents a bold vision for IT knowledge management.  Vendor tools that support this concept have only recently appeared with features that will be familiar to the “metadata repository” crowd.  Where the meta-model starts and stops, and how it federates with other data sources is an important starting point.
2. The various components of ITIL process ROI are enabled by the CMDB.  Understanding the ROI model will help launch the CMDB effort.  Gathering metadata is all cost; effective usage is where the reward comes from.  A successful strategy will focus on both simultaneously.
3. The technical issues in architecting the suite of tools needed to implement the vision.  Needless to say, ITIL has presented a gold mine to software vendors, who are supplying good functionality and lots of marketing hype.  Sorting through the value propositions and defining the correct tool “ecosystem” will make or break ITIL projects.

This article originally appeared in TDAN in November 2007