We are certainly not the first to point out this dilemma. IT managers are under increasing pressure to deliver on demanding service requests and to adapt to changing business needs. Processes in search of optimization include a broad spectrum of different tasks, such as:

• IT incident management (fault/problem remediation)
• IT problem management (root cause analysis)
• IT configuration management
• IT change management
• IT release management

IT organizations are realizing that they need enforceable and repeatable IT processes to improve the efficiency, effectiveness, and quality of their IT services (control); drive compliance with regulatory requirements such as Sarbanes-Oxley (compliance); and reliably support key business needs (alignment). Hence, they're looking to proven best practices as a means of gaining control. In this context, the ITIL IT Service Management process framework has become popular as guidance on how to tame the chaos that often thrives in modern data centers. Started in the mid-1980s by the United Kingdom's Office of Government Commerce, formerly known as the Central Computer and Telecommunications Agency, ITIL is now a mature, non-proprietary IT process framework that is industry- and technology-independent. ITIL has taken off over the last years, with an adoption rate of 45% expected in the United States in 2008. In Europe, where ITIL was originated, adoption is already ubiquitous.

Given the significant need for IT process improvement and broad consensus in the ITIL process framework, focus is then squarely on the technical enablement and automation of ITIL processes. BPEL, the SOA standard for process orchestration, provides a solution to implement ITIL process automation. BPEL was designed to leverage existing software functionality from multiple sources, such as ERP systems, service providers, and custom code via Web Service interfaces. It provides orchestration to enforce consistent execution of a defined process across these assets. Furthermore, in BPEL, processes are modular "building blocks" that can be flexibly assembled into larger end-to-end processes.

When USi embarked on IT process automation, it quickly realized that traditional workflow tools would be too restrictive. Today's IT operating environments require a complex network of supporting system and infrastructure components generating a large volume of "events" to continuously sort through. Traditional workflow tools tend to be very linear in terms of how they execute a process flow, with one step following the other. They're not a good fit for the highly event-driven nature of IT management. Also, for USi, the dynamic nature of the approval process across many internal and client systems required an asynchronous solution. This in turn needed to be coupled with a rules engine for defining business logic to determine the necessary approvers at the time of execution. Oracle BPEL Process Manager provided USi with a platform to meet these requirements, including several added features that provide more value from an audit perspective. Each time a process flow executes, the BPEL orchestration engine provides a graphical view of the process flow. This enables end users to determine where a particular approval request currently stands in the overall business process. The BPEL engine also captures all of the task data, such as the approver and time of approval, for presentation to an auditor. And it provides revision control for the process definition to track when and how the process changed over time - invaluable functionality during audit reviews.

Perhaps, most important, USi learned to plan for growth from the outset when implementing Web Services and SOA technologies. Web Services have a way of quickly proliferating when you start automating discrete tasks. If you don't plan for this growth upfront by investing in a UDDI repository, or using other methods for tracking your toolbox of Web Services, you're destined to have multiple services with overlapping functionality. Reuse and repeatability is key to realizing the value of SOA. Using a UDDI repository promotes this by providing a way to locate existing Web Services in your toolkit so you can capitalize on the fruits of the discovery process you went through to find the scripts and automated tasks you converted to Web Services.

For you as an SOA architect or developer, IT operations are a worthwhile opportunity to shine with your SOA skill set. Most certainly, people will be impressed to see how you can service-enable existing Perl code, Unix shell scripts, or VB scripts, and connect them in conjunction with services provided by help desk and system management applications. More than that, you'll be able to demonstrate business value to your CIO and build momentum for a larger SOA initiative in your enterprise. If you want to go beyond the basics of BPEL, the "BPEL Cookbook" (http://oracle.com/technology/pub/articles/bpel_cookbook/index.html) is a great advanced resource to learn directly from your peers.