All Under One Banner

Much confusion prevails about the precise definition of a SOA and its implications for the organization, especially since use of technologies like as Web services, the initiation of reuse programs and the construction of loosely coupled systems are all part of the SOA, but are often undertaken without a larger-scale perspective.

Cutter Consortium's Web services strategies editor, Tom Welsh, expresses the resultant cynicism. He says SOAs have come encumbered with "a generous helping of salesmanship, washed down with appeals to businesspeople's well-known dislike of technical details and promises to deliver all the benefits of IT without the attendant chores and limitations". Welsh says this propaganda on behalf of SOA is calculated to win business for analysts, consultants and system integrators, and notes that once contracts have been signed and payments assured, these suppliers will no doubt be able to design and build distributed systems that meet expectations and discharge their contractual obligations.

"Should anyone be uncivil enough to challenge their claim to be building SOAs, the studied vagueness that pervades most discussions of SOA guarantees that just about any working distributed system can be classified as one," he says.

Welsh agrees the aspirations behind some of the SOA advocates' more extreme claims are perfectly valid, and endorses their aim of ensuring the people directly responsible for the day-to-day running of business activities are able to create and modify applications that would automate those activities. However, he says for now when a vendor claims to have successfully delivered a SOA application, we can expect to find that traditional methods have been used. A distributed systems architect - a programmer with lots of old-fashioned experience - will have assessed the requirements, resources and constraints, asked some shrewd questions about future expectations, and come to an informed decision about the best design. If it is a distributed system and it works, it will probably be possible to label it an example of SOA.

But Gartner's Wiggins disagrees, arguing that semantic agreement between vendors on such tools as transfer protocols and Web services makes integration much easier and helps assure definitional consistency. So too does the fact that those tools allow users to automate many tasks, and in some cases, to eliminate programming. The real issue, he implies, is the ability of the organization to change in order to take advantage of SOA.

"Today's systems that are based on SOA are designed around modelling, where you draw workflow and flowcharts, and that flowchart actually becomes code - becomes executable," Wiggins says. "And that's something the businesspeople can do, but it requires a change in mind-set, it requires a change in the system itself. So instead of the old systems where the business was forced to adapt its processes around whatever IT delivered, today's next generation systems and the early first generation of SOA-based systems are turning that on its head."

He says the effect is to turn the IT department into an enabler of process, but with the process itself being managed by the business.