Many IT organizations are now process-aware for the first time. They use service modes such as IT Infrastructure Library to map out how their islands of operational expertise should work together to deliver high-quality services. Various maturity models exist to measure progress toward implementing their newly minted processes. Run Book Automation techniques are automating repetitive tasks in ways that are more readily coordinated across different groups and IT skill-levels. This is great! Study after study shows that service-aligned processes improve productivity and service quality.
Lackluster history of IT process automation
Yet no process stays the same forever. The most successful implementers of ITIL typically embrace a continuous-improvement approach to processes. IT's service management processes must be able to adapt to changes in expectations, architecture, technology and tools. ITIL processes that have been implemented and automated without anticipating change spell trouble with a capital T.
You need only look at the history of business process re-engineering for the cautionary tale. Most businesses have historically automated their processes statically. That is, they would code it once and assume it would simply repeat forever. When markets shifted -- economic cycles moved up and down and innovation happened --many businesses found themselves stuck with highly efficient ways of doing outdated work. Breaking apart processes that were automated in a static way to create new processes is a nightmare that no sane IT organization should want to go through.
I believe IT has the unprecedented opportunity to do process automation right the first time. Instead of being the barefoot shoemaker's children, IT organizations can become the showcase example of how their business units should implement flexible process automation.
Implementing flexible process automation
Flexible process automation occurs when automated functions or tasks are used and reused in different ways. The ultimate goal is to have processes that can change without losing the cost efficiencies gained with automation. This is true for both business and IT processes.
The catch (isn't there always a catch?) is that there is currently no room in most IT budgets for a full-blown Business Process Management (BPM) suite that automatically models, monitors, simulates and redesigns processes. The question becomes, "How can IT fit innovative process flexibility into its existing projects and budgets?" Let's look at some of the currently budgeted projects to see how IT can acquire capabilities for flexible process management.
Tools for successful flexible process automation
Most enterprises have CMDB projects under way to create a registry of IT assets and service relationships. The old adage "you can't manage what you can't see" remains true even in today's n-tiered, virtualized, rapid development world. If IT's processes are truly flexible then they should be designed with the assumption that the IT infrastructure today will be different from the different from the IT infrastructure tomorrow.
Therefore, workflow engines should have access to this "source of truth" about the current and past state of IT infrastructures. They should also have access to information about the infrastructures' relationship to business services it is supporting, which could be leveraged by the process logic. It is no surprise that CMDB vendors (such as BMC in large enterprises or Symantec/Altiris in mid-sized enterprises) are tackling workflow automation as the next logical extension.
Many enterprises are already investigating solutions with workflow capabilities in them, either as a scripting replacement for low-level repetitive tasks or so ITIL implementation teams can capture the interactions and approval steps needed to manage processes across IT silos. By ensuring that these solutions simplify the effort of designing processes, when it is time for the redesign, the task is not as onerous. Beyond looking for a nice interface, the key here is looking for solutions that implement a model-based approach to capturing the workflow details.
This makes it easy to create modular workflows that can be combined in different ways to create more complex processes. Model-based workflows should also be easier to understand than arcane scripts that simply capture changes to the workflow or insert metrics to determine if it's being consistently followed as insurance against future audits.
These tools should also loosely couple process/workflow design and process/workflow integration. In my opinion, this is the biggest lesson to learn from the history of business process automation efforts. If process design is disconnected from the technology integrating the various application functions, then the design diagrams are simply pretty pictures – useless for controlling how work is actually done. Yet having process design and integration as a tightly coupled entity doesn't work either. This is because any change in the applications, the integration technology or the workflow requires an entire rewrite of the automation – not good.
Service-oriented architecture glue
So how does one loosely couple design and integration? By taking a service-oriented architecture (SOA) approach to implementing the integration aspect of the workflow solution.
Taking an SOA approach to integration means that application functionality is exposed in a self-describing manner and process designers don't need to know details about an application's internal data structure to use it in a process. To implement this on today's budgets and time frames, IT needs to look for solution providers with both strong Web services strategies and adapters for existing management applications.
For example, most enterprises have invested heavily in forms-based technology for problem and change management (basically any helpdesk installed today) and must leverage those investments. Creating flexible processes that leverage forms-based technology requires the workflow's process design features to be loosely coupled with the solution's ability to integrate with those forms.
The integration capability must discover a form's data structure (field names, attributes, etc.), build a custom adapter for the process logic to use, and update the adapter as that form changes over time. Opalis and IBM Tivoli (via MRO acquisition) provide these capabilities in their workflow solutions, whereas BMC and CA package these capabilities into solutions focused at specific processes. The design part of the solution must also be able to update and change the process logic using the adaptor without changing the adapter. Are the adapters just hiding point-to-point integration or are they truly interfaces that expose legacy capability in a standardized way? This is where Web services standards become the preferred way to implement standardized integration.
Going one step further, the solution should also be able to directly leverage Web services interfaces available from management application vendors. This means checking on the progress vendors have made on their product's Web services strategies – and not just the big guys like BMC or CA who've be working on this since 2001 -- but for any product selected, be it service-level monitoring, PC provisioning or database patch management. These products all represent automated functionality that must be used in flexible IT processes at some point in the future. Therefore, selecting vendors with serious efforts to provide standard-based interfaces can only help.
By requiring these foundations within today's budget and projects, it will be easier to leverage them in the future. Doing this makes it possible for IT to avoid the re-engineering trap and to show the rest of the business how to get flexible processes done.
ABOUT THE AUTHOR: Jasmine Noel is Founder and Partner of Ptak, Noel & Associates. She has served as director of systems and applications management at Hurwitz Group and was a senior analyst at D.H. Brown Associates.