+1. As with the term "SOA", the term "canonical" should be accompanied by some context. Without context, both terms are ambiguous and assumptions about their implicit context can lead to confusion. E.g. SOA at the EA level. Application canonical message. Service canonical message.
Enterprise canonical models can be useful for helping to define consistent service canonicals--the service canonical doesn't use the complete enterprise canonical, but the definitions within are consistent. E.g. "Credit history" isn't used in all service messages, but when it is used, the definition matches that within the enterprise canonical definition. -Rob --- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > 2008/10/20 Kirstan Vandersluis <[EMAIL PROTECTED]>: > > --- In [email protected], Michael > > Poulin <m3poulin@> wrote: > >> > >> a single canonical viewacross an enterprise may exist but not used > > (this is what I think Steve meant) > >> - Michael > >> > >> > >> > >> ----- Original Message ---- > >> From: Steve Jones <jones.steveg@> > >> To: [email protected] > >> Sent: Saturday, October 18, 2008 3:04:11 PM > >> Subject: Re: [service-orientated-architecture] Re: van Hoof on EDA > > & SOA > >> > >> > >> Depends what you mean by canonical. IME a single canonical view > >> across an enterprise is pretty much IT suicide. > >> > >> Steve > >> > > > > An enterprise should have a common data dictionary, at a minimum > > defining the terms and structures shared across groups. But I'm > > really relating back to Paul's note that the message defines a > > structure using XML Schema, and that structure is "cannonical" in > > that any user of the service conforms to it in order to use the > > service. I would say this message structure should be part of the > > enterprise data dictionary and reused as appropriate. In this way, > > its use as a cannonical model could be broader than just as a > > message set. > > Now the first bit I agree with (service defining a specific interface > that people must use) the second (that interface should be > standardised at the enterprise level) I disagree with. > > Take "Customer", if I am sending an order to a customer I need to know > > 1) Name > 2) Address > 3) What I'm shipping > > So the "Shipping" Service needs to have just that, it doesn't need the > enterprise canonical form of customer that also includes > > Last contact > Buyer history > Credit History > Credit Rating > Mother's Maiden name > Pet name > Sales contact > Phone number > etc > etc > etc > > This is why I don't advise enterprise canonical models except to say > that "minimal canonical form" is a good idea. > > Steve
