Attend any SOA conference or read any SOA article, and you can be forgiven for thinking that 'the technology's a cinch, but redrawing business processes are a bear.'
Eric Knorr and Galen Gruman beg to differ somewhat with this widely held view. True, the technology is ready and available to perform all kinds of magic for the SOA,from routing transactions between partner systems to providing analytics on system events. But, the challenge is being able to sift through an array of often bewildering choices to determine the best technology fit for a budding SOA. Writing in CRM Daily, Knorr and Gruman sum up the challenge this way: "Technologists must make key decisions about the platforms on which to build services, as well as how those services will be exposed, managed, and mediated. Some companies may opt for an ESB (enterprise service bus) to connect services, whereas others may focus on standards-based services designed for maximum reuse."
To ESB or not to ESB: Enterprise service buses are another, sometimes vexing, technology choice that needs to be made. For example, the article states, payroll processing giant ADP went years without an ESB, but recently adopted a distributed ESB because "it's difficult to maintain a bunch of one-to-one messaging," according to Bob Bongiorno, ADP's CIO of employer services. The company's number of services grew from nine to more than 30, but along the way, "the management complexity has far more than tripled," he says.
However, the article also quotes Anne Thomas Manes of the Burton Group, who equated ESBs to warmed-over EAI: "EAI is fundamentally different than SOA," she said. "EAI is about bridging business process silos; SOA is about breaking them down." However, Manes disagrees that an ESB should be a gateway to all services, and that there are other alternatives to ESB for managing point-to-point services, such as XML appliances.
Governance and incentives (or disincentives): The technology underpinning SOA needs to have ironclad governance behind it, the article notes. For example, the authors describe how BT (formerly British Telecom) has developed 14 service platforms, each with its its own sets of services, and each with its own architect. The architect's job is to "ensure that all services -- whether developed in-house, provided by a partner, or bought from a vendor -- adhere to the architecture." And there's an enforcement stick to go with it -- "if a BT project doesn't meet the architecture, the development team loses a quarter of its annual bonus. To enforce that compliance, if a BT project doesn't meet the architecture, the development team loses a quarter of its annual bonus."
The topic of incentives versus disincentives is an interesting one that we'll hear more of as enterprises figure out how to promote SOA adoption. Last month, for example, I described AT&T's carrot and stick approach, in which development teams were informed in a memo from a high-level VP that their jobs would be in jeopardy if they did not adhere to standards when rolling out new apps. It isharsh, and AT&T VP Rich Erickson admitted that punitive measures probably wouldn't have gone that far, but it did put standards foremost in everyone's minds.
Leave a comment