Most data integration projects mandate unique skill sets. Far too often, though, IT management reallocates resources from other projects or workgroups in order to accomplish these efforts. Such decisions are only as effective as the manager’s understanding of the discrete talent necessary to get the data integration job done. Master data management (MDM) - with its ability to address economies-of-scale issues around large data integration efforts - challenges the traditional “system at a time” approach typical of most data integration projects. Consequently, MDM development calls for a specialized combination of talent, requiring the team to not only have OLTP-based development skills but also data quality and content expertise.

MDM Guiding Principles

As Jill Dyché and I described in our book, Customer Data Integration: Reaching a Single Version of the Truth (Wiley, 2007), MDM is the collection of processes, controls, automation and skills necessary to standardize and integrate subject area data originating from different sources. The implication is that the MDM team must bring a variety of skills to the program. The most successful MDM projects begin with the principles that:

  • The company’s standard system development lifecycle (SDLC) should include data-centric development activities to ensure MDM success. Most SDLCs are application focused and lack the rigor needed for data-specific tasks such as data requirements, cleansing and acceptance testing.
  • MDM development is a broad term, involving diverse tasks such as data administration, application interface development, hub configuration and business rules automation, to name just a few. It’s unlikely that existing staff members can assume new MDM projects without extensive training.
  • Requirements are different for MDM. Savvy IT organizations understand that MDM delivers operational integration. As such, requirements should also include service level agreement-based operational rigor (e.g., processing throughput, transaction logging and system management).
  • To support MDM, data administration must exist as part of IT’s competency set.

All this impacts the MDM development team. Figure 1 shows an organization chart I helped institute at a large financial services company.
In this case, the MDM development organization is separate from the MDM management team, which handles maintenance and support. MDM development is responsible for on-boarding individual applications in addition to the initial data loading, development and configuration of the MDM hub. MDM development also includes a separate testing team that ensures the hub can support the integration of new platforms, applying the diverse application-based create, read, update and delete (CRUD) processing.

The MDM management organization is charged with continuous maintenance and support of the hub, data content, quality improvement and data conflicts. MDM management may enlist data stewards to resolve data conflicts and monitor MDM data quality to refine matching and integration. The deployment team deals with release management of hub changes, including improved rules to support value survivorship, source integration or the on-boarding process.

Each of the teams that comprise the MDM development organization has its own charter, role descriptions, and key performance indicators.

Playing Nice with Others

Because MDM projects often represent the first time data quality and application transaction processing converge, it’s critical that MDM project teams reach out to other organizations in the enterprise and collaborate with them. These might include:

  • The data management team. We’ve been advocating discrete data management teams for a few years now. They own and support data modeling, metadata management and data standards - at the enterprise level.
  • The data governance council. Many of the information policy and decision issues that emerge as part of MDM will naturally be beyond the purview of the MDM team. Indeed, data governance is mandatory for defining how information will be accessed and used by systems and knowledge workers alike.
  • Application development. Developers of other enterprise applications will want to leverage the MDM hub to support their application requirements sooner or later. Indeed, one of the value propositions of MDM is that it alleviates data rework for every new development or maintenance effort, rendering applications programmers de facto MDM stakeholders.
  • IT architects. The IT architecture organization should participate in the design review processes undertaken by the MDM development organization. This ensures that the MDM solution conforms to the company’s development standards.

As with other strategic IT initiatives, there’s no such thing as one size fits all with MDM. And, as with most IT initiatives, clear role and skill-set delineation can mean the difference between a scrapped project and a problem solved!

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

Don't have an account? Register for Free Unlimited Access