X
Business

Three places where SOA needs more work

SOA -- so simple even a caveman can understand it... not.
Written by Joe McKendrick, Contributing Writer

In a GEICO Insurance commercial, a marketer gets the idea to present the company's product pricing as "so easy even a caveman can understand it." He ends up having to buy dinner (roast duck with mango salsa) for some very offended cavemen. 

Likewise, SOA often gets presented by vendors as so simple even a caveman can understand it. So easy even a caveman can understand it... notTrue, SOA does offer more simplicity to complicated integration scenarios. But SOA is a new way of thinking for many organizations, something beyond the reach of most products.

SOA still has some vexing issues that need to be thought through and addressed. In a new post, Brenda Michelson attempts to help unravel what she describes as "the hard part of SOA," citing three areas where more work is needed:

First, there's the matter of service definitions, Michelson says. "What’s missing—and desperately needed—is a publicly available, cohesive, services definition methodology..." Michelson encourages practitioners "to share their tips and challenges publicly, and join or create practitioner-led forums to advance real-world SOA."

The second challenge is the need for semantic understanding between technologists, business users, machines, and enterprises, Michelson continues. "With SOA, the need for semantic understanding becomes even more pronounced, because of the multitude of service interactions, and the self-describing nature of service-oriented languages for service descriptions, contracts, policies, and orchestrations. Semantics must be expressed in business terms."

Third, there's the need to establish a formal SOA program within the enterprise to get things moving. "Common activities include evangelizing SOA, setting and enforcing standards (technical, methods), selecting application infrastructure and tooling, building out common (system-oriented) services, finding and conducting pilot projects, and stewarding the service catalog." Michelson advises that SOA efforts be built incrementally.

Editorial standards