Multidomain MDM

Introduction

Multidomain Master Data Management (MDM) is the foundation for 360 Engagements that use Customer 360 or Supplier 360. Multi-Domain MDM can also be implemented without those accelerators, following best practices for designing the underlying data model and business entities.

There are numerous business goals that can be achieved with Multidomain MDM. These include:

• Enhancing customer marketing opportunities
• Meeting regulatory or compliance requirements
• Establishing enterprise data governance and operational efficiencies

As its name implies, Multidomain MDM will house master data and relate different data domains. Master data is defined as attributes that are critical to deduplication of data (e.g., names, addresses, and identifiers). Master data also includes critical relationships within and between data domains, creating the 360 degree view. Data domains are aligned to business entities, such as individuals/persons, organizations, and sales organizations.

The data sources that are processed into MDM can be consolidated to create a single version of truth or golden record. The MDM User Interface (UI) allows for different levels of authorization based on a user’s role. The UI provides a history of any changes made either from the data sources or by data stewards. Graphical views of hierarchical as well as network relationships provide a visualization of linking within (e.g., householding) and across (e.g., customer to product) data domains. Master data and its relationships can be distributed by various means throughout the enterprise.

MDM, the application, is designed to be configurable and can manage what has been already described above. MDM comes with an embedded Business Process Management (BPM) application, ActiveVOS (AVOS). AVOS is tightly coupled with MDM and BPM workflows are available and can be customized to meet the data authoring requirements in MDM.

MDM, the solution, will be comprised of other external applications as well, such as those for data quality, data integration, data warehouses, and analytics.

For every MDM project, whether it is the initial implementation or extending onto the existing MDM Solution, the phased approach is the same: Analyze, Architect & Design, Build & Test, and Deploy & Operate.

Pre-project Planning

The business goals to achieve with MDM must be outlined. Likely, a road map will need to be developed in order to be able to ensure that value can be delivered incrementally without getting bogged down and short-changing the quality of the requirements.

Understanding of current pain points and how the MDM solution can overcome these must be documented in the business requirements as well.

Identification of the data sources (e.g., internal, possibly external third parties), the data consumers, and means of integration must be done. Again, this likely will be phased across the roadmap of the 360 journey. Another critical decision is the technical architecture supporting the MDM Solution -- on prem or hosted in the cloud. Multidomain MDM can be placed into either environment. Ensuring the proper supported servers and operating systems as well as sizing of these server must also be done. Among other IT activities will be determining how many environments will be needed (e.g., Development, System Integration, QA, UAT, Production) and which data security policies are needed, possibly driving what type of data is available in the different environments (e.g., can’t have production data in development).

Once the requirements, road map and infrastructure are decided upon, project staffing roles need to be filled. Among these roles are:

• Executive Sponsor
• Business Stakeholders
• Subject Matter Experts
• Business Analysts
• Project Management
• IT Architects
• IT Administrators
• Development team
• Testing team
• Data Stewards

During the project kick-off sessions, the representatives from the different roles above meet to review the solution roadmap, business requirements, the data sources and consumers, and the IT architecture.

Discovery & Analysis

The discovery phase will align the business requirements to the solution and prepare for implementation build.

Data profiling of the data sources is critical to the success of the project. Therefore, access to the production data as well as Subject Matter Experts with institutional knowledge of the data and systems is needed. Focusing on the attributes that will be in MDM, the profiling analysis will review various measures of data quality, typically using the Informatica Data Quality application (which is a separate product from Informatica than MDM and may need to be licensed along with MDM) to map source attributes to MDM target fields (i.e., build the MDM data model), and determine the derivation of building in-scope hierarchies and relationships and aligning records to MDM types (Is the record a person or organization? What type of address or phone number?).

The results of the data profiling will be reviewed and will drive how to implement cleansing/standardization, matching and survivorship and validation rules.

Data integration patterns (e.g., batch, services, pub/sub) need to be documented per source and consumer. This will include initial and ongoing data loads as well as the frequency for ongoing integrations. In particular, data volumes need to be set as this will be needed to confirm sizing and capacity of the technical architecture supporting the MDM solution.

Data stewardship and other possible UI roles will need to be outlined. Defining what these roles will be authorized to do within the UI and any requirements for business process workflows for these roles will be reviewed.

Functional requirements will be documented to align the business requirements as to how the implementation will deliver these items.

Architect & Design

Using the business and functional requirements as well as other outputs from the Discovery and Analysis phase, the MDM solution will be architected and designed.

Data modelling will ensure the MDM physical data model will properly structure the required master attributes and relationships. Whether this involves building new tables or extending the existing data model, as would be done if using Customer 360 or Supplier 360, the data model will be reviewed with the business and IT stakeholders.

Business entities are the composite data structures that organize the data display in the User Interface into a complete view of a person, an organization, or another defined entity. Business entities can also be returned in a request service call to MDM, providing the full set of data for a single entity. Defining the business entities in scope for MDM will be done during design as well.

Rules for the following will also be designed based on the requirements:

• Match Rules: Establish which attributes will be used for deduplication, the need for exact or fuzzy matching as well as which rules result in automatic matching or need manual review.
• Trust Rules: Upon record consolidation, how should the contributing data survive on the consolidated (single version of truth) record?
• Business Rules: Design how business or validation rules will be implemented, ensuring that these can be used during batch, services, or user inputs in the UI.

Extending or customizing the existing AVOS workflows will also be designed to ensure support of business requirements.

Build & Test

The build and test phases are performed in the lower-level environments.

Among the development activities will be:

• Configuration of the MDM physical data model and integration targets
• Integration development and source to target mappings
• Configuration of business entities and UI
• Configuration of match and trust
• Match tuning, which requires iterating through cycles of matching full sets of in-scope production data, reviewing results with stake holders, adjusting match rules, and repeating the cycle
• Configuration of user role authorizations
• Development of AVOS business workflows
• Outbound integration development

Preparation for test planning can occur in parallel with development. Testing commonly includes dry run testing, system testing, integration testing, performance testing and user acceptance testing (UAT). The latter requiring some time once development has been promoted to the UAT environment to allow for the users to become familiar with the UI and its functionality.

Each environment needed will require installations of the applications and their supporting servers. Run books for these installations will provide documentation that can be followed in the higher environments.

Deploy & Operate

Preparations for deployment can begin in parallel to the test phase.

Informatica recommends having one lower environment that mirrors production. In that environment all of the activities and steps for go-live can be conducted ahead of time to ensure successful production deployment and operation. Code promotions, initial data loading, setting up of user authentication/access, and job scheduling are some of these activities.