There were some interesting points in this article. Canonical model and data definitions can indeed be a key enabler of effective interoperability. This notion predates SOA, EDA, et al.
Canonical definitions are hard to create. Adopting existing standards has challenges: "While often cumbersome and sometimes overly complex, the benefit is that they can be leveraged immediately." The complexity often inhibits the ability to leverage them immediately. In the cases where I've seen this attempted, efforts to adopt industry standard definitions were abandoned due to this complexity. Additionally, part of the reason for abandonment was also no enterprise-level buy-in/focus on the effort. Creating them incrementally also has challenges. I fully agree "There is no need to conduct a massive enterprise modeling project." Indeed, such an effort is likely doomed to failure. But an incremental approach has the added challenge of managing definition evolution and balancing tactical project needs with strategic efforts. "Just in time" definitions can be effective, but it can create a good deal of churn and rework. > In the modeling process, it is important to first identify > the core common business objects that are referenced in many > business activities. Specific business process information can then > be layered on by combined those common objects and introducing > context-specific attributes. This implies that the canonical model is simply a superset of all the participating components. IMO, this isn't sufficient. Once a particular object is identified, with all the attributes, the uber object should be split into useful sub-objects to be used by specific processes. Passing around an all-encompassing object is almost always counter-productive. I fully agree that common syntax and semantics is very important. Architects should not underestimate the level of effort required to achieve this. -Rob
