MAG Members: How to publish prebuilt reference data models compliant with the MAG's modelling procedures
Overview document regarding a prebuilt reference data model
Important note:
The document presented below is a table of content that proposes a way of publishing prebuilt data model compliant with the terms of the MAG's modeling procedures.
The purpose of this document is to present an overview of the prebuilt reference data model. Some excerpts of that data model can be presented. It is not mandatory to highlight the detail of that model but rather to explain the business scope in the MAG's terms so as to facilitate the understanding of your proposal.
The standard content presented here can be modified depending on needs of each company that proposes a prebuilt reference data model compliant with the MAG’s modelling procedures. However, the document must deal with all points that are identified in the standard content.
To be compliant with the MAG’s procedures modelling, the prebuilt reference data model must be based on the MAG’s principles and in particular:
- Enterprise data architecture based on domains of business objects.
- Data architecture based on the concept of Data Category that encourage loosely coupled.
- Description of business objects’ life-cycles without dependence on organizational issues.
- Specification of elementary operations (default MDM’s CRUD operations) and extended operations (added-value uses cases).
Standard content
1. General scope
Description of the business scope.
2. Relation with business data standards
If needed, connection with data standards like Fpml, H7, Accor, OAGi… are explained. In particular, if the prebuilt reference data model is based on those data standards or on the opposite if the pre-built model is parallel of those models.
3. Domain of business objects
Description of the business objects domains composing the data business models as defined in the MAG’s modelling procedures.
Each data business models is presented with a short definition and description of associations with other domains.
4. Main uses cases
List of the main uses cases that are possible with help from that pre-build reference data model. Those uses cases are not only basic CRUD operations but also extended operations as defined in the MAG’s modelling procedures.
5. Main data approval processes
List of the main data approval processes that are possible with help from that pre-build reference data model.
6. Deeper view in a business object domain
In order to allow the reader for evaluating the quality of the reference data modeling, this section presents a deeper view of the data structure in the scope restricted to one business object domain.
List of data categories encompassed in that business object domain.
Deeper view of at least one data category and presentation of one or two business objects’ life-cycles.
If you are interested in promoting your prebuilt reference data models in the MAG community then read that section. If you are interested in using prebuilt reference data model, please stay in contact with the MAG community because progressively prebuilt reference data models will be proposed. |
|
Sample of Prebuilt Data Models published by the MDM Alliance Group
Here below an excerpt of our prebuilt data models about the Party and Party Relationship management.
A specific Party (either Organization or Person) is registered once whatever its roles and relationships with other Parties. This is a vitally important point to avoid duplication of data, siloed databases and finally siloed MDM. As already said in other MAG's publications, the required data model for MDM implementation doesn't stem from a specific modeling approach dedicated to the MDM objective. The Asset and Party mechanism presented here is a core business pattern for setting up sustainable data architecture. This business pattern relies on a 'centred role approach' rather that a 'centred actor approach'.
From a physical point of view, even if transactional databases could keep duplications for existing IT reasons (several customer databases, isolated employee database...) the 'centred actor approach' would not be the right choice in the MDM field. Indeed, as the MDM relies on a new database dedicated to reference data, it is an opportunity to set up a unified and sustainable modeling immediately. With help from that database all reference data governance features will be available in a relevant way: feeding and querying data, permission management, approval processes, version management, etc. Obviously, if existing transactional systems are not able to run with this MDM database, it will be possible to push those reference data into existing databases without unnecessary interference.
To find out more about the MAG's prebuilt data models, please go to the download section. Many business concepts are already defined as Address, Contact, Skill, Position, Pay Term...
|
