The MAG's MDM modeling procedures at a glance

Need an overview of the MAG’s MDM procedures modeling before reading the complete guide?

That section presents the following topics:

• Separation of concerns: avoiding the mix of core business rules with organizational issues so as to ensure a sustainable MDM.
  
  
• States management applied to reference data: taking into account business objects' life-cycles to prevent risks of data integrity problems at the level of the MDM.
  
  
• MDM's project life-cycle: having a powerful MDM tool with the ability to automatically generate MDM's User Interface and governance functions from a direct XML Schema uploading is vitally important to conciliate a top-down life-cycle with an iterative life-cycle based on prototyping of data models and UI.
  
  
• Merging several types of logical data modeling: building up the MDM relying on relational, object and hierarchical oriented approaches and SOA (pre- and post-conditions for triggering validation rules) is vitally important to optimize the MDM and secure its delivery.
  
  
• Derivation rules from the semantic modeling to the logical modeling: building up the logical data model from the semantic modeling in order to ensure the loosely coupled at the level of data.

Separation of concerns

The MAG’s procedures modeling rely on a separation of concerns between those four points of view:

• The core business modeling allows for building up a complete Common Information Model shared at the level of enterprise. That common language is expressed via a static view of information but also via dynamic views for describing business objects’ life-cycles. Those life-cycles are not reliant on organizational issues like permissions, approval processes, actors, etc. They are sustainable; their pre- and post-conditions protect the integrity of reference data at the level of the core business.
  
  
• The organizational modeling relies on the Common Information Model and completes the system with organizational specifications. Based on a unique Common Information Model, it is possible to define several versions and variants of the organization, depending on needs. Whatever organizational needs, the core business modeling must be respected. The isolation between business objects’ life-cycles and organization is vitally important. Two types of uses cases are distinguished: extended uses cases own pre- and post-conditions that are reliant on business objects’ life-cycles. Conversely, elementary uses cases are not reliant on business objects’ states and therefore they can be modeled and implemented like simple CRUD operations. The third concept of organizational modeling is data approval process, that is to say the workflow for conducting data modification among actors.
  
  
• The logical modeling is a intermediate stage between the upstream modeling (core business and organizational modeling) and the software implementation in the MDM Tool. The logical modeling allows for representing a logical view of the system taking into account several urbanization concerns like loosely coupled for both operations and data. The loosely coupled at the level of reference data is a significant concern. The MAG’s procedures modeling provide the best practices to structure data models so as to decide how to use nested data types versus relational links with primary and foreign keys. One crucial point for modeling MDM is to understand that the logical data models must take benefit at the same time of (1) XML oriented approach (nested data type, facets of syntactic and simple semantic validation rules), (2) object oriented approach (multi valuated attributes, inheritance of data types and values), (3) relational oriented approach (integrity rules, primary and secondary keys, normal forms) and also (4) service oriented architecture (to add services associated with data for validating rules in pre- and post-conditions of modifications). The logical modeling prepares the software implementation that will rely on the MDM tool.
  
  
• The software implementation is limited to a translation of logical models into the MDM tool. If that tool is sufficiently generic and powerful, a simple parameterization will be sufficient. In particular, the MDM tool must be able to automatically generate User Interface needed for managing data, but also all added-value governance functions like the version management and data approval processes.

The more the reference data model will be rich, the more MDM governance functions will be automatically generated by the MDM tool. Obviously, that approach is true only if the MDM tool is sufficiently powerful. For example, a modification of reference data structure mustnít compel a redesign of elementary CRUD operations but only and automatically updating of those services. The MDM tool must be able to load the reference data model that comes from the Common Information Model and organizational models (uses cases and approval processes). That reference data model relies on a XML Schema format associated with an UML standardized view or a proprietary view via an IDE.

The figure above, from MAG’s modeling procedures, highlights the vitally important separation of concerns between the core business modeling and the organizational modeling. The uses cases and approval processes mustnít mix organization states with business states otherwise each organizational modifications will generate regression risks at the core business level. Whatever organizational choices, business objects’ life-cycles must be protected in order to avoid any data inconsistencies. The MDM solution mustn't be authorized to change reference data values if those modifications are not possible because of business objects’ states. That concern is not treated at the organizational level. This is not an organizational concern; this is a core business concern. Those two types of concerns mustnít be confused otherwise the MDM solution will rely on spaghetti codes and will be not sustainable.

Example of states management applied to reference data

The figure below shows an organizational life-cycle (approval process) relying on two business objects' life-cycles. Those two business state machines ensure the core business integrity. Whatever organizational choices, modifications of business objects Product and Provider are authorized or not with help from pre- and post-conditions handled by each business state machines. The modification of each reference data attribute is depending of the current state.

Thanks to this architecture, approval processes may be changed without generating risks at the level of reference data.

What are risks if states are not managed?

#1 - Risks of incoherence at the level of business objects
The Product can’t pass from 'Close' state to 'To be negotiated' state.
Negotiation conditions can’t be modified if the Product is positioned in the 'Close' state.

#2 - Risks of incoherence at the level of approval processes
The 'Business Unit approval' is not possible if the buying negotiation is not finished AND if the Product is not positioned in the 'To be evaluated' state.
The 'not standard corporate approval' is not possible if the 'BU approval' has not occurred AND if the Provider is already in the 'Not standard state'.

The MDM project's life-cycle

The previous explanation about the separation of concerns applied to the MDM project is not reliant on the MDM but it is particular sensitive for improving referential data quality. The other point to well understand is the difference between the separation of concerns and the MDM project life-cycle.

The figure below shows the MDM project’s life-cycle proposed in the MAG’s modeling procedures. In order to secure the MDM project, a top-down approach associated with an iterative cycle is used. The top-down stage allows for building up a first sustainable version of the reference data architecture. As explained in the MAG’s procedures modeling, that data architecture relies on business objects domains and the list of business objects that constitute the information system at the enterprise level. Those domains and business objects are sustainable. Depending on the IT context, it may be possible to drive a reengineering stage to take advantage of existing IT assets. Then, the reference data modeling may use an iterative cycle with intermediate user validations because those data models rely on the data architecture previously defined.

It is vitally important to have a flexible MDM tool that provides business users and IT specialists with the ability to automatically generate the MDM’s User Interface. Thanks to the automatic loading of data models, the MDM’s UI is generated and allows for an easy user validation procedure.

In this case, the MDM tool is a very powerful solution to support data validation. When validating data models, Business users and IT specialists are not in an easy position because models are often complex to understand. If your MDM tool is XML Schema oriented and able to automatically load data models so as to generate User Interface then you have a significant advantage to succeed the data models validation in a progressive and sustainable way, involving your users in a concrete approach relying on UI iterative prototyping.

Automatic generation of the MDM’s User Interface

The figure below shows an example of a very simple extract of a data model associated with its XML Schema implementation and the MDM’s User Interface automatically generated.The MDM tool used is EBX. Platform of Orchestra Networks.

The usual join table between Titles and Authors used in relational oriented approach is transformed in a direct association represented via a multi-valuated attribute. This is an object oriented approach more convenient for producing automatically the MDM’s User Interface (avoiding useless screens for join tables). Of course, the MDM tool must be sufficient powerful to ensure referential integrity constraints because the MDM is used not only for querying data but also for updating. The automatic generation of MDM’ UI can be seen in the figure. That generation is done via a direct XML Schema uploading.

The rendering of the ‘Author’ list depends on the number of occurrences in the referenced table (check box in our example, but could be a multi selection list box).

In the data model above, the association link is unidirectional from Titles to Authors. If needed, another association link in the other direction can be added (figure below).

In this example, the user interacts with reference data from Authors to Titles.

Tip: beyond the MDM field, that type of MDM tool, very agile for generating the User Interface, can be used for helping the validation of any data models, not limited to reference data models. From a UML data model and an XML Schema representation, the MDM tool uploads it and then automatically generates the user interface that will allow users to validate any models.

Merging several styles of logical data modeling

The next figure shows the various styles of logical data model needed for modeling reference data.

The relational style allows for setting up primary and foreign keys so as to ensure a loosely coupled at the level of data models. The associations between data can’t be done only with primary/foreign keys or with nested data types. In the first case it would be impossible to automatically generate a user-friendly MDM’s User Interface. In the second case, too many nested data types would generate a russian-doll data model that would be complex to maintain with many risks for ensuring referential integrity constraints.

The object style allows the designer to set up multi-valuated attributes either for multi-valuated keys (in order to avoid useless join tables) or nested data types. Obviously, those multi-valuated attributes are not authorized with the normal forms of relational approach. Nevertheless, but in the context of MDM project a relevant conciliation between object oriented and relational oriented approaches becomes possible.

Finally, the hierarchical style is also encompassed in the MDM style in order to take benefit of XML Schema advantages. Beyond usual nested data types of XML Schema, the ability to add some simple rules for validating data with help from XML Schema facets is very convenient. When those facets are too limited, for example for dynamic enumeration or rules that handle several attributes, it will be needed to declare services attached to data in pre- and post-condition of modification

Derivation rules from semantic modeling to logical modeling

The derivation rules from the semantic modeling to the logical modeling are vitally important. They ensure a clever conciliation between the various styles of logical data modeling required to build up a powerful MDM (see above). Amongst several added-values, those rules ensure the loosely coupled at the level of data models.

Those three simple examples are extracted from the appendix 1 of the MAG’s modeling procedures. All derivation rules are available in those procedures, about fifteen derivation rules.

Example #1 – Use of a nested data type

In that example, nested data types are used because data are located in a unique Data Category.

The concept of Data Category is well-defined in the MAG’s procedures modeling. A Data Category encompasses a set of classes that are semantically tightly coupled. That is a building block of data, self-defined, self-sufficient. The objective is to encourage the loosely coupled between Data Categories.

Note: the term Category comes from Grady Booch in UML (cluster of classes).

At the level of the logical modeling, the model shows a nested data type relying on InfoServiceLine, because InfoProductLine and InfoServiceLine are located in a unique Data Category.

Example #2 – Use of a foreign key attribute

In that example, a foreign key is used to connect data because they are located in two different Data Categories (Contract and Catalog). Therefore, the logical model of InfoContrat includes a foreign key attribute idPoductCatalog. The derivation rules proposed by the MAG’s procedures modeling forbid nested data types that span across several Data Categories. With help from that mechanism, Data Categories are loosely coupled.

Example #3 – Use of a list of foreign key

That last example shows two classes that are located in two different Data Categories. The association link is multi-valuated from ClassC to ClassD. In this case, a multi-valuated attribute is used in InfoClassC. This attribute encompasses the foreign keys that allow the system to connect InfoClassC to InfoClassD. In the figure, the primary key of InfoClassD (not represented here) is InfoRole2FK. The name of the complex data type that represents the key takes over the role name stemming from the semantic model.

Note: the naming rules depend of the context of each enterprise.