SOA + BPO = Chaos

SOA and BPO (business process outsourcing) aren't a natural match, apparently. Some think the two together can even unleash the forces of chaos.

SOA and BPO (business process outsourcing) aren't a natural match, apparently. Some think the two together can even unleash the forces of chaos.

Writing in Information Week, Howard Baldwin describes a financial-services firm's risk management application that blew apart and failed to time and economic savings that were promised.  "What had once been one application was broken down into 15 XML-based services, some of which were outsourced because they encompassed noncritical information," he explains.

However, the developers failed to plan for the madness that ensued upon deployment. "Instead of one application logging data, there were 15 services that needed to be managed--and all were sending messages to the system-management application," he says. "That app would in turn notify the IT department of the errors it was logging. Not only did the risk-management application crash, but it took the system-management application down with it, both of them overwhelmed by the essentially 15-fold amount of data generated. The company eventually had to redesign the way messages were handled to ensure that the system-management application only logged the most critical ones."

Baldwin cites this case as he points to "the conundrum of combining a service-oriented architecture, in which loosely coupled business processes are transformed into discrete interfaces that can be easily plugged and unplugged as business conditions require, with the outsourcing of those business processes to third-party providers. The advantage is the disadvantage. You can break business processes down to their most granular, logical elements; focus your development efforts on where you can provide the most differentiation; and let someone else handle the overflow or the low-profit transactions. But you open yourself up to a management challenge the likes of which you've never seen."

Obviously, a great many unresolved issues remain as companies seek to outsource activities within an SOA framework. As Baldwin concludes, "At its core, building Web services to connect to an outsourcing partner is application development. Admittedly, it can be a bit more complicated, but the fundamentals are the same. You still need to sit down with the users to understand the business process. You still need a development team that understands the technical ins and outs of XML. As with all component-based code, you need to be able to catalog it so that you can not only reuse it, but the next developers can figure out whether such a piece of code already exists before they start to replicate it."