Three places where SOA needs more work

Three places where SOA needs more work

Summary: SOA -- so simple even a caveman can understand it... not.


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.

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Wonderful

    Hi Joe, this is a wonderful article, you've hit the nail on the head.

    We tend to cluster these unsolved problems in terms of Governance. Perhaps it's an issue of when you have a hammer everything looks like a nail.

    But in particular, service definition and description is about metadata, and metadata is in the registry repository. We see things like choreography, process, access control, reuse profile, dependency profile, and even things that go far beyond this like policy definition as being part of the service description. This would include things like service levels, which help describe expected performance of systems.

    The interesting complexity of service description is that a service looks different to different observers. And it should. A service consumer view of the service should be dramatically different from a support organization.

    On the issue of semantics, this is a "somewhat less governance centric" issue, but the first level of interoperability are things like transformations, which are metadata. Beyond this are agreements and understandings of the nature of data elements, which go outside the system itself to integrate. Despite interfaces being "self describing", this problem goes much deeper than that.

    Finally the idea of an SOA Program lies at the core of SOA Governance. Evangelism, organization and human behavior is easily more than half of an SOA, and without organizational buy in, your SOA will have a hard time scaling up.

    Rolling all these items up into one convenient, if poorly defined package called governance is less useful that breaking it down and defining it as you have. That said, it's important to understand that there's a body of work on these problems and that folks are working to make all three things a bit more manegable...

  • Add one - SOA Testing

    Let's not forget SOA testing!!

    Testing should not be left to the last stage and should be inherent in every stage of rolling out SOA and integration initiatives. A commitment to SOA success is a commitment to SOA quality which means unit, regression, and end-to-end testing.

    If 3 components of an SOA test to 99% quality, the resulting total system quality can be as low as only 97%. SOA, in this example, is actually creating LOWER quality environments by mistake.

    In short, SOA granularity requires more and different types of testing to identify errors. Every message, interface, service, and business process must be tested and validated in order to generate the expected benefits.