Almost all large organisations have many applications which were developed based on different data models and data definitions, yet they all need to share data. So the basic idea of a canonical data model is “let’s use a common language when exchanging information between systems.” So, if system A wants to send data to system B, it translates the data into an agreed-upon standard syntax (canonical format) without regard to the data structures, syntax or protocol of system B. When B receives the data, it translates the canonical format into its internal format and everything is good.
The benefit of this approach is that system A and B are now decoupled; if A needs to be upgraded, enhanced or replaced, as long as it continues to reformat the data for external systems into canonical form, then B or any other system is not impacted. Simple and elegant! Under this approach, organisations with hundreds of application systems can now happily upgrade and enhance individual systems without the complexity (and cost/risk) of coordinating the analysis, design and testing with all the other systems.
However, there is a catch. While A and B are no longer coupled to each other, they are now coupled to the canonical physical format. So now if the canonical model changes, every single system that uses it to send or receive information is potentially impacted.The results endless analysis and discussions among business analyst, architects and designers of any proposed change to the canonical model.
The complexity of data Governance is often avoided by creating "quick and dirty" service implementations, which focus only on the requirements at hand so as to speed up implementation. Over time, these services create increasingly reductant services and restricts the flexibility and extensibility of the overall SOA.
One symptom of this approach is revealed by the inspection of the data structures being exposed through service messages. If there are many services exposing arbitrary variations of the same business information, or many instances of data mapping running in the enterprise service bus (ESB) and business processes, then it is likely that a simpler and more reusable solution could have been developed. Left unchecked, this approach can lead to a solution so complex that all the benefits of the SOA approach are lost.
A good place to look for possible candidates for the CDM is the Information Structure Viewpoint and Application co-operation viewpoint in ArchiMate model.
A structure like this would indicate possibility of a redundant information in both the customer model.
A target Information model for this could be to have a specialised representation of customer as shown. However it is not evident from this model that customer object is a part of the Canonical data model. We can use group to explicitly state this fact as shown in the next model.
The customer object is now a part of a group is represents a set of canonical data objects
Note that canonical data model is often achieved though Enterprise service bus patterns. We do not model the ESB patterns in the above diagram. This model merely points to the presence of a CDM and not how its implemented.
No comments:
Post a Comment