Blow the Lid Off AutomationBlow the Lid Off Automation

In the early days of business process management (BPM), circa 1999, deployments were focused on integrating and automating repetitive processes. When there was a break in the flow, BPM software supported human intervention to quickly resolve the exceptions.

This orientation limited BPM to standardized processes, such as account activation, in which the sequence of activities is unchanging. Yet for most firms, the exception is often the rule. Many business processes are dynamic, not standardized, and thus require the systems that support them to adapt quickly to changes within the business environment.

The greatest value of BPM software is delivered not through automation and integration alone, but by introducing a layer between users and IT infrastructure to allow process to quickly adapt to change without requiring costly coding and IT development work.

To take better advantage of this adaptability, the next phase of BPM will focus on delivering actionable, real-time reporting on process states and performance indicators. With better intelligence, users will be able to see the status of process activities and gauge the immediate and downstream impact of business decisions. We'll examine the maturation of BPM technologies and the capabilities that will set next-generation systems apart.

A Very Brief History of BPM

In the early years of BPM, from 1999 to 2001, initiatives tended to be parochial, integration-centric deployments aimed at closing gaps in existing ERP deployments. Solutions of this period were differentiated by proprietary features such as application adapters, data transformation capabilities and product-specific process definitions.

In the second phase of maturation, from 2002 to 2004, BPM solutions began to resemble ERP more than enterprise application integration. Organizations were building process-centric applications, and the technology had evolved from middleware into a development environment.

At the same time, complementary standards such as Web services and advances in BPM development and design tools lowered the cost and complexity of application and data integration. These trends also advanced one of the fundamental charters (and least-fulfilled promises) of BPM: putting business logic management (processes, business rules, user roles, task descriptions and so forth) in the hands of business managers without threatening the application logic's integrity.

In the absence of BPM, business logic exists primarily in two places: embedded inside applications and IT infrastructure, where it's out of reach to business users, and in the minds of business process owners and subject-matter experts. BPM introduced the ability to abstract business logic so it could be managed and maintained within a separate system by nontechnical business users.

Enabled by standards-based protocols (notably the core Web services stack of XML, SOAP, UDDI and WSDL) and the emergence of service-oriented architectures (SOAs), BPM frameworks gained flexibility and agility in resolving integration issues. Prior to SOA, changing the structure of process documents or data meant taking those processes offline so programmers could manually code each change. SOA provides a common means for communicating between applications so connections don't need to be programmed in advance as long as the BPM environment knows where to find information and how to access it.

Many BPM frameworks today include an embedded or inherent SOA capability, and most can take advantage of external services. This is a critical advance in supporting dynamic processes in which the information, activities and roles required might evolve rather than being predetermined.

Goal-Driven BPM

If integration best described the first generation of BPM, the second-phase equivalent is orchestration. Orchestration has changed the role of BPM frameworks from that of a transit system, designed to shuttle data from one point to another over predefined routes, to that of a virtual power user that "knows" how to locate, access and initiate application services and information sources.

Orchestration-focused BPM frameworks support business performance by applying goals, policies and rules, while adjusting process flow to accommodate outcomes that can't be predicted. In patient admissions, for example, the next step is dependent on the outcome and circumstances of the preceding step. Information discovered in the diagnostic stage drastically alters treatment, and a change in the patient's "state" (such as sudden heart failure) may completely alter the process flow.

This transition in BPM can be described as a shift from event-driven to goal-oriented processes. Earlier workflow and BPM systems provided the ability to stitch together a series of events into a process sequence. These tools supported some variation in process flows, such as splits and joins, but the majority of the process was predetermined. In the goal-driven approach that defines orchestration, processes are defined in terms of end goals and milestones, but you don't need an exact path or process flow programmed in advance.

What differentiates a goal-driven system is the ability to determine the process sequence based on current context. For example, a BPM system can compare the business rules and policies that apply to the current state of a process to determine what step should occur next and what information will be required in that step.

Visibility Drives Performance

In the coming third phase of BPM's evolution, integration and orchestration will be combined with real-time reporting to continuously validate and refine the business users' understanding of performance drivers. This intelligence will enable users to adapt business systems and process flows for maximum performance, and it will blow the lid off what for years has been a black box shrouding automation. With few exceptions, reporting on process events and performance used to be done only after execution — and usually within a separate environment. Changes either required bringing down and recompiling an application or were limited to exceptions and yes/no decision points.

The latest trend in BPM is to provide more sophisticated reporting capabilities within the BPM environment itself. This trend has been both enabled and necessitated by the movement to more flexible architectures and goal-driven process models. Improved integration capabilities, for example, are being exploited to present information on process state via work portals, dashboards and graphical environments. These tools will let business users see the impact changes will have on process efficiency.

Next-stage BPM systems should provide key performance indicators around process throughput, application availability and other performance metrics. Another differentiator will be support for end-to-end visibility into information flow, integration points and performance analytics, such as project milestones and business volumes.

Many systems already monitor the impact of events on downstream activities, determining, for example, whether process backlogs will likely cause a delay, and they'll alert administrators to reallocate workloads. Some vendors are now coupling this monitoring capability with simulation engines to support scenario planning and what-if analysis. Real-time feedback and future-performance metrics deliver the greatest value when they can support decisions and process improvement within a single, closed-loop environment.

The need for better reporting will only accelerate with growing use of business process execution language (BPEL). BPEL will allow process execution to be commoditized and distributed, so larger BPM processes will be calling on many BPEL-based subprocesses that may be executed within other environments. This will demand intelligence on interactions among subprocesses and larger superprocesses.

The more flexible and adaptable the processes and supporting systems become, the greater the need for visibility. And, in the same manner, the greater the ability to monitor and predict results, the more BPM will be identified with maximizing business performance, rather than simply integrating and automating systems and tasks.

Nathaniel Palmer is Vice President & Chief Analyst of Delphi Group, a Perot Systems Company. Write to him at [email protected].