Mdm introduces the maturity of MDM

Maturity of primary data management (MDM)

According to the complexity of the implementation of primary data management, the master data management can be divided into five levels according to the view of Jill dyche and Evan levy, which reflects the primary data management (MDM) from the low to the high) different Maturity. Below we will briefly introduce these five layers:

Level 0: no master data management (MDM) is implemented)

In the case of level 0, there is no data sharing between each application of the enterprise, and no data definition element exists in the entire enterprise. For example, a company sells many products and processes the production and sales of these products by multiple independent systems. Each system processes product data and has its own list of independent products, product Data is not shared between systems. At level 0, each independent application is responsible for managing and maintaining its own key data (such as the product list and customer information), and each system does not share this information, the data is not connected.

Level 1: provides a list

Whether large or small, list management is a common method. Within the company, a logical or physical list is maintained manually. When heterogeneous systems and users need some data, they can obtain this list. Maintenance of this list, including data addition, deletion, update, and conflict handling, is handled by the staff of each department through a series of discussions and meetings. Business Rules are used to reflect the consistency of value. When business rules change or a similar situation occurs, such highly manual management processes are prone to errors. Because list management is manually managed, the quality of list maintenance depends on who participates in the change management process. If someone is absent, list maintenance will be affected.

The difference between MDM Level 1 and MDM level 0 is that although each department maintains its key data independently, it maintains a loose master data list through list management, provide the required data to other departments. In MDM Level 1, data change decisions and data change operations are determined by people. Therefore, only after a person completes the data change decision can the data be changed. In actual situations, although the data change process has strict regulations, due to the lack of centralized and rule-based data management, when the data volume is large, the cost of data maintenance will become very high, low efficiency. When the number of primary data, such as customer information and product catalog information is small, the list management method is feasible. However, when the product catalog or customer list grows explosively, the change process of list management will become difficult. Mdm Level 1 depends on human collaboration. If the product manager needs to update the product price list, contact the ERP system owner to send an email to her. Implementing a customer or product list within an enterprise is just like maintaining relationships between people in different departments. If a customer or product has a hierarchy or group, the list will be difficult to provide, and it is usually difficult to manage level 1 because it is too complex.

Level 2: equivalent access (through the interface, each system is directly interconnected with the master data host)

Compared with MDM Level 1, Mdm Level 2 introduces (automatic) management of primary data. The establishment of data standards defines the access and sharing of detailed data stored in the central repository, providing strict support for sharing and using data between systems. Central repository is usually called "master data host )". This knowledge base can be a database or an application system that supports data access and sharing online.

Creating, reading, updating, and deleting (crud) are typical programming terms for processing basic functions. Even in MDM, crud processing is a basic function. If your database only supports crud processing, it does not mean that you have implemented MDM. Mdm Level 2 introduces peer-based access, which means that one application can call another application to update or refresh the required data. When the crud processing rule definition is complete, Mdm Level 2 requires the customer or "equivalent" application to format the request (and data) so as to be consistent with the MDM knowledge base. The MDM Knowledge Base provides centralized data storage and supply (provisioning ). At this stage, rule management, data quality, and change management must be customized and built as additional functions within the enterprise.

For example, a database or a packaged application (such as a sales automation system) provides data access to external applications. When an external application (such as a call center application) needs to add a customer, the external application commits a transaction and requests the data owner to add a customer entry. The master data host adds data and notifies external applications. The crud processing method is much better than that of the paper office. It is session-based data management. In MDM Level 1, data changes are performed manually. In MDM Level 2, data changes are automatically completed-standard processes implemented by specific technologies allow multi-application systems to modify data. Mdm Level 2 supports the use and change of a single and shared data knowledge base for different applications. Mdm Level 2 requires each equivalent application to understand basic business rules for access to the master list and interaction with the master list. Therefore, each equivalent application must properly create, add, update, and delete data. Authorized applications have the responsibility to adhere to data management principles and constraints.

Level 3: centralized bus Processing

Compared with MDM Level 2, Mdm Level 3 breaks the organizational boundaries of independent applications, use data standards accepted by various systems to establish and maintain master data in a unified manner (data stored on the master data host of MDM Level 2 is stored separately by each system, ).

Centralized processing means building a universal, target-based platform for MDM. Most companies find that MDM is challenging their existing IT architecture: they have too many independent platforms to process primary data. Mdm Level 3 centrally accesses and controls data used across different applications and systems. This greatly reduces the complexity of application data access, greatly simplifies the management of data-oriented rules, and enables MDM to have more functions and features than a distributed environment. Data of business owners is facing the challenge of consistency. Data exists in different places, and the meaning of the data is different. The data rules vary with systems. Centralized MDM processing-using a public platform as a bus (hub)-describe a consensus and integrate theme domain data from multiple systems, this means that the use of centralized and standardized methods to convert heterogeneous operation data will be integrated no matter what it looks like in the source system. At MDM Level 3, the company manages the content of the topic domain in a centralized manner. This means that the application system, as a consumer or master data, has a consensus that data is the image of the topic data content, breaking the organizational boundaries of each independent application. Mdm Level 3 supports the existence of distributed primary reference data.

One of the core features of MDM is the only accepted method to ensure that all systems can accept data representation. This is somewhat similar to language translation. English is already known as a global language through the translation of other languages. At MDM Level 3, a company allows any two systems to share data and speak the other language. Mdm Level 3 also reduces the complexity of equivalent access. The "consumption" application no longer needs to support system positioning and operation logic. Any distributed details related to source system data will be centrally processed by the MDM bus. The Automatic Data Standard at MDM Level 3 means that the target data value is represented and precise master data value capturing is provided through the necessary steps. Consistent enterprise data views are supported for the first time since MDM level 3 in all classifications. Data quality rules are here for data cleansing and error correction.

Level 4: business rules and policy support

Once data is integrated from multiple data sources, the topic domain view goes beyond the individual application and is displayed as an enterprise view. You will get a single version of the facts. When a single version of the facts is available, the inevitable response from business directors and executives is often: "prove it ". Mdm Level 4 ensures that the primary data reflects a company's business rules and processes and confirms their correctness. Mdm Level 4 introduces primary data to support rules and performs integrity checks on the MDM bus and other external systems. Because most companies are relatively complex, the rules and policies that affect business data access and operations are also relatively complex. It is impractical to assume that any single system can include and manage various types of rules related to the primary reference data. Therefore, if an MDM bus really intends to provide data accuracy within the enterprise, the support for workflow and process integration is essential.

For example, in an HMO, multiple applications are required to support the care of a patient. A single access (visit) may include admission, room and bed allocation, monitoring equipment, testing, health check, and othersProgram. Once a patient is ready to leave the hospital, the discharge process must ensure that all activities and resources related to the patient are settled. The MDM technology is very effective in aggregating multiple application systems to ensure patient identification and correct processing. Although patient identification is important, Business Rule integration is equally important. The clinical system relies on a series of business processes and data rules to identify all significant patient details. This includes returning all room-based resources (monitoring equipment, beds, etc.) for a useful detailed list of all expenses incurred when a patient is discharged from hospital. Mdm ensures that when John Smith is discharged from the hospital, the correct room and equipment are placed in the john smith detail directory, rather than other John Smith (performing physical treatment on another floor ).

The MDM system must not only support rule-based integration, but also integrate external workflows. These rules may include interacting with the clinical system through the bus or waiting for approval from another system or person (who has the permission to make a change. With an MDM bus, rule definitions can be logical and dependent on inputs of other systems. Of course, data coordination and Audit means that other systems (or business processes) can be rolled back to ensure that data changes have undergone strict approval, this error can be detected and the transaction can be rolled back as needed. Mdm Level 4 provides support for rule and Policy scalability. It is important to support any business-oriented rule set in a flexible and sustainable way through the bus.

For example, if a store manager updates the price of a product, the bus system needs to be able to negotiate with a trusted system (such as the product management system) to make the rule take effect. Detailed rules will support changes to product prices in another system-the bus must be able to understand the permission systems or methods that can handle and approve changes. These rules may involve complexity or privacy restrictions and prohibit them from directly appearing on the bus. At MDM level 4, an enterprise can support a set of steps or tasks that must be followed before a special creation, read, update, or deletion task is permitted. Workflow automation is often used to support authorization for events or activities that occur on the bus. However, change management is far more than just a workflow: it can include logical processes and human-based decisions. The existence of change management supports dynamic businesses and changes. For example, before January 1, 911, anyone could carry goods on a domestic American airline. There is no other form of authentication or payment method specified. After 911, the Federal Aviation Association (FAA) guided the establishment of a more comprehensive provision to indicate whether a person is allowed to carry the goods. In this special example, it is unrealistic to require FAA to be deployed on each system for the shipper. Deploy a rule management system to centrally approve rules for all systems (including the MDM Bus), making it easier to implement (and more realistic ). Centralized data definition and standardization have been introduced in MDM Level 2, which is relatively simple compared with centralized rule management in MDM Level 4. The more complex the business flow, the more business flows, the more bus requirements, so as to better support cross-functional and heterogeneous rules for common data. It is important that MDM Level 4 supports centralized rule management, but the rules themselves and related processing can be separated. In other words, the MDM bus must ensure that the rules are centrally applied even if they reside outside the bus.

Level 5: enterprise data concentration

At MDM level 5, bus and related master data are integrated into independent applications. There is no obvious separation between primary data and application data. They are integrated. When the primary data record details are modified, the related data elements of all applications are updated. This means that all consumption applications and source systems access the same data instance. This is essentially a closed-loop MDM: all application systems are integrated through a centrally managed primary data. At this level, all systems seem to be the same version of the truth. The operating application system and MDM content are synchronized. Therefore, when a change occurs, the operating application system is updated. In those familiar MDM Architecture styles, the persistent bus architecture, when a bus updates all the operating application systems, will reflect this change, forming a direct operational view of the change. In the registration environment, when data is updated, the bus connects to related system application transaction updates through the web service. Therefore, Mdm Level 5 provides an integrated, synchronous architecture. When a system with permissions updates a data value, all the systems in the company will reflect the change. After the system updates the data value, do not select update for the corresponding value in other systems: Mdm will make this update transparent.

from MDM Level 4 to MDM Level 5 means that the MDM functionality is not specially designed or encoded in an application. This also means that primary data transmission and supply do not require dedicated development or support from the source system. All applications clearly know that they do not own or control master data. They only use data to support their own functions and processes. Because of the MDM bus and supported IT infrastructure, all applications can access the primary reference data. After completing MDM level 5, a company will connect all their applications-both operational and analytical-all access to primary data is transparent. For example, when a customer updates her status-do not register the System of the change-data changes will be broadcast to all application platforms (so consistent ). Mdm Level 5 implements the data concept as a service. Mdm Level 5 ensures a consistent enterprise image of the primary data topic domain. Defining "customer" is actually the same as accepting changes to the customer's primary data business rules for other applications. Mdm Level 5 removes the last obstacle to primary data: Unified adoption of data definitions, authorized use, and change propagation.