If SaaS is anywhere in your future, and it will be unless you are a military secure establishment and even then it might me, then GIVE UP NOW on the idea that you can mandate data standards in applications and create a single great big view that represents everything. It isn't going to happen, you are now back in the wild old world of multiple different systems each with their own specific exchange formats and....
you have to cope with it
Moaning about it or trying to push back on it because it doesn't meet your "corporate data model" isn't going to get you very far, its liable to get you heading out the door in fact.
Single Canonical Form is for people who believe in the great big database in the sky theory of architecture, it didn't work for SOA but some people still tried to force it in. Now the love child of SOA and the Cloud is coming to destroy it completely. The only sensible policy is to look at an "active" MDM strategy and a brokerage approach to communication between systems ideally based around a federated data strategy that leaves information its its source systems but provides references between them.
The brokerage challenge and active MDM challenge will only grow as SaaS becomes more common. There is no ability to inflict, and I choose the word advisedly, your Single Canonical Form on SaaS providers so you have to actually take a sensible solution oriented approach to data consistency and visibility.
Single Canonical Form is a dinosaur like approach but it was one which some people still managed to get away with proposing as a way to create a career. Well SaaS is the meteorite heading towards their earth and the choice is evolve or die.
Technorati Tags: SOA, Service Architecture
5 comments:
I've never really bought into the single canonical data model either. However with many-to-many interactions having an independent format that all parties transform to produces fewer transformations. For 1-n, n-1 and 1-1 combinations it seems reasonable that the service provider would provide in its own format and any service consumers transform to the provider's format. Just like you would expect in the "real" world - you would not have everybody submit expenses using their own template form, but the expense claims dept provides their own form which becomes the standard. You then take your own expense details recorded in your own format and transpose them onto the standard form. Such a "needy" conversion model would seem reasonable in the service world too. Thus those that need the service do the conversion, or have it done on their behalf - the point being that the transformation is "owned" at the end that needs the service.
Agreed. What we need is better frameworks for transformations, more (semantic) metadata for those transformations to to work with, and more fault-tolerance.
Steve,
Great posting.
I've long held the belief that SOA needs to include the concept of translating between federated canonical models.
Canonical in the small makes sense.
The one-canonical-to-rule-them-all is nonsense.
Like a lot of things related to SOA, I think the idea of a canonical data model got blown out of proportion.
The idea of a canonical data model arises from the need to decouple service representation from the underlying implementation. You don't want underlying assumptions or physical schemas etc bubbling up to the service interface. Hence the need for an "independent" data representation.
On top of that you don't want a proliferation (combinatorial explosion) of data representations.
So in my view, an independent (canonical if you like) data representation is important. Minimising the number of data representations is desirable. But I agree, a "single" canonical representation is unrealistic.
"The only sensible policy is to look at an "active" MDM strategy and a brokerage approach to communication between systems ideally based around a federated data strategy that leaves information its its source systems but provides references between them."
Not exactly sure that you mean here.
Post a Comment