A service-oriented architecture (SOA) is a useful vehicle for business process management (BPM), but getting your enterprise to successively adopt the two practices will not happen overnight. An incremental approach, small bites—if you will—has benefits over a big-bang approach, some viewers say. This was among the themes in a presentation about avoiding "fail-mode" in BPM and SOA implementation given at a recent SearchSOA.com virtual trade show.
"The agile incremental approach is to find some customers for a service, implement it, support their business process and their business needs and then, over time, enhance [the service]," said Mike Rosen, chief scientist at The Wilton Group and independent SOA consultant. "If you provide value with that service, more business processes will want to use it."
While the goal over time can be to get an entire enterprise involved in a SOA-backed BPM, this is a rather large conceptual shift for an organization. It can require that certain hardware, methods and human resources be replaced.
So it is best to start with a small project that will provide value to the business, but not break the bank if it fails. From there, architects can take the lessons they learned and start building outward.
When incorporating BPM, it is helpful for an organization to already have a pretty solid handle on its Web services. Rosen said business processes can potentially need to access information from a variety of disparate areas in a company and web services facilitate that best – so long as they are well organized.
"What we've seen from experience is that this approach, where we tightly couple our business processes to the existing system, doesn't scale," Rosen said. "We want to insulate the business processes from the underlying legacy systems."
For example, an organization would want any business process that needs to access policies to do so through the policies service. This service would contain all the rules associated with the location and access of policies.
In such a way, a SOA-BPM system should be layered, said Rosen, each layer with its own interface. The business process layer defines business processes and breaks them into activities. A separate layer contains the services that facilitate those activities. Another layer would handle integration, and so on.
"Often when we look at business processes and SOA we ignore the information aspect and focus on the technology aspect," said Rosen. "What's important is that you have some vision of sets of services that you need now and then over time to meet your business requirements."