Hence, by using EM CLI in a Perl script and then exposing the Perl script as a Web Service as illustrated earlier, you can create Web Services for system management operations like monitoring/managing targets, jobs, groups, blackouts, notifications, and alerts. Concretely, sample Web Services could include:

• IT infrastructure provisioning actions such as adding/deleting targets, submitting/deleting jobs, creating/deleting users
• Monitoring functions such as every day send an e-mail list of backup jobs that were still running after 6am
• Management actions such as every week write pertinent information about failed system management jobs to a file and then purge the system management job history.

Our "emcli provision" submits a job that will provision the image file located under the filepath "Images/myimage" on the hardware server target specified in the variable "mylabel." This system management job will run immediately with a reset timeout of 100 minutes. Image properties will be picked up from the file properties.txt overwriting default image properties. The server "stageserver.us.oracle.com:/private/share" will be used as the staging server and "/private/share" will serve as the staging storage for this task executed with "joe" as the username.

Leveraging the technique we described, you can now execute this hardware server provisioning task via a Web Service by launching this command in a Perl script and wrapping the Perl script as a Web Service.

The main advantage in using Perl or shell scripts as a basis for Web Services is that this technique can be very widely applied. Most platforms provide command-line utilities to interact with a multitude of programs, all of which are available to scripting languages. This technique also transcends the Unix world. For example, Microsoft provides administrative utilities under Windows for Exchange and other products via PowerShell. Using Perl, you can invoke any of these commands programmatically and, in turn, expose them as Web Services as illustrated.

Automating an IT Process That Uses the Service-Enabled PERL Script
Now, let's create some value for the organization around the Perl script that we've turned into a Web Service. First, we want to reduce manual intervention, especially by a specialist such as the system administrator, who should worry about keeping the servers up and running, not executing mundane tasks such as provisioning accounts. There's a shortage of skilled system administrators and, besides, any manual intervention is error-prone and comes with a time delay (because many system administrators work off account provisioning requests in batches). Second, auditability is key in IT operations. Large data centers need to conform to audit standards such as SAS 70 (Statement of Auditing Standards No. 70). Frankly, for an application service provider such as USi, this was a key driver for applying SOA to IT operations. USi must comply with a number of audit standards, such as SAS 70 Type II, as part of its own corporate policies and procedures. In addition, USi is also subject to audit reviews by its clients in support of their compliance initiatives for Sarbanes-Oxley, HIPAA, and other regulatory legislation.

Figure 1 illustrates how the service-enabled Perl script is embedded into an end-to-end IT operations process orchestrated by BPEL - the SOA process orchestration standard.

Besides the Perl script, two typical IT operations applications participate in this process. The first is an IT help desk system. USi uses PeopleSoft CRM as its help desk system. Your company might use help desk software from Remedy or Peregrine. Any help desk system has interfaces to interact with a BPEL orchestration engine. The second system is a system management application. For USi, this is a custom-developed application, but it could also be a system such as HP OpenView, IBM Tivoli, or Oracle Enterprise Manager, among others. Again, these systems either have ready-made Web Service interfaces or you can Web Service-enable their command-line interfaces.

The process kicks off with a request for a new Unix account on a specific server entered into the help desk system. It then queries the system management application to identify the server's owner. This owner is asked to approve the request in a human workflow step. Oracle BPEL Process Manager provides extensions to easily implement such human workflow steps. Once approved, the Perl script is called to execute the account provisioning request. Then, the help desk ticket is updated and finally closed.

This process automation produces some major benefits. First, the approval step is electronically documented, which meets SAS 70 Type II audit standards. Second, we limited any waiting time to the necessary human approval step. Every other activity, including the automatic lookup of the owner as well as the execution of the Perl script, is fully automated. The process can be initiated as a Web self-service request with the help desk system simply tracking the activity. Importantly, every BPEL process is again a Web Service. This means that this process can be immediately reused as part of larger business processes. In our case, a fitting context would be an HR employee onboarding process with the creation of a Unix account being one of many other steps. The advantages of repeatability, auditability, and the reduced execution times of the IT operations process are now inherited by the higher-level HR onboarding process, which is important to executive management. SOA has made a true difference to the business.

Your Opportunity to Apply SOA to ITIL Processes
The Unix account creation process was just a very simple example of an IT operations process where SOA can add value. We tried to exemplify how the combination of (1) service-enabling custom management scripts, (2) process orchestration including human approval steps, and (3) tying in typical applications used in IT operations, such as help desk and system management systems, can help streamline IT operations and even higher-level business processes.

To fully grasp the opportunity, you need to understand the current environment in IT operations. Over the last decade, IT environments have grown more and more heterogeneous and so complex. Separate subgroups in IT, such as networking, server, database, and applications management, often act as silo'd organizations using different help desk tools. Moreover, technology components, such as servers, networks, storage solutions, and applications, come with their own management point solutions - narrow in focus and simply inadequate for delivering on the automation and control required. This results in IT operations teams implementing highly inefficient processes that involve significant manual effort. It therefore comes as no surprise that 70% of the IT budget is spent on maintenance, with administration headcount being the most prominent budget line item; 60%-80% of outages are due to human error; and highly paid system administrators are executing mundane, ad hoc, unscalable tasks. In brief: IT operations is ready for process improvement.