In part II of this series we discussed the Common Information Model. Because MDM is a business project we need to establish of a common set of models that can be referenced independent of the technical infrastructure or patterns we plan on using. The essential elements should include:
– Common Information Model
– Canonical Model
– Operating Model, and
– Reference Architecture (e.g. 4+1 views, viewpoints and perspectives).
We will now turn our attention to the second element, the Canonical Model.
The Canonical Model (business rules and format specification) describes how the extraction of business rules from the software portfolio are managed and shared among other applications. In addition to externalizing business rules locked in proprietary applications (for example ERP or CRM) we also use design patterns defined here to communicate between different data formats. Instead of writing translators between each and every format (with potential for a combinatorial explosion), use this in combination with the CIM to write a translator between each format and the canonical format using rules to guide the effort. See the Open Applications Group Integration Specification (OAGIS) as example of an integration architecture that is based on a canonical data model. Implicit (and emerging now as generally accepted practice) is the use of rules (rules engines like iLOG for example) to handle reference data that must be shared across systems beyond software packages in our portfolio. OAGIS uses XML as the common protocol for defining business messages and processes (scenarios) to enable business applications to communicate among one another in a standard manner. Not only the most complete set of XML business messages currently available (there are others several others, see the eXtensible Business Reporting Language (XBRL) for example), it also accommodates the specific industries by collaborating with vertical industry groups to add and extend additional requirements as needed. For another real working example in the Product Information Management (PIM) space see GS1 Global Data Synchronization Network and the standards that make this possible.
Nick Malik over at Inside Architecture has written an exceptional post about this. We may not agree on all aspects (mostly semantics) but I think he has summed up well what this set of models should address in the blueprint. His post addresses the essential elements a complete modeling effort would produce. These products would typically include:
Canonical Message Schema – describes how when passing messages from one application to another we pass a set of data between applications where both the sender and the receiver have a shared understanding of what the values are:
(a) data type,
(b) range of values, and
(c) semantic meaning.
Event Driven Perspective (Views) – a style of architecture characterized by a set of relatively independent actors who communicate events amongst themselves in order to achieve a coordinated goal. This can be done at the application level, the distributed system level, the enterprise level, and the inter-enterprise level (B2B and EDI). Although we disagree on where this effort belongs (see Part IV of this series on reference architecture development), the logical view will have its origins here.
Business Event Ontology
This ontology includes a list of business events, usually in a hierarchy, that represents the points in the overall business process where two or more objects (entities) need to communicate or share the same data values and intent (semantics). And this, as Nick states is “is not the same as a process step. An event may trigger a process step, but the event itself is strictly speaking simply a “notification of something that has occurred,” not the name of the process. Ontology development is a pretty exciting technology I have watched mature from simple lab exercises (toys really), to something far more useful. For more on this see Part II (The Common Information Model) or my post at Essential Analytics about the Protege ontology editor.
The last remaining modeling effort is the collection (identification and grouping) of the rules used to define the behavior of the elements we have already referred to. Typically buried in application code, (if you are not lucky enough to have a Business Rules engine <g>), this model describes the business rules, protocol, and default behavior expected when the model elements interact with each other (especially useful when exceptions occur or logical constraints are violated). Not a common artifact I find, wish more of us would take the time and effort to accomplish this task. For another real world reference see the GDSN Package Measurement Rules (issue 1.9.2) for the global definition of nominal measurement attributes of product packaging or the GDSN Validation Rules.
As I stated in Part II, this is hard challenging work. The key differentiator and difference between success and failure on your MDM journey will be taking the time to model the blueprint and sharing this work early and often with the business. We will be discussing the third (and most important element) of the MDM blueprint, the Operating model in part IV. I encourage you to participate and share your experience, we can all learn from each other.