• Team / Technical Lead
• Microsoft Consultant
• PROGRAM MANAGER - PERMANENT...
• State Sales Manager - Complex...
• IT Network Engineer - West Sydney

The ABCs of BPM

Bruce Silver, Information Age

12/04/2006 11:14:49

While the service oriented architecture (SOA) market continues to gain heat, fuelled by increasing attention from major vendors, Sydney-based Perpetual has hurdled SOA to adopt business process management (BPM) to gain end to end visibility over its core processes.

Perpetual - its name since January this year when it changed from Perpetual Trustees after more than 120 years and moved into new CBD headquarters - is using Savvion's pure play BusinessManager to automate its human-centric processes.

According to David Doust, founder of local Savvion rep Adaptive Edge, BPM as a solution goes beyond SOA's primarily architectural approach to model, simulate test and optimise processes.

"We see SOA as preparing the ground for BPM," he says and cites a house-building analogy: "If SOA can do the earthworks for the foundations, so can BPM - and build the house as well."

Having set up Adaptive Edge three years ago as an adviser to the financial services sector, and subsequently joined by process improvement specialist Guy Baldwin to add Wall St experience to the local operation, Doust has seen initial market confusion clear to rapid growth.

"There has been a steepening interest curve since mid-2004; previously we were explaining what BPM does and now we're focusing on solution design and discussing Savvion delivery partnerships with systems integrators.

"BPM has five flavours: enterprise application integration (EAI), workflow, content management -- and pure play which is enterprise-wide human and system process automation with business activity monitoring (BAM).

"The first four require unnatural acts to achieve end-to-end automation."

While Perpetual is Savvion's first site in Australia, it lists Johnson & Johnson and Bank of America among the 20 Fortune 50 customers it has in the US. Savvion was selected from three local vendors and the new suite will go live at the end of May.

"Perpetual were looking for rapid implementation for end-to-end control," Baldwin says. "We could offer enterprise deployment in a 90-day project.

"Unlike ERP, BPM has a short time delivery model, fast skills transfer and can quickly build an effective process bridge between the business and its IT capability."

The benefits claimed by BPM (business process management) software sound almost too good to be true. Proponents crow about lower app dev costs, shorter time to market, improved compliance enforcement, and new points of leverage for optimising business performance. BPM software can't improve anything by itself, of course -- but it can be a powerful weapon when combined with business-oriented documentation and analysis. Within its own controlled, high-level app dev environment, BPM wraps IT solution development within business-driven modelling and performance measurement.

At the least, BPM provides an effective new medium through which the business side can communicate its requirements to IT. At best, it can distill functionality from existing applications and free business logic from the bonds of existing infrastructure to enable unprecedented agility. One persistent problem for potential adopters, however, has been abject confusion. BPM solutions come in so many varieties that only a handful of consultants seem to know which solution is best for the task at hand.

Today, clarity is emerging in the form of the BPM suite, an integrated set of tools and runtime components designed to create software analogues of business processes. Together, these elements allow customers to model, deploy and monitor BPM systems without having to staple together bits and pieces of technology from different vendors.

Properly utilised, BPM suites account for the fact that the internals of elemental process activities -- particularly those implemented by existing business systems -- may be difficult to modify. Instead, BPM suites enable IT to optimise business performance by changing the process logic that interconnects them. Process design in a BPM suite is akin to a flowchart, annotated with the necessary implementation detail. It requires little code, and the process logic is easily changed, qualifying BPM as a style of agile application development.

The basic BPM flow BPM begins with process modelling, a business-driven exercise in which current and proposed process flows are documented in detail, linked to quantifiable performance metrics, and optimised through simulation analysis.

These optimised models automatically generate the skeleton of the IT implementation in a BPM suite's process designer, a graphical development tool that integrates human workflow, application integration, and business rules to create an executable process solution. Completed process designs are then deployed to the process engine and other components of the BPM suite runtime, where they route and track tasks, integrate with external business systems, and enforce business rules.

As process instances complete each activity, the process engine generates an event to mark the occasion. Those events are collected by the BPM suite's performance management component, which aggregates them into metrics that measure business performance. Performance management dashboards graph metrics versus their target values, with drill-down analytics via OLAP queries. They also provide real-time alerts and automated escalation procedures when KPIs (key performance indicators) go off track, a capability of the BAM (business activity monitoring) component often bundled with a BPM suite. Actual performance data can be fed back to refine process models and begin a new cycle of incremental process improvement.

Process wars Tally all that functionality, and you end up with quite a stack: software for business modelling, simulation analysis, human workflow, application integration, data mapping, business rules, performance analytics, BAM and Web portals. All of these originated as independent tools from specialised vendors.

But today, within the BPM world, the trend is toward wrapping all these components inside the BPM suite, whether through mergers and acquisitions, OEM, or integration partnerships. This shift has created conflicts between BPM suite vendors and suppliers of modelling tools, BAM, and integration middleware, each of which tends to describe BPM in its own way.

Perhaps the greatest source of confusion, however, has derived from the two competing technical architectures for BPM. The one that has had the most media attention is based on the BPEL (Business Process Execution Language) standard, which implements processes by orchestrating Web services within an SOA environment. This is where the large infrastructure vendors play, including IBM, Microsoft, Oracle, and SAP. On the other hand, most pure-play BPM suite vendors -- such as Fuego, FileNet, Pegasystems, and Savvion -- use an architecture that evolved from the workflow systems of the 1990s, one better suited to incorporating human tasks in the process model. In these offerings, SOA and BPEL play a more limited role and focus on application integration, rather than describing the end-to-end process.

The bottom line is fairly simple. The big-vendor solutions that emphasise BPEL work best for composing Web services into applications that involve little human workflow -- that is, without multistage handoffs to various users in various roles in an organisation. Pure-plays have long emphasised implementation without programming, so their BPM solutions tend to provide the straightest line to a practical BPM deployment. The downside is that, as opposed to their big-vendor competitors, pure-plays' offerings can be more difficult to integrate into an existing application environment.

Modelling reality Whether from a big vendor or a pure-play, modelling tools have one main purpose: to describe business processes in terms of their elemental activities and tasks, the resources required to perform each task, and the business rules interconnecting them -- all using a graphical notation understandable to business users.

Models play a critical role in aligning process design with quantifiable performance objectives and optimising expected results through simulation analysis. By annotating each process activity with performance-related parameters such as expected time to perform, resource costs, availability, and branching ratios at forks in the flow path, models can be analysed in a variety of scenarios using a simulation engine built into the modelling tool.

In advanced modelling tools, the KPIs that will be used to measure the performance of the process implementation determine the parameters required in the model, ultimately closing the loop of performance improvement. This requires models that go beyond simple descriptions of activity flow to include modelling of organisational resources, process data, and process performance metrics.

For years, these capabilities have been the exclusive domain of business process modelling tools from vendors such as Casewise, IDS Scheer, Popkin (now Telelogic) and Proforma, often as part of a broader suite of enterprise architecture tools. Now, however, vendors such as Global 360, IBM and Savvion are implementing the process modelling functions of these tools within the BPM suite itself. At the same time, modelling vendors are improving interoperability among BPM suites by leveraging BPMN (business process modelling notation), a standardised graphical notation from the Object Management Group.

Where once the output of process modelling was a business-oriented specification intended to guide IT in any implementation efforts that might be needed, BPM assumes an automated process implementation will be executed on the process engine. Modelling standards such as BPMN and interchange formats such as CIF allow the output of a modelling tool to be imported into a BPM suite's design tool and a skeleton implementation design to be generated. This skeleton design lacks the implementation detail to be executable off the bat, but it creates a business-specified starting point.

The closed-loop problem Even with standard BPM design languages such as BPEL, each vendor's process design tool is specific to its own runtime environment. Today, there is no such thing as a portable process design that can be executed on your choice of process engines -- unless, of course, you consider human tasks, business rules, and complex data mapping to be "external" to the business process design.

Most BPM suites today provide a unified design environment that hides the complexity of combining human workflow, application integration, business rules, and transaction management within a single executable design. The benefits this provides over treating these process components as independent entities in the enterprise architecture stack are a common data model and common state management over the entire end-to-end process.

Like modelling, process design is mostly graphical. The tool provides a palette of activity types from which the designer selects, configures, and assembles the process steps. Unless custom activities need to be created, process design involves minimal programming. Behind the graphical design metaphor, the tool creates an executable process implementation in the BPM suite's particular process execution language.

In BPM suites based on workflow architecture, the language is typically proprietary but compliant with the XPDL (XML Process Definition Language) standard from the Workflow Management Coalition. Process activities may be one of several predefined implementation types (Web service, user task, integration activity)‚ each assigned to a resource, such as a human task role or an integration adapter. The configuration dialogue for each activity depends on its type.

By contrast, BPM suites based on service orchestration rely on the BPEL language standard. BPEL provides a single activity type -- Invoke -- to call a Web service, human task, or integration adapter, all of which must be implemented as a service, with an interface described by WSDL. But Invoke must be addressed to a service end point -- a URL, not a task role. To accommodate human tasks, what gets invoked by BPEL is not the user task itself but a task manager service, which handles the workflow details.

Another difference is that workflow-based BPM suites support the notion of a subprocess, a reusable process fragment that shares context data and state management with the calling parent. BPEL provides no such concept. A subprocess is another BPEL process; data sharing and state synchronisation must be explicitly defined in the process logic. To address these real-world limitations, IBM and SAP last summer outlined optional extensions to the BPEL standard, but the specs are not yet complete. In the end, regardless of architecture and coding differences, BPM suites tend to accomplish the same set of core functions.

Rolling out process-driven apps The completed process design is then deployed to the process engine. As each instance of the process is triggered, the engine routes it through the defined sequence of activities, integrating external applications, routing workflow tasks to human participants, and managing deadlines and exceptions throughout the process. In offerings from app server vendors such as IBM, Microsoft, Oracle, or SAP, the process engine leverages unique capabilities of the app server and its associated middleware. Offerings from BPM pure-plays tend to run on the user's choice of app server platforms.

The process engine also reports snapshots of instance data and state, usually in the form of events, for the purposes of performance management. The performance management component of the BPM suite collects those events and uses them to update KPIs and other performance metrics defined in the modelling phase.

Typically, metrics are aggregated in OLAP cubes, which can be charted and queried by users in management dashboards. OLAP-based performance management provides historical and "near-real-time" reporting and drill-down analytics, as updates are performed on demand by re-crunching the collected data set. Some BPM suites, including those offered by Adobe, FileNet, IBM, Intalio, and Savvion, support true BAM, providing real-time updates of selected KPIs with rule-triggered alerts and escalation actions. Metrics computed from running processes can be used to refine the model parameters used to generate expected values of those metrics, making the effect of process changes more predictable and stimulating additional rounds of process improvement.

The BPM choice Picking the right BPM suite is a real challenge. Although virtually all the vendors promote the same list of capabilities in their brochures and Web sites, each offering is actually tuned to the requirements of a fairly narrow set of process types or use cases. For example, a BPM suite designed for transactional, "straight-through" processes involving complex application integration but little human interaction might not be the best choice for collaborative, human-centric processes with minimal integration. Document-centric processes and production workflow processes where pools of users draw tasks from shared queues at high speed have their own unique requirements addressed by some, but not all, BPM suites.

Such complications aside, BPM is offering real return on investment to users today. When presented as an architectural stack, it can sound like a tangled mess. But the new generation of integrated BPM suites is untangling BPM and providing a new middle ground for business-IT collaboration.

Sidebar

Modelling employee background checks

By Ephraim Schwartz

Sterling testing systems never actually called the solution they came up with BPM (business process management) until after the fact, says Paul Mladineo, vice president of strategic development.

But Mladineo and his team, headed up by CTO Michael Richardson, certainly understood the challenges faced by their company, which specialises in pre-employment screening and background checks. They ultimately chose a BPM system from Fuego for the task.

"The data we collect is a commodity, not proprietary," Mladineo says. The task, then, was to differentiate the company's services from the competition, which taps the same information.

Because the data is publicly available, Mladineo knew that the data quality, delivery, and services wrapped around the information was how they could achieve this. However, Sterling faced one additional challenge: Managing and mapping unique customised services for 4,000 customers was not what Mladineo called "commercially efficient".

What was needed was a BPM solution that could model the sourcing processes and reuse process components where applicable -- and then employ logical branching in order to accommodate a wide variety of clients and services. "Employment verification for day care centres is quite different than licensing for driving a tractor trailer," Mladineo says, and yet the process of employment verification itself has some common attributes.

The IT goal was to expose meaningful results to clients with many different formats and kick off alerts, in some cases using XML messaging, and to do it on a scale that could accommodate Sterling's numerous clients.

"With this repository of process components, we can build, configure, and test processes, and it doesn't require hard-coding," Richardson says.

The process started with flowcharting the "as-is" business processes, which gave them the opportunity to automate and reuse pieces of the processes that were similar and then to use branching to accommodate customisation.

"It is one thing to do that with a Word document that is sent around, but another thing entirely to translate that to a logical infrastructure running on servers," Richardson says.

The ultimate goal is to cut the amount of time it takes to complete a typical piece of work by 25 to 40 per cent. Of course, there is always a disconnect between design and execution.

"Using Fuego, we were able to create the connections between the theoretical process and execution by having a common visualisation tool used by both the technical folks and business folks," Richardson says.

Is it a roaring success? Mladineo says it is still early in production, and they don't have a full set of data back, but the mere process of modelling the current system has brought to the surface inefficiencies in the production level. "The rigour required to do it with a tool forced a lot of internal discussion."

Sidebar

Building a workflow for insurance reps

By Ephraim Schwartz

With more than $US3 billion in sales and more than 2.3 million customers, 100-year-old American National Insurance Company (ANIC) has quite a few legacy systems in operation.

The greatest challenge for ANIC was around customer service. "Customers wanted information about the relationship between us and them," says Gary Kirkham, vice president and director of planning and support at ANIC.

Although CSRs (customer service reps) went to great lengths to satisfy a query, it often would mean a handling time of 10 or 11 minutes, as reps drilled down into one system for a piece of the answer, logged out, and went into the next system.

"The reps had to have enough talk that was meaningful while they worked between systems," Kirkham says.

ANIC wanted one interface with all the data immediately accessible to the CSRs. When Kirkham started the project in the 90s, the process was called "technology-enabled selling", he recalls, and it was only after Gartner redefined the market in early 2000 as BPM that the name came to mean something more.

After the processes have been modelled, Pegasystems is used to log on to all of ANIC's legacy systems when a request comes from a workstation. A transaction is launched and comes back to a clipboard behind the scenes of the workflow. When a customer call comes in, Pegasystems taps into the various customer files and history and sends the information up to the CSR. "Depending on what the customer asks for, different business rules are enacted that take the CSR down different paths," Kirkham says.

The original goal was to put the CSR in a position to help the customer as quickly as possible. As that improves, ANIC has a secondary goal of optimising and automating processes.

When an insured customer dies, for example, it triggers an entire set of processes that used to be done manually. "Once Pegasystems knows an insured has expired, it processes automatically all the things three people used to do," Kirkham says.

The results for ANIC have been quite dramatic. Kirkham credits the new system with increasing sales in its annuity division from $750 million to $2.2 billion two years in a row. It does this by helping ANIC's 80 independent brokers differentiate among callers by which ones produce the most sales.

"Through our business rule, we can service one of these customers usually within 15 seconds," he says.

Sidebar

Evaluating anti-terror technology

By Ephraim Schwartz

Business process management even has a place in the war on terror, according to Indy Crowley, research staff member and acting lead for IT at the Institute for Defense Analysis (IDA), an organisation that evaluates technology under the SAFETY (Support Anti-Terrorism by Fostering Effective Technologies) Act of 2002.

In support of the SAFETY Act, companies submit technologies and services to IDA for evaluation. At any one time, IDA might be juggling 50 different "applications", as they call the products or services. Each application, in turn, may involve as many as 60 different steps before a final evaluation is made and sent on to Homeland Security.

The challenge was to know the status of all applications under evaluation throughout its lifecycle at IDA in order to respond to internal and external enquiries.

"Before using Appian, everything was done on spreadsheets and paper," Crowley says. And it tied up specialists whose sole job was to track the documents throughout the lifecycle.

Crowley says the Appian system formalised a series of tasks or processes. He created a prototype to model the current processes, which was used to discover why applications were so hard to track. Then, as they used Appian, processes were modified.

"We took out steps in the process that were there simply to tell us it was there," Crowley says.

While the system is in its initial stages and there have been improvements, Crowley judged the results "mixed".

One of IDA's goals was to be able to adjust processes frequently as needs arose, and to change or retrograde applications that were already under review. The current system does not do that easily because its business processes are complex, long-running, and hard to modify.

"We are looking for the next version of the product, which will allow us to break the model into small subsections so we can go back and change the processes under way," Crowley says.

The product has allowed IDA to use fewer people to track where things are, and applications are not held up for lack of knowing where they are.

"Now, the process is documented. When questions come up about why it is taking so long, there is a basis to figure out how we can make changes and where," Crowley says.

Peter Davidson contributed to this article