SOA & Metadata: Is Loose Coupling a Loose Cannon?

I was just reading Joe McKendrick's So much metadata, so little time post.  It reminded me of a conversation I had last week with some IT folks at a large insurance vendor.

While Joe is really addressing the SOA Registry/Repository gap, my customers are looking at things a little differently. You could use the same title, but their metadata issue is a bit different - it takes forever to find what they need (data locations, definitions) today and they are afraid SOA will make things worse.  Companies want the architectural and development efficiency SOA brings.  It's just that they know it will complicate the whole metadata problem.

Take this insurance company, for example.  Though often given a patronizing pat on the head by cutting edge technology vendors who will  get around to that AS/400 port "any day now," it's been my recent experience that insurance companies are at the forefront of SOA, perhaps just slightly behind their banking brethren.  That's likely because SOA solves two key insurance industry technology challenges - modernizing older systems and efficiently sharing information with external partners.

When these companies modernize their policy underwriting systems, putting in place an SOA repository may help development, and an SOA registry may help their services run smoothly and securely, but neither of these addresses the key problem of business metadata.  Questions such as What is a customer? A policy? Damages? Coverage? are not addressed.  In many cases, this was addressed in the metadata strategy, but only in the context of a database or reporting application.  When data becomes service enabled via a Data Service, all of this context is lost.  And if services start to multiply and get built on top of other services, the problem only gets bigger. 

Now, I'm sure anyone reading this with an insurance policy or bank account would prefer that their insurer or bank didn't lose context and got the details right.  So there needs to be some bridging between the SOA registry/repository and the metadata repository.  To my knowledge, no one is really doing this.  Even the WS-MetadataExchange is really technical metadata about a Web Service.

Dan Linstedt has been writing about this for some time now.  Check out his entry The Answer? MDM - MMDM - SOA and Registries.  Seems like there is room for even more convergence between SOA registry/repositories and metadata repositories. 

Interestingly, being XML-based, Web Services might have an edge on traditional metadata repositories in that they can leverage XML industry standards, such as ACORD in the insurance industry.  Many, many man years have been spent defining what various terms mean - exactly the kind of tedious and time consuming work a good metadata strategy requires.