News

SOA Fatigue: It’s the People and Processes, Stupid

• By Stephen Swoyer
• September 19, 2005

Large-scale service-enablement is a doomed enterprise for one important reason, some codejockeys argue: bureaucratic infighting.

It’s not that the technology vision espoused by SOA advocates and their fellow travelers isn’t viable—although most developers also question just how viable pervasive service-enablement actually is—but that the loosely coupled services infrastructure envisioned by most proponents will almost certainly be plagued by a very familiar array of people and process issues.

Call it turf wars revisited, or SOA petty fiefdom, of a sort.

“There is a 4-year old system in place at Wells Fargo that…interacts with multiple external credit-scoring companies to make granting decisions,” explains Jonathan House, an IT director with Amirsys, a medical technology company. Except that on the path to composite app bliss, reality got in the way. “Each of the organizations that we interacted with had their own proprietary software for accessing credit-score information. None were compatible with each other, and none were Web-services based,” explains House, a former programmer with Wells Fargo.

House makes this point to illustrate the implications of external turf wars: namely, that third-party credit-score providers have little or no incentive to accommodate the service-enablement agendas of companies such as Wells Fargo. “We built the ‘credit-score’ interface that the application used, along with four different implementations of that interface for each of the vendors we were working with. In two cases we asked the vendor to write the interface code for us, and offered to pay them to simplify our job, and in both cases we were turned down flat because they saw that the interface design made their service a commodity.”

Rob Park, a senior agile technologist with Eclipse Software Systems, knows all about turf-warring of the internal kind. In one of the few SOA initiatives he took part in, bureaucratic petty fiefdom was a substantial impediment to project agility and success. “In the SOA case I was in, we still were as SOAPy as I've seen, actually using WSDL,” he says. “And where I could see a central application registry being beneficial [because of WSDL], there was too much bureaucracy across groups to even get that started. Lastly, integration time…was always a nightmare to get up and running. Getting the status of all the apps, most having some interface update, and finding out where they all were just took time.”

Kareem Yusuf, director of SOA product management with IBM, acknowledges that turf-warring—between internal business units, competitors and other groups--can pose stumbling blocks to SOA success. At the same time, he argues, turf-warring need not be an SOA showstopper.

“Invariably humans tend to be involved at some step in this [business] process, be it as approvers, exception handling or as core initiators and actors in the actual process itself,” he concedes. One recipe, says Yusuf, is a strong top-down push for service-enablement. “If this is a mandate that originates at the top, that can really help to eliminate some [bureaucratic] inertia,” he comments.

On the software side, Yusuf cites Big Blue’s WebSphere Process Server, a complement to the WebSphere Enterprise Service Bus IBM announced last week. Process Server is designed to address this problem, says Yusuf, by helping integrate business processes that involve people, IT resources, and business partners. “[Process Server] is a tool that really provides the core [service] orchestration capability, so it helps you identify and manage the role that people have in a process, too.”