Enterprise Architecture in Higher Education

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.    Read more...

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.