EA and ITIL V2 processes – supporting practices

This post is in response to a question from Nick Malik about my thinking of how EA and ITIL relate to each other. In my post on the EA Model I use to help communicate with our community, I added IT Service Management (ITIL) into the V2 graphic. I was not clear about the relationships between ITSM and EA.

This spring I created a presentation for the University of Alaska EA and PM Workshop I was invited to speak and teach at. Instead of just posting the PowerPoint, I thought I would turn it into a post.  

I am not going to give you all the definitions of IT Service Management or the history of ITIL (IT Infrastructure Library).  I want to focus on how EA and ITIL work together in our organization. Note I have not had a chance to investigate all the ITIL V3 changes so this discussion is about ITIL V2.

In ITIL V2 there are two main categories of services under the IT Service Management umbrella – 1) Service Support and 2) Service Delivery.

Looking at Service Support, I will focus on Incident, Problem, Configuration and Change Management.  

  1. Incident Management – we use an incident tracking system (COTS with mods) to record our client’s request for help with technology. The incident tracking system uses “category” and “sub-category” to describe incidents. The values for these two descriptors come from our EA architecture components.
  2. Problem Management – using the same incident tracking system, we can start to relate incidents that look similar and try to determine if they have a common “root” cause. By using common EA architecture components for incidents, we can then determine which components are similar and may require a change or a project to correct the root cause of the problems (group of incidents).  This in turn modifies our EA specifically our Application Portfolio and our Technology Matrices.
  3. Configuration Management – we have not made a lot of progress here but the theory is that the EA architecture components are reflected in the Configuration Management database (CMDB) and can be reported against to see the impact of projects and changes. The real power of the CMDB is to capture and understand the relationship between configuration items (EA architecture components). The CMDB contains the “current state” architecture – as long as it the data is kept up to date!
  4. Change Management – we use a change management application (home grown) and like the incident tracking system, it uses our EA architecture components to describe changes. EA has an approval role in our Change Management process as the Enterprise Architect sits on our Change Advisory Board.

Looking at Service Delivery, lets focus on Service Level, Availability and Capacity Management.

  1.  Service Level Management – we created a Core Services Catalogue and publish it to our community. Think of this as the “default” service level agreement to our clients. In cases where something special needs to be articulated, we will create specific service level agreements that define this. When I think of the three roles of Enterprise Architecture , the Core Service Catalogue is used for guidance, consulting and approval of our EA.
  2. Availability Management – the linkage from this ITIL process is to our EA documents like our Application Portfolio and Technology Matrix. We leverage the attributes in these EA artifacts to assess the ability of an IT component to perform at an agreed level over a period of time.
  3. Capacity Management –  allows us to think about “future state” architecture by considering changes to Business Capacity tied to strategy and service plans, Service Capacity which suggests changes to application, data and infrastructure architectures and Component Capacity which suggests changes to infrastructure architecture.

Hopefully, this gives you some idea of my thoughts on EA and ITIL and why they are complimentary practices.  Looking forward to any comments and suggestions for improvements. Nick, did I answer your question?