Master Data Management Experience

Master Data Management Experience

2005.08.29 from: ZDNET

In a company, the main function of the Primary Data Management System (MDMS) is to have a single system as a reference point for all public data items.

In the past year, Builder.com has not been able to solve the problem of primary data management with multiple clients. Therefore, based on my experience, I wrote an article for them about how to achieve the best management of primary data. In this article, I will examine and analyze all implementation processes, lessons learned, detours, and corrections made to the Goals.

In a company, the main function of the Primary Data Management System (MDMS) is to have a single system as a reference point for all public data items. Then, each "customer" system in the Organization can refer to this system to manage its key data, so as to ensure data consistency and correctness throughout the application suite.

Learn about MDMS through other applications
In my previous articles, I pointed out that in the company, the process of achieving this goal is very slow, but it is indeed moving forward. This is mainly because there are three types of applications in the company:

Newly created applications, including internal and external applications and some applications that do not need to be customized.

The upgraded application may have such a window in an existing system. You can use this window to perform the upgrade.

There is no Upgrade window in the system for the legacy applications, and there is no alternative product for the system.

In the first case, if you have realized this in the process of system analysis, as part of the R & D or installation and configuration process of this type of project, you can introduce it into the MDMS system as a connection to the MDMS system. If there is no connection in this regard, the main or part of the reason can usually be attributed to no budget, no available resources, or no time. However, if you have considered this connection problem and have budget, there is no reason not to allow these new applications to make full use of MDMS.

In the second case, planning and budgeting can be linked as part of the system upgrade procedure. Of course, to add connections from these systems to the MDMS system, you need to perform a lot of analysis on the impact of such connections. For example, if you want to upgrade a data item stored in the MDMS, so what is the impact on the system? In addition, in such projects, funds are generally used for new features rather than infrastructure improvement. Therefore, some low-priority connections may not be executed during a specific upgrade process.

The last case is the legacy applications. From the perspective of connecting to the MDMS system, in some large companies, legacy systems are the most common and most complex systems to process. Today, many companies have an important program using a so-called "Legacy" language such as COBOL, according to a statement of DevX:

"70% of the world's data is processed in the COBOL language, and 90% of the ATM transactions are processed in the COBOL language. Today, 30 billion COBOL transactions are processed online every day. Among the top 500, 492 use the COBOL language, including the top 100, and the current investment in COBOL has exceeded 3 trillion USD. "

Despite this situation, few programmers have the required COBOL skills. This is because many programmers with this skill are at the retirement age. Because programmers with Cobol skills seem far from having Java or. net skill programmers have attractive prospects, and now the number of programmers with such skills is dropping sharply. If the company does not consider these problems wisely, this problem will be similar to the Y2K problem of the year, which may be a headache and may lead to a large increase in salaries of programmers with this skill.

In some companies, there is such a saying: "If there is no problem, you do not need to repair it. "And they use it as another common reason that they will not make any improvements as long as these systems are able to work, and limited funds, resources, and time are best spent elsewhere. This makes it difficult to integrate such systems into the new Mdms system, but in the face of this trend, my suggestion is: although these resources can still be used, we should at least consider them as much as possible, of course it is relatively cheap and should be given priority.

Parallel R & D problems
One of the main problems we need to solve is that while developing the Mdms system in an organization, we often have other R & D work in parallel. Therefore, the planning of Mdms or other systems often causes some problems. These problems may include the following scenarios:

The MDMS system does not obtain the data required for initial planning until MDMS is "running.

As a common and system-required data, it was not intended to be included in the MDMS system.

The common data identified in existing applications is not extracted from MDMS.

For R & D teams and MDMS teams, there are other restrictions such as budget, time, or resources.

Deploying an Mdms system in an organization may bring about a lot of modifications, because managers always try to require that the development path and upgrade path be consistent with the development path of the Mdms system as much as possible. Although this does cause a lot of headaches and other problems, it is still worthwhile in general.

One of the several teams I have worked with is to store their data in a local database, at an appropriate time, or import the data to the database from the Mdms system, or change the connection so that the data can be loaded directly from the Mdms. In this way, the local application can switch its management data to the Mdms system one by one according to its own pace, in addition, they will not be affected by other activities or be bound by these activities. This is because it is relatively easy to change a Database Connector or add another database to a data activity script, such as EAI, ETL, or even an SQL Server DTS package.

Case Study
One of my clients is very special. He knows the impact of any modification to the Mdms System on enterprise operations, in addition, he knows the rate at which data flows through other systems during the last update of internal classification inheritance. Although only a portion of the data has changed, after the change, the IT department will begin to receive a subpoena requiring technical support-They claim that the data in system A does not match system B, because at that time, only one of the systems had changed, and the other system had not yet had time to change.

Then they will find another system-system C has crashed, because the database of system C contains the relationship between the classification inheritance table and the products sold by the company. These changes have damaged the original connection, resulting in system errors and some data loss in system C. Fortunately, the system has discovered the problem before it passes the corrupted data to other systems, otherwise, end users may use the corrupted data to do whatever they want.

There are indeed some risks in connecting various systems through the Mdms system. These risks make you doubt whether they are really worth taking. For this reason, the IT team had to invest a lot of time and resources to back up system C, not to mention the end users who lost confidence in them, and end users may use this as an episode in their work.

Does anyone support Pooh Sticks?
Pooh sticks is. a. A game created by Milne. In this game, each participant puts a stick into the stream to see who is throwing the stick first to the designated end location.

No matter how you connect various systems to achieve data sharing, when data begins to flow, it is very important to take a look at how the data flows into its subsystems from the system; for example, whether these data streams are automatically loaded every night or manually initialized and uploaded? Or is it discarded once a week? If you can understand this and perform a reasonable analysis on each system, when the changed data in the Mdms system is disclosed through your infrastructure, you will know what problems will arise.

Because of various factors and data constantly flowing through the system, some systems may not display identical data even when the same point occurs. As long as the customer system knows this and accepts this fact, it may not become a major problem when such a problem occurs for the first time. The Effects of Changes in a data item may vary depending on different factors, such as the data item, system, or use of the data item.

For real-time systems, I mentioned this in one of my university presentations, "even if the correct data appears at the wrong time, it is still a mistake. "

Initially it seems that this ing work is a relatively simple process, so we connect several key systems together. However, this work has become a very large project, because we did not strip these systems, did not record the application in advance, and found many expired documents, etc, therefore, our central IT team cannot control these systems. In addition, we also found that to determine the purpose of data in various systems, simply asking the corresponding project manager can not solve the problem, in order to track the use of data in the code, we have to get program developers involved, and we need to meet key users so that we can determine the impact of our changes. This is the biggest problem to be addressed by the launch of the Mdms system.

Three-in-One MDMS System Management Team
In my original article, I once suggested that the best way to implement the Mdms system is to build a management team which consists of three aspects: one member manages the data in the Mdms system, the other member manages the use of the data, the third member manages the main technical contacts related to the Mdms system, and the use of the data in the system (see figure ).

Figure A: three-in-one team

This implementation method has been adopted by a company I serve, but for the MDMS system, no "three in one" team member works full-time. However, the composition of three members from different departments within a project team ensures that the MDMS system can take a solid step towards becoming the core system of the company's infrastructure.

In the early stages of MDMS system deployment, another role is required, that is, the Evangelist of the MDMS system. This person must publicize the concept and advantages of the MDMS system to the IT team and major corporate shareholders. These shareholders will not only invest in the MDMS system, but will also fund those systems that need to be changed to ensure compatibility with the MDMS system. It is particularly important to enable different departments of an enterprise to accept the concept of the MDMS system, and to enable them to know that the MDMS system can make their work easier and their efficiency higher, and it will produce higher productivity.

Case 2
Recently, a project for a very large equipment company in Europe is to implement a variable control system. We can use their MDMS system to provide a large amount of necessary data for the new system. The company already has a good storage solution for this data, which is well managed and well controlled. Therefore, we do not need to process more data. This project saves us a lot of time, resources, and money, so that we can focus our main efforts on major improvements in the new system and can be used to develop new functions.

For data items that do not exist in the MDMS system, we store them in our own small database. When the data in the MDMS system can be used, we will find the most appropriate update method for this data. The result is that almost all the data required by this system is from the MDMS system, and some data can be directly fed back, other data can be loaded at different times.

Lessons learned
Now, we have realized the lessons learned in this project. Our main lessons are far more:

Planning

Be sure that you know when and how data flows from the MDMS system to other systems, and be sure that you know the impact of data changes on the system.

Carefully consider the annual plan of your IT team and try to be consistent with the data already included in the MDMS system when developing similar systems.

If there is a big change in your data, you should plan it separately.

R & D

Only develop the functions of the MDMS system you need. Remember that this is only a data source, and remember that this system will not be directly used by a large number of end users.

Provide as much public data access infrastructure as possible between the MDMS system and other systems. This reduces system complexity and makes data maintenance and technical support easier.

Communication

Maintain regular communication with the IT team to ensure that the MDMS system can provide data to them as much as possible when they need data.

It is necessary to maintain regular communication with end users so that they can understand the benefits of using the MDMS system, because their investment can bring more time and benefits to them.

Looking into the future
In the next few months, we will focus on identifying and including as much public data as possible in the MDMS system, systems that are currently using the data are also encouraged to obtain the public data from the MDMS system. We also need to consider the relationship between data items in different systems (for example, you have A product type in the system as, however, your sub-product types may be 1, 2, or 3), and the effective rules used for different data items in each system. This ensures data consistency between systems. Of course, some of the relationships and rules may have been resolved within the MDMS system, because they just extended from a simple data warehouse.

We also need to consider what types of data can be stored in our MDMS system, such as the translation of frequently used idioms, usage instructions, and management of digital assets, such: product ID.

In this case, the main project of the team is to analyze the data flow and usage of other systems. The work involved will consume most of the resources of the team, in addition, most people in the company may be involved in the process of analyzing all systems.

For any new R & D, including upgrading, connecting to the MDMS system is a required feature and there is no reason not to do so. In some cases, IT is forced to roll back to ensure that each project has sufficient funds and time, and that the work has been completed correctly. In addition, another team may be set up in the company to develop data sharing tools, such as ETL and EAI, to ensure that connections between systems are established in a public and manageable manner as much as possible.

We also need to begin to note that software in the new MDMS field, such as the sap mdm system, can be used to replace our own MDMS solution.