Where does the process-managed enterprise meet the service-oriented architecture?

	express delivery
	• print  • comment
	Service-oriented architectures can help BPM projects realize the dream of continuous process improvement, say vendors: BPM is an early adopter market with many false starts behind it SOA brings a new level of flexible modularity Processes need to be defined and configured carefully Mapping processes can be hard work SOA gives more flexibility to handle exceptions
	Glossary terms: business process, SOA, BPM, BPEL, granularity, lookup tool Sponsored links: your text link here

In the past, business process initiatives have often stalled on technology grounds. Now that SOA is gaining increasing acceptance, business process management (BPM) software seems to have a bright future ahead of it. With standards emerging for SOA design and deployment, and established vendors preparing the technology backbone, the foundations are being laid for BPM.

That's not to say moving to a process view is simple. For a start, any attempt by software vendors, consultants and even companies themselves internally to map standard processes are usually met with such antipathy by the corporate world as to render them almost useless. Some managers remain wary of any process automation initiatives, recalling the upheaval caused in the 1980s by Michael Hammer's process reengineering gospel, while others take the same position as Nicholas Carr's 2004 article, Does IT matter? (the response from business process gurus Howard Smith and Peter Fingar was IT Doesn't Matter — Business Processes Do.)

Whatever your point of view, it's indisputable that the IT to support business processes remains underdeveloped. Although a host of business process management systems are now available — and mainstream vendors like Microsoft, Oracle and BEA are moving up the stack and have built some elements of BPM into their core offerings — the vision of "roundtrip BPM", as defined by industry analyst firm Gartner, remains a distant dream.

Early adopters

"It's still very much an early adopter market," says Jeremy Payne, VP sales EMEA of Cambridge, MA-based BPMS and business rules engine vendor Pegasystems. "An awful lot of people make claims to be in the BPM market but if you look at Gartner's definition, very quickly people who have a BPM marketing veneer fall out of the picture."

According to Gartner, roundtrip BPM covers three stages: the initial modeling of the business process; its deployment into the overall architecture — including both machine-to-machine and human processes; and finally analytics feeding back to the process owner. Many process management initiatives fail to get off the drawing board once systems architects recognize the scale of integration work to bring the different elements of functionality into play. The processes have to run over the existing IT infrastructure, which means building hooks to implement the process deployment and then monitor performance in order to provide feedback for analysis. This adds a new layer of process-driven integration on top of any existing application integration that may be in place, potentially adding extra cost, complexity and inflexibility. And yet inflexibility is anathema to the round-trip model, which implies a philosophy of ongoing process improvement (further 'round trips') as a result of the analysis performed in stage three. Several BPM vendors don't help their cause by relying on third party add-ons to cover the full range of integrated functionality, making seamless operation even harder to achieve.

The move to service oriented architectures (SOAs) could change all that, allowing vendors for the first time to define overarching architectures to support modular, pluggable service-oriented components, each infinitely configurable to match an organization's business processes and strategy. The key is to work out how to map the two together.

Creating services

Although earlier generations of technology have offered component-based approaches, their ability to support BPM has been limited by the difficulty of applying the componentization to business processes. Jeremy Wood, CEO of 42 Objects, a London-based financial services specialist, says: "Corba in the 90s was reusable and componentized at the bits and bytes level. BPM [today] is a way of being able to deliver business level components, incorporated into a framework."

For services in an SOA to be applicable to the business, they need to be broken down to the right level of granularity — not so coarse grained as modules in an application but not as fine grained as was typical with CORBA and other object-oriented systems. In Smith and Fingar's first book together, Business Process Management: The Third Wave, the authors expounded on the idea that all the elements of a business could be thought of as processes — whether applications, services or indeed the aggregate of the processes themselves. While perhaps having a firmer grounding in a business philosophy than in practical IT, the Smith-Fingar perspective does allow a glimpse of an approach to the problem.

Increasingly, BPM vendors themselves take a service-oriented approach to architecture, although this can take different forms and won't necessarily plug directly into an existing enterprise SOA. Savvion, for example, includes a UDDI directory in its offering, so business processes can be registered as services in the directory, whereas Pegasystems provides a layered set of services focused around a repository of business rules, which define the policies for how the services operate. John Everhard, technical director of Pegasystems, says: "We use the rules engine to abstract away from technical Java code. We have rules for everything and every rule is highly parameterized for a particular moment in time." Pega's BPM Process Commander sits above the rules engine and calls the rules and services in real-time to establish how to combine functionality.

Everhard believe this adds a level of abstraction above SOA: "Even with traditional SOA, you are calling pre-written components that have fixed structures. They may be granular at a business level, but they are procedurally coded. Our ethos is to take the intelligence out of the applications and capture it in the rules engine."

Mapping the process

Mapping out business processes, the first step in the journey, can be an impossibly complex affair. Complex processes are easier to map if they are already well-defined and relatively mature: it's building in the capability for change and improvement that is the greatest challenge. webMethods' Olivier Barbe, marketing director of webMethods, gives the finance sector example of account opening, order processing and order confirmation, distinct processes which nevertheless can involve a huge number of counterparties. In a major deal with a large investment bank earlier in the year, webMethods mapped the company's whole process, including the different systems and human participants, and using BPM and workflow automated the STP (straight-through processing) cycle from customer contact to order confirmation.

In other cases, BPM initiatives are applied to more specific processes — such as a parts configuration process or a customer service offering. Standards allow process maps to be shared and reused later when these individual processes need to extend elsewhere in the organization. The Business Process Management Institute (BPMi.org)'s recent merging of its business — and its popular BPMN notation standard — with the Object Management Group (OMG)'s efforts in the area, along with increasing acceptance of OASIS' BPEL execution standard, suggest that users are converging on a common set of standards.

Everhard says: "We are starting to see people take BPEL on board. There was some confusion because initially it was just a language for description of processes you could call as web services. It's now expanding so you will be able to port processes from one application environment to another." He sees a day when Oracle, IBM, BEA and the rest provide advanced BPEL engines that can consume these standard process definitions which Pega and others will supply.

SOA development

The next challenge is to develop an SOA which can meet the needs of that particular process, not just within the enterprise but across the entire value chain. In some organizations, that issue has already been addressed — because the architecture already exists on which to build. In the banking sector at least, many institutions have made their big architecture decisions. 42 Objects is a founder member of BEA's Components Club, an initiative in the finance sector to provide common services which can be pulled into the BEA development and application server environment. Before its founding, the company conducted research among 25 different banks in the City of London, looking at areas of overlap.

42 Objects' Wood says: "Technology standards have matured enough that banks have had the confidence to put together technology frameworks, and architecture offices have been set up over the past few years. Now there's an opportunity based on the new technology standards to base application components on top of the framework and give the banks a head start in decomposing their legacy. We're using this approach to provide fine-grained business services to plug a lot of the gaps [in their systems]."

Initially focusing on funding issues and the netting and aggregation of trades for margin calculations, Wood says there are different areas where this can be extended. "It's great for us as a software vendor. Now we can deploy very quickly in an integrated environment. The SOA approach lends itself well to [creating business opportunities for] start-up organizations."

Addressing exceptions

A final area of concern that SOA helps address is exception processing. Even where BPM approaches have thrived — such as in straight-through processing initiatives in the finance sector — it's the point at which the process breaks — whether because a manual process has to be invoked or because a threshold is breached — which raises most concerns.

"If you take all the process breaks that occur in a traditional workflow system they are when an individual is involved," says Pegasystems' Payne. By automating processes in a rules-based BPMS with a services infrastructure, the system can make decisions about what actions to take when a break occurs or when an expected human response isn't forthcoming — perhaps substituting a different service for one that has failed, or calling a further service which can investigate the problem.

So far the impact of BPM on businesses has been limited — process improvement projects nibble away at the edges, while the quality standards world of Six Sigma initiatives still focuses mainly on engineering and manufacturing processes in isolation. Despite all the talk of best practice centers, reference architectures and evaluation suites, the mainstream business of selling and supplying goods and services largely remains untouched by BPM. Marrying BPM to SOA is set to unleash a new wave of process management and automation into those areas.

More on this topic