Authoring Master Data consists in creating and modifying the content of the master data entities. Most people consider two scenarios for authoring master data. This simplified vision is tied to the traditional MDM hub styles that I have described in a previous post.
- Scenario #1: Authoring takes place in the operational applications. This scenario corresponds to the Registry, Consolidation and Co-Existence hub styles.
- Scenario #2: Authoring takes place exclusively in the hub. This scenario corresponds to the Centralized/Transactional hub style.
Seeing the world purely through the lens of the traditional hub styles leads to this dreadful reduction of possibilities, and obliviates some of the real-life use cases. In this post, we will discover interesting cases for authoring master data and illustrate them.
Scenario #1: Authoring in the Operational Applications
The first scenario is the best for ensuring non-disruptive operations. In fact, nothing changes for end-users. Operational applications publish - via a data integration layer - their master data in a convergence hub. The convergence hub transforms this Master data into Golden data.
This scenario applies when the operational applications host all the required entities and attributes needed in the golden data.
- Wait! What happens when there is no official operational application for authoring certain master data?
In this case, fallback solutions sprout in the form of Excel spreadsheets, Access databases, text files, etc.
Scenario #2: Authoring in the Hub
Everyone (including myself) loves their spreadsheets, and they work fine... until you need multi-user access, concurrent changes, data quality/de-duplication, version history and approval workflows. When editing critical master data such as cost centers or employees, you need all the aforementioned capabilities. In this case, spreadsheets are not a long-term solution.
In this second scenario, your replace the spreadsheets by the MDM platform. The MDM platform provides for accessing and authoring master data. It supports collaborative workflows for authoring, enforces data governance policies (for quality, access, security, etc) as well as versioning. The hub handles possible duplicates, and generates golden data from the authored master data.
- Not yet! What happens when some pieces of the master data already exists in the operation applications and must be authored there?
This is where it gets interesting !
Scenario #3: Vertical Partitioning / Additional Fields in the Hub
Operational applications (CRM, ERP, SCM) contain information relevant for operational usage, but not necessarily all the master data required today (or tomorrow) by the business.
In this scenario, end-users keep on authoring data within the operational applications, and other users may complete this data in the MDM hub.
Collecting master data from a Product Lifecycle Management platform, and enriching it with additional information within the hub is a use case. Extending Employee information from the HR application with the Twitter, LinkedIn, Google+, <YourSocialNetworkGoesHere> accounts is another one.
Here, the golden record is a vertical consolidation of operational data and of data authored in the MDM hub.
- Hold on! What if I want to separate operational records from authored records?
This is the next scenario.
Scenario #4: Horizontal Partitioning / Additional Records in the Hub
In this scenario, the MDM hub is treated as an application that delivers records in a range separated from the operational applications' records. Records authored in the hub appear as added to those coming from the operational level.
For example, for managing a generic Party entity, we may retrieve Customer Parties from the CRM application and author Suppliers Parties exclusively in the hub. Customer Parties and Supplier Parties belong both to the same Party entity, but in two different ranges.
- This is nice, but all use cases cannot be reduced to vertical or horizontal partitions! Sometimes I need to change something "in the middle".
Indeed! This is my last scenario.
Scenario #5: Data Enrichment in the Hub
This scenario is the most complex one, as there is no predefined segmentation. Data authored in the hub simply merges with the information delivered by the operational layer. Both the operational applications and MDM hub contribute to the golden data. This approach can be used to override, enrich, fix or complete operational data through authoring processes managed in the hub.
In this scenario, a customer golden record can be aggregated from CRM data, from the Website Registrations and from data authored in the hub. Consolidation rules designed in the master data logical model define the strategy for merging all this information.
For example, consolidation rules may define that:
- the Email comes from the website,
- the Phone comes from the CRM system,
- the Shipping Address comes from the Order Management system,
- the Name will be the most frequent one in all these systems,
- Any data authored in the hub by a data steward has precedence over all the other systems' data.
The matching/consolidation mechanism implemented in the hub guarantee a smooth collaboration between operational systems and authoring workflows running in the hub to create the best of breed master data.
What is Your Scenario?
A single scenario usually does not apply to all the entities in a Master Data Hub. Scenario is not dictated by the hub structure or style, but derive from the business requirements for every entity or group of entities. For example:
- "Authoring in the Hub" for Cost Centers
- "Horizontal Partitioning" for Customers and Suppliers Parties
- "Vertical Partitioning" for Employee Data
- "Data Enrichment" for Product Data
Semarchy Convergence 1.3 was specifically designed to support all these authoring scenarios, and provides a unique framework combining them in a multi-domain MDM implementation. The Semarchy Convergence Evolutionary MDM platform embraces your business cases and helps you creating a simple, safe and fast MDM solution.