Business process management the key to SOA success

Changing your business processes to define the role of SOA works much better than building SOA for its own sake.

Companies are missing the boat on SOA success if they're spending millions of dollars on a service-oriented architecture only to use it for application integration alone, analysts and practitioners say. Rather, today's SOA success stories are in wider-reaching business process management (BPM) initiatives where, in some cases, even IT becomes organized along business process lines.

Anne Thomas Manes, an analyst at Burton Group, speaks with enterprises that have spent $US3 million to $US 4 million a year on SOA projects -- in some cases, $US 10 to $US 15 million in the past five years.

"All this money is going into ESBs [enterprise service buses] and Web services, and they get a dozen or two integration projects going, but are they getting any business value out of that? I don't see it," said Thomas Manes, who wrote a controversial SOA blog post titled "SOA is Dead; Long Live Services." "I don't think a bunch of integration projects are worth $20 million."

A common misperception is that service-oriented architecture is a product or even a one-off project, when in actuality it's not even a technology. Rather, a SOA implementation is an approach to IT and business transformation, and so must involve the business side and business process redesign -- even though these initiatives, too, can face significant hurdles.


Mike Kavis was chief enterprise architect at Catalina Marketing, when the company decided to redevelop the 20-year-old business processes it used to produce printable coupons for retail customers.

The 10- to 12-step process spanned many business units and sometimes took 12 weeks, far too long for customers who needed their coupons within days or a week. "The customers said they loved the product, but it just took too long. That was the business pain point we set out to resolve, and SOA happened to be the way we ended up approaching it," Kavis said.

On the back end, the system used to manage coupon development was proprietary, with six months of new-hire training required. "There was a lot of application silos and redundant data entry points, so we were dealing with quality issues," said Kavis, who is now CTO of Web services consulting startup M-Dot, as well as an independent consultant and SOA blogger.

But when a consulting firm was brought in to help evaluate business processes and systems, and ultimately retrain application developers to implement a SOA architecture, the IT department didn't exactly embrace the idea. The application developers, for instance, learned that they would no longer work in silos attached to particular applications but would have to learn how to develop services using connectors from the programming languages they already knew, such as Visual Basic and C++, to Java. Java would became the standard programming language for the front end of the new business processes developed for the store coupon system.

"It was a battle because IT thought they were going to be outsourced. They didn't see what was in it for them and didn't know what the big picture was for the business," Kavis said. He ended up bringing in employees from human resources, finance and operations, as well as C-level feedback, to create a center of excellence.

The business side took some convincing as well. "Once the consultants showed them that we had a lot of business process redundancies [something IT already knew] and we could cut those out and cut the cost of producing a store coupon by 50%, the business started to own SOA," he said.

SOA and business process transformation

A SOA project at a telecommunications company also resulted in an IT reorganization, according to Burton Group's Thomas Manes. A new CIO regrouped the staff to reflect business processes rather than business units, with IT groups dedicated to business functions such as billing, provisioning and customer acquisition rather than business units such as residential or mobile.

This effort was in fact part of a complete IT and business process transformation. The SOA portion, including the staff reorganization, has allowed IT to develop generic, reusable services that are fine-tuned to fit a business unit's request, versus building a new service from scratch every time a business unit wants to launch a new product, Thomas Manes said.

The CIO also required that developers' code pass muster with an architectural planning board and meet SOA coding principles to ensure business processes would truly integrate and be reusable.

The need for SOA governance

The telco's approach to governance is right up Todd Biske's alley. Biske has been an enterprise architect at A.G. Edwards, a SOA consultant for Momentum Software Inc. and is now a senior enterprise architect at $US 11 billion chemical company Monsanto. He said he believes service ownership through governance is a key to SOA success.

"Someone needs to take on that role of actually owning the service, making changes to it based on new business interest in it or how it's actually being used by consumers," Biske said.

If, for example, a service has three operations that customers call on in a given sequence, then the service owner should ask whether that service can be a single operation. Or if customers tend to use two separate services in tandem, the services could be combined.

"Someone needs to be looking for these patterns. Otherwise, you're never going to get the benefit of consolidating services and making it easier for applications to use combinations of services," he said.

Read more on Service-oriented architecture (SOA)