There are two types of master data management platforms available today: those with prebuilt data models developed by the software vendor and those that are model-driven, where the implementing company constructs the data model based on its requirements. In the second scenario, project team members from business and IT work together to create data definitions and business rules; this process defines the MDM data model.
One could debate the merits of which is better. However, the ability to model data is a critical skill set for a successful data migration effort, regardless of whether the MDM platform has an out-of-the-box data model or uses a model-driven approach. As an example, your MDM initiative may require that you create a canonical model, which is a design pattern used to communicate between different data formats. You may need to map your different legacy systems' data to that canonical model so you can smoothly move your customer, product or other types of master data into your new MDM hub.
But even before you get to that point, a successful MDM implementation requires a full understanding of your source systems and their history and evolution. Profiling early and often is critical. Typically, an old legacy system no longer has a documented data model. There may have been one at one time, but through staffing turnover, changes in data requirements and undocumented system modifications, it no longer exists.
To understand what you're profiling, it's best to start by spending at least some time on a high level data model of the source system that's providing the data. You may never understand this system to the level of detail you'd like, and your data model may not go to the treetop level, but you're well-advised to have one. By not understanding the underlying database or application, you run the risks of extracting data in a way that doesn't make sense or not taking advantage of the opportunity to fix easily correctable data quality issues at their source.
If you are implementing a model-driven MDM platform, data modeling is definitely a critical skill set for someone on your project team, because you'll literally be building the MDM repository from scratch. You'll have the power to design, build and deploy the master data management system to exactly match your business, and with that power comes great responsibility. Your data modeling must be in sync with the way the business operates in the real world across all important business units, geographies, channels and market segments, because the MDM platform can only be as robust and accurate as the underlying data model.
Data modeling is also a critical skill on the outbound side of the MDM platform as you publish data from the hub to the rest of the enterprise. You'll want to write Web services that provide useful functions and make master data available to various applications, portals, data warehouses, and front and back-office systems around the enterprise. Skilled data modeling will be helpful as you work to understand how those applications will consume the master data coming from the hub's canonical models.
As much as you work to standardize things around the hub, the enterprise is a very heterogeneous place with all kinds of strange technologies that have been incorporated over the years. Data modeling and data mapping are usually the key to transforming and translating between point A and point B. There are tools to do that today, and I'm a big believer in them. In particular, I tend to avoid writing custom code to transfer data between key places in the enterprise, because the maintenance cost of that custom code is typically four to five times its original cost to create. That's why I am a big fan of ETL and enterprise service bus products, which make shipping data around the enterprise more manageable and reduce or eliminate the need for writing custom code. Even with these tools, a good foundation in data modeling still goes a long way. Recently, an MDM project team reached out to us for help in reviewing some of their project deliverables, and as it turned out, their data modeling. It was fun helping them, and in addition to the data modeling, we worked on some data flow diagrams and process modeling.
Data modeling is one of those core skills that both business and IT people should learn. Some great products are available to make the process easier, although I've used PowerPoint in a pinch. What it boils down to is communicating the structure of existing databases, tables and columns, or envisioning the structure of a new database, with its tables, columns, constraints, business rules and other properties. Where MDM is concerned, data modeling is the lingua franca that helps all of the parties in the project better communicate with one another.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access