Friday, June 12, 2009

Single Canonical Form? Only Suicidal Dinosaurs need apply

Now I said a while ago that Single Canonical form wasn't for SOA well now I've been doing some SaaS projects and I've realised with traditional modesty that not only am I right, but that people who are still pushing it as an approach can be described as suicidal dinosaurs.

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: ,

5 comments:

Anonymous said...

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.

Josh McDonald said...

Agreed. What we need is better frameworks for transformations, more (semantic) metadata for those transformations to to work with, and more fault-tolerance.

Kelvin Meeks said...

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.

Saul Caganoff said...

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.

Colin Jack said...

"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.