How to architect a Service Management System? The Technical View...
Architecting an ITIL based Service Management System for a medium to large enterprise organization requires more than a single picture to be produced. There are typically many stakeholders to take into account and multiple views are required to understand added value, positioning, content and implementation aspects.
This is the third of four blog posts that will each describe a different architectural view on realizing a Service Management System. The third view is called: The Technical View. This view is targeted at system developers, solution consultants and subsystem providers and provides an answer to the main question: "what's inside a service management system?".
And in order to answer the main question a number of related questions need to be looked at, e.g.:
- How to structure and construct the service management system?
- Wat are interfaces and constraints?
- What applications and data are needed?
- What does the infrastructure look like?
- What standards will be used?
Previously in the Functional View we have seen that ITIL v3 is addressing the business problem by putting the focus on services as the main output of a service management system.
Now what’s inside an ITIL v3 based service management system? It all starts in the upper left hand corner of the picture above by defining a service. The business value of an IT Service is created by the combination of Service Utility (what the Service does) and Service Warranty (how well it does it). A sample of this was provided in my previous post.
Going through its lifecycle (strategy, design, transition, operation, improve) the service is broken down into the service assets that it consists of. There are two types of service assets:
- Resources – this is what everybody has or can obtain in the market. Resource types include People, Information, Application, Infrastructure (incl. IT infrastructure and Facilities) and Financial Capital
- Capability – this is how you apply / use the available resources and what makes an IT organization unique / different. Capability types include Management (incl. e.g. project management), Organization, Processes, Knowledge (read: resources know-how) and People
As you can see People have a unique position as they are both a resource and a capability. ITIL v3 provides most guidance on IT Processes. What is often not explicitly indicated in ITIL v3 is when/how an IT process should be applied to a services as a whole and when/how an IT process should be applied to one or more service assets(!). For example you can do change management on an entire e-mail service and only on the e-mail application. This ambiguity leads to sometimes very heated discussions: e.g. whether application management is an integral part of service management or a more detailed layer underneath service management. The end user typically doesn't care as it is transparent to them, however within IT is crucial that everbody knows their position and role in the service management system.
In many presentations and customer conversations that I encounter it is indicated that service management only requires to organize people, process and technology. Altough this is largely true, what is often missing is:
- An indication of how these topics are interrelated
- The service asset types: information and financial capital
In this picture I am showing the high-level relationships between the service asset types: people, process and technology (read: application + infrastructure). It all starts with the notion that processes consist of activities that are performed by one or more people and/or one or more pieces of technology. Management software (as part of technology) integrates with each other and help to (further) automate the ITIL based processes. The integrations between the technology pieces represent information exchange and/or a workflow continuation.
As every (potential) service provider has a unique collection of resources and capabilities (otherwise there is no differentiation), it is impossible to create a detailed one-size-fits-all single technical view for a service management system. What typically happens is that multiple pictures are being created each modeling a different service asset type e.g. by following The Open Group Architecture Framework (TOGAF) approach; an infrastructure architecture, an application architecture, an information architecture, etc.
Another approach is to create a service model for each service that breaks the service down into its service assets and shows how the service assets are interrelated. This is the ITIL v3 recommended as it relates to the integrated CMDB as part of the Configuration Management System.
Which approach do you prefer / take?
Regards,
Jeroen Bronkhorst
