Separation of concerns
The MAG’s procedures modeling rely on a separation of concerns between these four points of view:
1/ The core business modeling allows for building up a complete Common Information Model shared at the level of the whole company. This unified data model is expressed via a static view of information but also via dynamic views for describing business objects’ life-cycles. These life-cycles are not reliant on organizational issues like permissions management, approval processes, actors, etc. They are sustainable; their pre- and post-conditions protect the integrity of ref/master data at the level of the core business.

2/ 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 creation and modification among actors.

3/ The logical modeling is a intermediate data modeling stage between the upstream data 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 Enterprise Architecture concerns like loosely coupled for both operations and data. The loosely coupled at the level of ref/master 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).
 -(4) Service oriented architecture to add services associated with data for validating rules in pre- and post-conditions of data creations and modifications.

The logical data modeling prepares the software implementation that will rely on the MDM tool.

4/ The software implementation is limited to a translation of logical models into the MDM tool. If the 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 ref/master 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 ref/master data structure mustnít compel a redesign of elementary CRUD operations but only and automatically updating of these services. The MDM tool must be able to load the ref/master data model that comes from the Common Information Model and organizational models (uses cases and approval processes). This ref/master data model is established with help from a XML Schema format (rich data description), associated with UML and/or proprietary views within a data modeling UI.

The figure above, from MAG’s modeling procedures, highlights the 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 mustn't be authorized to change ref/master data values if those modifications are not possible because of business objects’ states. This concern is not treated at the organizational level. This is not an organizational issue; 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.

States managements applied to ref/master data
The figure below shows an organizational life-cycle (data approval process) relying on two business objects' life-cycles. These two business state machines ensure the core business data integrity.

Whatever organizational choices, modifications of business objects Product and Provider are authorized or not depending on pre- and post-conditions handled by every business state machine. The modification of ref/master data  attribute is depending of the current state (decision tables managed as ref/master data).

Thanks to this architecture, data approval processes may be changed without generating risks at the level of ref/master data integrity.

What are risks if states are not managed?
#1 - Risks of incoherence at the level of business objects
Example: The Product can’t pass from 'Closed' state to 'To be negotiated' state.
Negotiation conditions can’t be modified if the Product is positioned in the 'Closed' state.

#2 - Risks of incoherence at the level of approval processes
Example: 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 poject's life-cycle
The previous explanation about the separation of concerns applied to ref/master data is not reliant on the MDM approach but it is particular sensitive for improving 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 suggested in the MDM 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 ref/master data architecture. As explained in the procedures modeling, this data architecture relies on business objects domains and the list of business objects that constitute the information system at the enterprise level. These domains and business objects are sustainable. Depending on the IT context, it may be possible to drive a reengineering stage to take advantage from existing IT assets.
- Then, the ref/master data modeling may use an iterative cycle with intermediate user validations because these 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 and data governance features. Thanks to the automatic loading of data models, the MDM’s UI is generated and allows for an easy user validation procedure.

In this situation, the MDM tool is a very powerful solution to support data models validation. Most of the time, when validating data models, Business users and IT specialists are not in an easy position because models are often complex to understand. If the MDM tool is XML Schema oriented (rich data models) 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 UI
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 modeling which is 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’s UI can be seen in the figure. This 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 previously shown 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 ref/master data from Authors to Titles.

Tip: beyond the ref/master data domain, this 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 ref/master data models. From a UML data model and an XML Schema implementation, 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
This figure shows the various styles of logical data modeling needed for modeling ref/master data in a sustainable way.

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 only with nested data types:
- With only PK/FK  it would be impossible to automatically generate a user-friendly MDM’s User Interface because of too many data links.
- With only nested data types it would generate a russian-doll data model that would be complicated 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, these multi-valuated attributes are not authorized with the normal forms of relational approach. Nevertheless, in the context of the 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 from 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 these 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, these rules ensure the loosely coupled at the level of data models.

These 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 this 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. This 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 data 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 this example, a foreign key is used to link data because they are located in two different Data Categories (Contract and Catalog). Therefore, the logical data model of InfoContrat includes a foreign key attribute idPoductCatalog. The derivation rules suggested by the MAG’s procedures modeling forbid nested data types that span across several Data Categories. With help from this mechanism Data Categories are loosely coupled.

Example #3 – Use of a list of foreign keys

This 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 link 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 on the context of every enterprise.