Semantic SOA

We believe that the key to making a Service Oriented Architecture live up to its promise of flexibility through loose coupling is to address the semantic issues.

Gartner has a maturity model for SOA that essentially runs from local (within an application) through to inter-application and eventually shared services mediated over a bus under proper governance control. Our observation is that many firms are sort of stuck at the second level, where they have most of the infrastructure in place, but most messaging is: a) request/reply and b) using a schema that is a negotiated agreement between the requestor and the responder.

We recognize why people do this: it is expedient, and requires only very localized agreement on what things mean. But someone eventually gets frustrated when it becomes clear that the promises of SOA (loose coupling, shared services, plug and play computing, fail safe applications, and the like) are being only marginally achieved.

When you get to that point, take a deep breath, relax, and think about what is really going on: lack of agreement. What you need is a basis for agreement. This is hard, but not impossible, and the broader the agreement, the more powerful the outcome.

You might come to this juncture and decide that the answer is to get all your applications on a shared database (the ERP promise). If your organization is small enough, you might succeed at this. (Our observation, borne out by the book “Growing Pains,” is that the cutoff point is somewhere between 500 and 1,000 employees.) Above that we have seen very few companies that have successfully gotten more than half their enterprise data on a single shared schema.

You might decide to lock all your warring factions (aka, application owners) in a room until they agree on what all the parts of their schema mean. You might try this, but our observation is that it yields very little positive result and a lot of irritation.

You might decide that you can adopt your industry’s “standard model” (HL7 for health care, ACCORD for insurance, NIEM for Justice, etc.), but with this approach we think you’ll discover two frustrating things: these industry standards are far too imprecise and ambiguous, and they cover too small a percentage of your internal footprint to do you much good.

You might decide that what you need is a “canonical model” (a model of the shared data that needs to be shipped back and forth between applications). We would agree; in general, you will make a great deal of progress with a canonical model. Our suggestion would be to rethink its origin. If you step back (or up a level, if you are a Zachman Framework follower) you will find yourself building a Semantic Model, or an Ontology, that represents the key concepts in your enterprise. A canonical model can be directly derived from such a model (we’ve done this and have the tooling if you’re interested). This has two major advantages: these models, due to the richer modeling constructs available, are typically more elegant and more rigorous at the same time. Additionally, an Enterprise Ontology is then available as a permanent asset that can be used in several other facets of your architecture: you can drive your unstructured data integration from this, your web-based data harvesting, the controlled vocabulary for your rules initiatives, and no doubt several more we haven’t thought of yet.

This approach is part of what we call “enterprise message modeling.”

We also see this as the starting point for a much more ambitious rethinking of enterprise architectures: migration from static XML/WSDL definitions to flexible XML/RDF definition of messages and information flow. If you believe the future of system integration rests on more formal semantics (or even if you’re just interested enough to pursue this further), give us a call or email.