Two papers recently published on IBM developerWorks ("Introduction to IT service management Part 1 and 2" -- see Resources) introduce you to the world of IT service management and its relation to the IT Infrastructure Library (ITIL) standard and set of best-practices. The papers describe how IBM can enable an enterprise to better implement an ITIL-based approach to service management through IT process modeling, process choreography, and self-managing autonomic technology.
In this paper, delve a little deeper into the ITIL processes and their sub-modules. Then take a look at how you can leverage ITIL-based canonical domain models and an Enterprise Service Bus (ESB) to provide a messaging infrastructure that can integrate and automate applications catering to IT service management concerns, while still helping your enterprise realize its vision of Service-Oriented Architecture (SOA).
ITIL is currently the most widely-adopted approach to IT service management available and provides a set of best-practice guidelines for IT service management developed by the British office of Government Commerce. The ITIL guide breaks down the key principles of the IT service management discipline into the following sub-categories, which are collectively known as the ITIL framework (see Figure 1).
Figure 1. The ITIL framework
As you can see from the diagram above, the Business Perspective module is closely aligned to the Business, and the ICT Infrastructure Management module is closely aligned to the Technology. The Planning to implement Service Management module handles all the issues and tasks involved in planning, implementing, and improving the IT service management processes that will be deployed.
The Service Management module is really the crux of the framework and contains the Service Support and Service Delivery sub-modules within it. The Service Delivery module covers the processes involved in planning and delivering IT Services, and the Service Support module describes the processes required for those IT Services' daily support and maintenance. The Application Management module details the processes required to manage an application through all phases of its application lifecycle. Security Management (which is all too often left as an afterthought) is a concern that cross-cuts many of the processes in the other modules of the framework, and the security processes in the framework are displayed as such.
The Service Delivery and Service Support modules are comprised of many business processes that are involved in properly managing these concerns. Figure 2, when expanded, displays a detailed look at the end-to-end ITIL Model. You can see that each of the parent categories in the ITIL taxonomy displayed in Figure 1 is fully expanded when you click to view the detailed image below.
Apply Domain and Model Driven design principles to the ITIL framework
In order to automate the business processes for these service management domains, IBM created applications that work to greatly reduce the human involvement required to complete a given process. The "Introduction to IT service management" series I mentioned earlier espouses the value of modeling your business processes to help achieve this. Domain and Model Driven design works hand-in-hand in this regard.
At this stage you might be wondering what I mean by the term domain, mentioned at the start of this section. Let me start by stating that Webster's dictionary provides several definitions. Of those, in this context, two are most applicable. A domain is defined as:
- Territory over which rule or control is exercised.
- The set of values of the independent variable for which a function is defined.
Wikipedia defines a domain as the following:
- The application domain of a software system is the type of tasks for which the system is used or intended to be used. This is closely related to a software engineering domain. Examples of application domains are insurance, computer-aided manufacturing and administration.
- A software engineering domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in that field.
If you take a closer look at the Problem Management business process as an example (which is a sub-category of Service Support in the overview featured in Figure 1), you see that it has a particular scope, and within that scope there are certain processes and activities that are specific to Problem Management and which are native to that particular business process (such as Create Problem Ticket, Update Problem Ticket, Process Misdirected Problem Ticket, and Close Problem Ticket).
Starting with a Domain Driven design approach lets you first obtain a deep understanding of your business domains (such as the ITIL Service Delivery or Service Support modules), which is actually intrinsic to getting the Model Driven design correct (the next step). Using the knowledge capital gained within the domain modeling, you can create models of the business processes involved in those domains and then choreograph those processes and implement applications that leverage those same processes. Applying this approach to ITIL lets you make great strides in your attempts to automate service management processes. For more information on Domain Modeling, please take a look at the book Domain Driven Design (see Resources).
Apply SOA design principles to the ITIL framework
Once you have the domain modeling, business process modeling, and business process choreography completed, the next step is to expose those processes through SOA. With the advent of SOA and web services, you can now share this business process data between applications built by different vendors that support the same domain. An example of this would be to use web services to exchange Problem Management data between an IBM e-ESM system interface and a Remedy or Peregrine system interface. Incidentally, Ali Arsanjani has written an excellent set of articles on Service-Oriented Modeling and Architecture, Service Oriented Integration and a Service Integration Maturity Model that can provide more information on how you can accomplish this (see Resources).
However, this story is not quite complete. Although both vendors might be able to process their own data within the Problem Management service requests and responses, without the use of a common Problem Management SOA services vocabulary (also known as Canonical Domain Standard), they won't be able to understand the data or transaction requests that other vendors' Problem Management applications send to them. Thus, both applications need to be using the same canonical standard for Problem Management service transactions in order to be able to communicate without the means of a mediator.
In essence, Web services provides a common communication model; however, a common data model is still missing.
Create a canonical domain model
Domain and Model Driven design is an iterative process. At this phase, you have to go back to the domain knowledge capital, process models that currently exist, attempt to analyze the business processes that are involved in the domain, and distill them down to a concrete set of verbs (actions such as Create, Update, Misdirect, Close for Problem Management), nouns (data objects such as Customer, Server, Problem Ticket), and associating canonical data models. Each application then needs to be able to send and receive data according to this standard, either natively (preferred) or through the use of a specially-created adapter that performs translations to the canonical format on behalf of the application.
If you have several applications supporting the same domain, then creating a canonical domain model provides a common language for the applications in that particular domain to communicate. New applications supporting that domain will automatically be able to integrate and exchange data with existing applications, providing they use the same canonical domain model. This common language also creates a set of common terms and processes (or shared knowledge capital) which makes the human interactions and discussions involved in managing the domain much simpler.
If your Web services interface does not inherently support a canonical domain model, then it needs to make use of an adapter (which are your on-ramps/off-ramps to the ESB for your applications) to convert outgoing requests to the correct canonical data model for that particular domain before placing a message onto the ESB for delivery to its target application. For example, a Problem Management application needs to convert outgoing messages from its proprietary data model to the Problem Management canonical data model, and vice versa, for incoming messages.
The data type for the schema of the messages for the canonical data models is also important. Since XML is such a ubiquitous standard and with its inherent support within the Web services SOA standard, I think it's a fairly obvious choice.
A data dictionary should also be created that describes each field in each XML schema within the domain model. It should specify what each field means, the values it should reflect within different scenarios, the data types it supports, as well as any other helpful data that someone might require in order to map their proprietary XML schemas onto the canonical data format.
A simple example of a canonical domain model is reflected in the diagram below. One way of implementing this approach might be to have a standard set of XML header fields for every payload that describes which verb (Create Ticket, Update Ticket, and so on) the payload is for. You could then provide the actual payload accompanying the verb in a set of Body tags in a field that is a sibling to the header.
Figure 3. An example of a canonical domain model for Problem Management
Apply a canonical domain model to your ESB
An ESB is a set of infrastructure capabilities implemented by middleware technology that enable SOA. The ESB supports service, message, and event-based interactions in a heterogeneous environment, with appropriate service levels and manageability. It can provide routing, mediations, and security (among many other things) for your application. This infrastructure also allows heterogeneous, disparate applications to connect to it and send and receive messages with any other application that is also connected to it.
Rick Robinson's article ("Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture") provides a greater definition of what an ESB can deliver within various scenarios (see Resources).
Once you have your ITIL-based applications with Web services interfaces that expose your Business Processes which exchange data according to a particular canonical domain model, you can connect them to an ESB. The ESB provides a centralized messaging infrastructure through which to route all messages that are sent and received by the applications managing IT service management concerns, and hence automatically integrate your applications that support your various ITIL domains.
One clear advantage of incorporating a set of canonical domain standards within your ESB is that, once an application complies with a canonical domain standard and is connected onto an ESB, another application that is also connected to the same ESB and complies with the same standard is able to immediately integrate with it. If implemented properly, this completely removes the need for any kind of mediations or translations for the two applications to communicate and greatly increases your ability to automate integrations.
Figure 4. An overview of the ESB
Service management is a concern that cross-cuts a lot of industries. A lot of industries have taken service management concerns and created industry-specific proprietary standards that wrap these concerns within them. This is a problem, because these concerns shouldn't be tied to a particular industry. At present, there is the IT Infrastructure Library (ITIL), which is a set of guidelines and best-practices, but unfortunately it doesn't provide standards for the more granular aspects of service management. IBM Tivoli and IBM Global Services (among other IBM groups) provide solutions that address this need and are active in standards organizations to help drive the creation and adoption of industry standards relating to service management that will allow these to be used across industries.
The long-term vision is to create a catalogue of ITIL-based canonical domain models based on the business processes for the service management domains that are part of IBM business and to assist application owners to adopt these standards using its IT service management strategy. This should greatly reduce the time and cost and let you automate what once required several months of manual effort.
The author would like to thank Stewart Hyman, Jay Smith, Erin Boyd, and Brian Snitzer from IBM Integrated Operations for their help in defining and articulating these concepts.
- Introduction to IT Service Management, Part 1 -- Discover the process integration for IT service management strategy (developerWorks, May 2005).
- Introduction to IT Service Management, Part 2 -- Describes six key IT process categories and how self-managing autonomic technology is at work in various IBM products to automate the individual tasks that make up each process (developerWorks, May 2005).
- The Key to Managing IT Services -- Get more information on ITIL.
- Domain Driven Design Web site -- Learn more about the concepts contained within Domain Driven Design.
- Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture -- Learn more about the ESB (developerWorks, June 2004).
- Service-oriented modeling and architecture -- Learn more about SOMA (developerWorks, November 2004).
- Toward a Pattern Language for Service-oriented Architecture and integration -- Focus on the migration, modeling, design, and implementation of SOA (developerWorks, July 2005).
- Increase flexibility with the Service Integration Maturity Model (SIMM) -- Apply the seven levels of maturity on the path to SOA adoption (developerWorks, September 2005).
- Domain-Driven Design: Tackling Complexity in the Heart of Software -- Find this book at Amazon.
Stephen Watt is a Software Architect working on middleware integration solutions within the Global Technology Integration and Management Competency for IBM Integrated Operations at the lab in Austin, Texas. Steve works extensively with WebSphere, Web services and the Enterprise Service Bus and spends his time figuring out how emerging standards, products and technologies can create, automate or improve Service, Network and Infrastructure Management processes. Prior to working for IBM, Steve spent several years consulting in the Middle East and working for startups in the USA and his native South Africa. Steve is the co-author of Professional .NET Programming for J2EE Developers and The ASP Maintenance Handbook (Wrox Press) and has also published several articles at ASPToday and IBM developerWorks. You can contact Steve at swatt@us.ibm.com.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags