If the title of this article caught your attention, chances are, you are interested in one or more of the following: ITIL, actionable process, or the new IBM Rational Method Composer. All of these are big topics that deserve further study. In this article, I will give you enough information about these topics to be conversational at the next user group meeting, but certainly not enough to be technically proficient in any of these areas. Rather, I want to show how these concepts can be combined so that you can get value from all of them.

What is ITIL?

For those of you long time readers of the Edge, you are probably used to seeing articles about the Rational Unified Process (RUP), eXtreme Programming (XP), and the Project Management Body of Knowledge (PMBOK). So what the heck is ITIL?

ITIL stands for the Information Technology Infrastructure Library and is considered the global standard for IT Service Management (ITSM) best practices. While software development styles like RUP and XP are targeted to the software development subject area, ITIL is targeted towards the IT operations area. It was created in the mid-1980s in Great Britain by the Office of Government Commerce (OGC) as a way to bring some rigor and uniformity to application and infrastructure management.

ITIL is delivered as a set of seven books that cover:

• Service Support
• Service Delivery
• Planning to Implement Service Management
• ICT Infrastructure Management
• Applications Management
• Security Management
• The Business Perspective

While all the books provide valuable insight, most firms that are new to ITIL tend to focus on Service Delivery and Service Support. Service Delivery is broken down into the following areas:

• Availability Management describes how to define application and infrastructure up-time and mean-time between failures. It deals with such concepts as serviceability, recoverability, and reliability.
• Capacity Management describes how to make sure that sufficient and appropriate resources are available based on defined service levels.
• Continuity Management relates practices for managing disaster recovery and outages.
• Financial Management covers how to calculate infrastructure costs and practices that promote cost optimization.
• Service Level Management takes on both the user-facing practices of specifying up-time and support levels as well as the practices to help users understand the trade-offs between support costs and service levels.

Service Support has the following areas:

• Configuration Management in this context deals with identifying and controlling infrastructure types of assets or configuration items (CIs). So where software configuration management deals with controlling code, model elements, etc., ITIL CIs can be hardware, middleware, end-user applications, etc.
• Change Management describes how changes to configuration items should happen. The activities described have a heavy overlap with standard software change management ones.
• Incident Management details how events that are not part of the normal operational process are dealt with. It includes the classification of incidents to set priorities on how they should be reacted to.
• Problem Management is related to Incident Management in that problems, errors, defects, etc., are often the cause of incidents. Problem Management describes how these types of events are handled and resolved via Requests For Change (RFC).
• Release Management describes the practices for bringing software items into the operations environment. It describes both implementation and distribution activities.
• Service Desk describes practices for managing incidents and problems through a centralized capability. It focuses on such key items as a service catalog and knowledge base for incident resolution.

The business case for ITIL

ITIL adoption is typically justified when an organization recognizes three business-related needs.

First, many organizations seek operational efficiencies that lead to infrastructure cost containment. If we step back a moment and evaluate the typical IT budget, we often see it broken down into discretionary and non-discretionary buckets. Discretionary spending is that which is allocated to new functionality to promote competitive advantage. Non-discretionary budgets cover "keeping the lights on." A Gartner survey suggests that the average IT shop typically allocates 75-80 percent of its budget to non-discretionary expenditures. Empirical evidence shows that as much as 10-20 percent of this can be redirected to discretionary funds if the operations organizations adopt rigorous service management processes.

Second, these same entities look for ITIL practices to reduce business continuity risks. A recent client brought a large program of applications back in-house from an outsourcer. In doing so, they adopted RUP and Rational tools to help manage the complexity of application development. When they started transition activities, they quickly faced major risks due to inadequate operational support that nearly caused the overall effort to fail. They have since embraced ITIL as a way to mitigate these risks in the future.

Third, in several firms that I have worked with, the end users drove the adoption of ITIL because of the IT department's inability to meet basic service levels. Let's face it, IT has had a bad report card for some time with many business users. We can't deliver, we take too long or cost too much, and when we get the apps to the desktop, expectations for performance or support aren't met. Several of our client's business communities have reached out to ITIL to solve these problems, because it provides a consistent set of practices and touches on areas that some operations organizations haven't thought about before.

ITIL adoption

ITIL achieved a strong following in Europe more than a decade ago, but has only recently started to gain a following in the US. Despite ITIL's growing visibility, it still remains "under the radar" of a significant number of IT professionals in the US, as evidenced in a 2004 Gartner survey that found 58 percent of respondents (CIOs, IT operations leaders, and data center managers) had little or no knowledge of ITIL. I first became materially aware of ITIL while working with a large financial services client. As the leader of the team responsible for process adoption, I was asked to help reconcile RUP transition activities and ITIL Release Management. It was at this point that I became aware of a fundamental inhibitor to the successful adoption of ITIL.

To help IT leaders get value from the various processes in the marketplace, I developed a categorization scheme based on the IT business process that they were applicable to and the level of ease with which an organization could adopt them. Figure 1 represents a sampling of this analysis.

Figure 1: Process applicability matrix

Further, I defined a categorization scheme for process, breaking it down into one of four categories:

• Best practices. Statements of discrete tasks or smart things to do if you are a practitioner in a given domain. ITIL, PMBOK, and CMMI fit in this category.
• Assessments, measurements, and audits. These processes typically provide maturity models or standards for assessment of an organization in a domain. They often state best practices in the context of this measurement. CMMI again fits in this category as does the Organizational Project Management Maturity Model (OPM3) from the Project Management Institute (PMI).
• Process improvement. These sets of activities help you analyze processes for ways to optimize their efficiency. Examples include Six Sigma and Lean.
• Actionable process. This process provides complete statements about what types of practices a firm should undertake, but also who does them, what they produce, workflows and workflow dependencies, along with specific lifecycle models that describe timeline objectives. RUP is the best example of an actionable process.

Distinguishing among these four types of processes is crucial, because our focus in this article is actionable processes, which are significantly easier to implement and provide greater value to an organization than the other three types of processes.

An additional distinction to make is the difference between a project-related process and operational ones. According to the PMI, projects are objective-based and have clear start and end points (although I've been on some projects that never seemed to end, but that's another article). Operational processes are those that continue ad infinitum and are typically sustaining in nature. RUP is an example of a project-related process; ITIL is an operational one. This is an important difference, as we'll see, because it means that we have to develop a different concept for the lifecycle model than would exist, say, with RUP.

When an organization brings in a set of best practices such as ITIL and provides a mandate for adoption, it faces a number of challenges that are at least somewhat mitigated with actionable process. Non-actionable processes are subject to significant levels of interpretation. For example, when workflows aren't defined, it is up to adopters to derive them from the set of practices. This forces extensive analysis of the practices to determine organizational or role dependencies, artifact ownership, governance approach, etc. It isn't unusual for extensive debate to occur about the contents and formats of templates and reports. I've seen this sort of analysis take weeks, if not months, and still result in less than satisfactory outputs. Finally, process adoption means organizational change. A key to successful change is to be able to clearly define for the people that are affected by the new process:

• What role(s) they will play.
• What skills and competencies they are expected to have.
• What, for a given role, the tasks are.
• What artifacts they will be responsible for and why.
• How they will work together as a team with others.
• How they know that they have been successful.

Actionable processes go a long way toward answering these questions. RUP provides an additional critical element: process tailoring guidance. Too often, processes are applied wholesale without providing flexibility to address varying project complexities or team skill levels.

Actionable ITIL

What does it take to make a process actionable? First, it needs to contain key elements, as shown in Figure 2.

Figure 2: RUP components

Figure 2 represents the process metamodel underlying RUP. This model is based on work from the Object Management Group (OMG) called the Software Process Engineering Metamodel (SPEM). It provides complete coverage of the various aspects of process utilizing the Unified Modeling Language (UML). To make ITIL actionable, these elements must be identified and documented. In addition, the relationships and dependencies must be determined as well, so that, ultimately, a work breakdown structure (WBS) can be generated.

The steps to do this are fairly straightforward, however, the amount of work is nontrivial. The workflow that we use to document ITIL is as follows:

1. Define the top level decomposition of the process. This helps organize the work and manage dependencies. These "buckets" of process translate into disciplines.
2. Identify roles and role groups. If you're familiar with RUP, you know that a role group, say Analysts, has roles that include, in this case, System Analyst and Requirements Specifier.
3. Identify artifacts or work products. These are the tangible inputs/outputs of process execution and can be anything from a document to a configuration setting in a tool.
4. Identify tasks. We follow an approach similar to use-case analysis, where we look for tasks by role and then evaluate the tasks for generalization as a refinement step. Keep in mind that tasks (RUP activities) break down into steps and that, as a general guideline, we try to not have any one activity have more than about ten steps.
5. Define relationships between the elements derived so far. We use roles as the base unit and initially define all relationships relative to them. Next, we'll evaluate, within a domain, relationships between elements (i.e., roles to other roles, artifacts to other artifacts, etc.).
6. Compose workflows. Workflows are assemblies of tasks, defining sequencing, synchronicity (what tasks can be done in parallel or not), and dependencies. In some cases, this step might be performed prior to Step 4, but as we'll see when we look at Rational's new approach to modeling process, this positioning works somewhat better.
7. Gather guidelines, checklists, tool mentors, etc. These are any elements that will facilitate process adoption, use, and governance.
8. Externalize the results. In the past, we used Rational Process Workbench (RPW) to generate modifications to RUP. Now we use Rational Method Composer instead. We'll examine this tool next.

IBM Rational Method Composer

If you've been around the Rational process space for a while or have attempted to customize RUP, you are probably familiar with Rational Process Workbench (RPW). It is a process management tool based on Rational Extended Development Environment (XDE) (a modeling and development tool). While it is a powerful tool, many felt that it was difficult to use. Enter Rational Method Composer (RMC), which offers a complete departure from RPW.

First, RMC is bigger than RUP. While it comes with RUP content libraries, users can author or customize any process within it. Second, as with many of the new IBM Rational products, it is Eclipse-based, which means that it has an industry-standard look and feel. Finally, RMC is much more accessible to users without modeling backgrounds. You still need to have analysis skills, and it wouldn't hurt to have a project management background, but you don't need to be a UML expert to use this tool.

Method: An RMC fundamental

A complete tour of RMC is beyond the scope of this article, but we can establish some basic concepts here. [Editor's note: For more detail on RMC, see the article "IBM Rational Method Composer: Key concepts and scenarios," also in the December 2005 issue.]

RMC traffics in method. A method is the definition of what work will be done as well as the ordering of that work. To author a method, you must define method content (the who, what, and how) and process (when), but these are separate elements, as shown in Figure 3. The key concept here is that when you look at real-world implementations of process, what is common across projects and companies is the artifacts and often the roles. What is not common is how the roles work together or which artifacts they may use. RMC seeks to optimize reusability and ease of customization with this definition. When we use it to make ITIL actionable, we'll start by defining method content, then define the process elements.

Figure 3: IBM Rational Method Composer allows you to author a method by defining method content and its process.

RMC provides mechanisms to promote method extension and customization. Where RPW was typically used to make modifications at an organizational level to RUP, RMC can support project-level changes and in fact promotes this level of process management. For you project managers and governance folks, this is huge! This means that your work breakdown structure and process definitions are synchronized through the tool and can be controlled via the method libraries.

Bringing it all together

By now, you have a basic idea of what ITIL, actionable process, and RMC are all about. You also should have added at least ten three letter acronyms (TLA) to your vocabulary, which is always important in building your resume. Now let's look at how Noblestar uses RMC to make ITIL actionable.

We were engaged by a client to help them bring additional rigor to both their software engineering and IT operations areas. Process engineering played a significant role in this engagement and formed the basis for much of this article.

Following our workflow, our first step was to decide how to decompose ITIL to make the task less daunting. The obvious choice was to break it down along the ITIL discipline lines discussed in the "What is ITIL?" section. Just as there are RUP disciplines for Analysis and Design, Implementation, Testing, etc., there are ITIL disciplines for Availability Management, Service Level Management, etc. These become the building blocks for our ITIL method content in RMC.

We adopted an iterative approach to populating the content, and, based on customer requests, began with Change Management. One note: After creating a standalone version of ITIL Change Management, the team felt that we could have leveraged RUP Configuration and Change Management more and in fact has now started an initiative to create a plug-in that conjoins the two. We were ready to begin populating the packages with roles, work products, and tasks.

Method content

This kind of analysis is very similar to use-case analysis in that you typically start with identifying roles, then describe how those roles function within the system. In our case, we reviewed the ITIL documentation to pull out any and all designated roles and populated the role information with as much detail as we could define, as shown in Figure 4. At this point, we didn't try to populate anything other than the description for the roles.

Figure 4. ITIL change management roles

The work products were identified and entered next. Again, this was largely done by reviewing the documentation and deriving outputs. The more arduous activity of identifying tasks came after and represented the bulk of the work. Where roles and artifacts were easily designated, tasks required the use of abstraction and, in some cases, required extending the information in the ITIL books. Table 1 shows a sampling of the derived work products and tasks.

An important take away from this is that making a process actionable is not simply a matter of transposing it into a process management tool. In fact, that is a fairly trivial matter, especially with a tool like RMC, which makes it easy to organize your content. Rather, the majority of the time is spent performing analysis on tasks and dependencies.

Another part of the method content is to define how the information is to be categorized. For example, how will roles be collected together into role groups? This is relevant because it affects the organization of the content in the final presentation. RMC provides for both a set of standard categories as well as custom ones. Standard categories include:

• Disciplines -- which in our case mirror the ITIL disciplines.
• Domains -- contain groupings of work products. We treat these as we would high-level problem domain packages. They should help practitioners identify type of artifacts by similarity of purpose. In our analysis of ITIL, we stuck with discipline classifications for work products as well, but may reorganize at some point for a better abstraction.
• Role sets -- as mentioned above, are groupings of roles.
• Tools -- are somewhat of an outlier in that you are not enumerating tool categories, but rather the tools themselves. In our case, this included tools such as Tivoli Configuration Manager.

Custom categories can be created for a number of reasons, but most often are created to build reusable views of the method content. By creating a custom category, then assigning various method elements to it, you can compose how information is presented in the final rendered Webpage.

Process authoring

Before I jump into the discussion about process authoring, I need to point out the distinction between tasks and activities in RMC.

You'll remember that one of the method content items we identified was tasks. Tasks are discrete actions that can be decomposed into a number of steps. They are the most atomically manageable unit of work in RMC. ¹ They are capable of being reused in multiple activities or processes.

Activities generally represent an ordered grouping of tasks, as well as the work products, roles, and guidelines. They are created during process authoring as an abstraction mechanism to pull tasks or other activities together into a workflow.

With the method content defined, we next started to build the process and configuration from it. To do this, RMC's capability to define work breakdown structures punctuates another major challenge. While reviewing ITIL for our client engagement, we quickly found that, while there were areas with significant amounts of detail that helped us to identify tasks, there often was not sufficient detail to create task WBS, and the devil is in the details as they say.

In our case, we had the luxury of going to internal resources with service management backgrounds to fill in the gaps. In addition, we worked with our client to develop the work breakdown structure.

Process definition within RMC is broken down into capability patterns and delivery processes. Delivery processes describe the complete lifecycle for a given project type. Examples included with the RMC beta for delivery processes include instances of RUP for small, medium, and large projects. One of the more compelling features is the ability to export delivery processes to Rational Portfolio Manager. Capability patterns are similar in content to delivery processes, but are typically smaller reusable components. RUP examples include use-case analysis or unit testing.

From the ITIL Change Management discipline we derived four core workflows. These were:

• Manage Request For Change
• Manage Change Schedule
• Manage Change to Configuration Items
• Evaluate and Manage ITSM Processes

The first two are clearly in the ITIL Change Management domain, while the other two map better into the Configuration Management and Process Improvement areas. We chose to make all of these into RMC capability patterns.

Capability patterns are populated with activities, which are created by dragging tasks, work products, etc., from the configuration view onto the appropriate breakdown schedule.

This leads to one of my favorite RMC features. If you're familiar with RUP, you are probably used to seeing activity diagrams that describe workflows. I'm a big fan of process modeling and especially of using activity diagrams to describe workflows because they help adopters to understand the context that they are working in. In the old days (with RPW), you created these diagrams in Rose or XDE and managed them as images. Great if you didn't change things much, but hard to maintain otherwise. With RMC, diagrams are synchronized with the schedules. If you're somebody that likes to model process workflows, you can do that in the tool and simply switch to the work breakdown view and there it is. Figure 5 shows an example of an activity diagram, and Figure 6 shows the associated work breakdown solution.

Figure 5: Process activity diagram

Figure 6: Work breakdown structure

For the defined iteration, we identified a Base ITIL delivery process, which ultimately will contain all of the disciplines and an ITIL Change Management delivery process so that we could deliver it standalone.

The final step prior to publication is to define views of the process. In our case, we defined views in a similar way to RUP, that is, with a team focus.

Publishing the final product is then merely a matter of generating the output.

So you have an actionable process. Now what??

I'd love to tell you that by creating actionable processes, all of your troubles will be over and you can take that extended vacation you and your significant other have been thinking about for years...but it's not quite that easy. Documentation of a process is only the first step. To really get value from process, you have to get people to use it on a repeatable basis. You have to get them to internalize well enough that they insist that new staff be trained on it before they start their job. This all leads to the need for organizational change management. But that also is the subject of another article.

ITIL offers significant value for IT operations and support organizations, but as a set of best practices documents, it lacks key components to facilitate adoption and maximize its value. Rational Method Composer provides an environment to not only fill in the missing pieces, but also make the extension and maintenance simpler and easier.

Acknowledgments

My thanks to Barry Snyder and Dan Logan, both of whom contributed to this article.

Further reading

ITIL -- The Office of Government Commerce site for ITIL is http://www.itil.co.uk/

IT Service Management Forum can be found at http://www.itsmf.com

Notes

¹ Tasks are decomposable into steps, making steps the most atomic unit, however, steps don't exist as discrete method elements in RMC.

About the author

Rate this article

Comments

Back to top

Table of contents

• What is ITIL?
• The business case for ITIL
• ITIL adoption
• Actionable ITIL
• IBM Rational Method Composer
• Method: An RMC fundamental
• Bringing it all together
• Method content
• Process authoring
• Acknowledgments
• Further reading
• Notes
• About the author
• Comments

Next steps from IBM

• Try: Rational Method Composer
• Buy: Rational Method Composer

Dig deeper into Rational on developerWorks

Discover knowledge paths

Skill-building guides for Rational, Linux, open source, cloud, Java, business analytics, and more.

Special offers