This chapter introduces the following samples:

This chapter includes the following sections:

Policy enforcement is one of the components that make up policy management. The other two components are policy administration and policy monitoring. Figure 7-1 highlights their complementary capabilities.

The master data governance solution, which is based on a mix of methodology and technology, provides the assurances that master data can be trusted and that processes are empowered by the truth.

Before you explore each component, recall the definition of a policy as described in 3.1, “Definition and objectives of master data governance” on page 16. A policy is a characteristic of data that is required to satisfy one or more business processes or business outcomes. It must be concise and support measurement.

Policy administration captures and maintains an organization’s policies for use in monitoring and enforcement. Policy monitoring provides visibility into master data health. Master data health is determined by translating a policy into a quantifiable measure of master data policy compliance.

Policies, when converted to metrics, show where data does not support the business. Then, business impact can be determined. Root cause analysis determines which policies to target for data quality improvement. These targeted policies are implemented in policy enforcement. Policy enforcement ensures improved data health by identifying noncompliant items and then bringing them into compliance through the appropriate remediation processes.

A customer wants to trigger a data stewardship process whenever a patient, who is under age 18, does not have a guardian, is missing its social security number (SSN), or the SSN is invalid. The following policies are in place:

Records that do not comply with these policies are routed to the appropriate remediation process that is responsible for bringing the record into compliance.

A customer has a challenge in sales territories that are not correctly distributed and where payouts are misappropriated.

The root cause is that master data management (MDM) hierarchy changes are not appropriately approved or validated. In response, a policy, such as the following example, is defined and implemented in BPM Express:

“A data steward manager shall approve, reject, or modify changes to key customer hierarchy changes.”

The completion of this task by the data steward might result in alerting the sales territory management system so that the sales team can react to a significant merger.

Data quality improvement projects require a mechanism for enforcing critical policies. Policy enforcement supports these projects by providing assurances that master data is in compliance with these policies. Policy enforcement is built on BPM Express, which is an enterprise class BPM system. By using BPM Express, businesses can rapidly build process-centric applications through a What You See Is What You Get (WYSIWYG) widget (not coding based) design and deployment tool. This product is available to MDM customers free of charge to build MDM-centric applications. Note the following requirements:

InfoSphere MDM v10.1 provides MDM enforcement samples to help users enforce review and approval of critical data change to remediate noncompliant policies, and to manage entity consolidation. Two samples work on the MDM Standard, Advanced, and Enterprise Editions:

One sample, entity consolidation, works on MDM Advanced and Enterprise Addition. The following sections describe these samples in more detail.

BPM Express is the heart of policy enforcement. BPM Express supports the interrogation of master data changes and identification of noncompliant items. It also brings noncompliant items into compliance, routes data changes for review and approval, and supports entity consolidation activities. The characteristics of a policy determine which type of process must be implemented:

Each process might require manager review.

This section highlights the general aspects of policy enforcement. No single example can capture all the aspects. To begin, refer to the patient example that was introduced in 7.1.2, “Data stewardship process example” on page 121.

Policies are implemented as business rules called Business Action Language (BAL) rules. The BAL rules component provides a rule editor that rule designers use to author business rules by using natural language technology. Using natural language, instead of JavaScript, to author rules means that no programming expertise is required to create business rules, and the rules are easier for people to read and understand. Master data updates are fed to these rules for evaluation.

Processes are started based on the outcome of the BAL rules. In the example in 7.1.2, “Data stewardship process example” on page 121, a master record update results in an invalid SSN attribute. A process to bring the record back into compliance is started. By using automated tasks, the process reads more data from the hub or other systems that are necessary to support the UIs and business logic. UIs are displayed by using human tasks.

A designated user (for example, a data steward or sales representative) is made aware of an SSN violation by viewing the task inbox or by a notification the user received. This user selects the activity to view the policy violation and then edits the data, bringing it back into compliance. The outcome of this user action can be sent by email to a designated individual for manual update in a source system. Alternatively, the outcome might be programmatically persisted back to the hub or source system. Manager approval or review can be added to the process as needed.

Figure 7-2 illustrates the physical architecture to support the aspects of policy enforcement processes.

The need to implement policy enforcement has the following key business drivers:

You might be hearing the following phrases:

A key aspect to any operational MDM project is to consider the business processes that consume master data. If the success of your MDM projects depends on improving business processes, you must include the requirements of these business processes in the MDM requirements. Without understanding the needs of the business process that will ultimately consume the master data, you have no assurance that the master data will support the business process. Master data governance provides assurance by monitoring and enforcing the requirements of the business processes as policies.

This section highlights the following business process scenarios:

For some organizations, certain data changes have a significant impact on the business. These attributes drive business process decisions that impact market campaigns, pricing discounts, compliance levels, and support contracts. The attributes are critical to the business, and changes to them must be reviewed. Through the critical data change review and approval process, owners of the consuming systems and process can review and approve updates to master data attributes with the control that they require.

For example, the customer service and account management departments both contribute data to the MDM hub of an organization. An individual’s contact information is often updated by the customer service representative (CSR) when the individual calls in for help or questions.

For high profile accounts, such as for clients who receive a platinum level of service, a call from an individual might trigger downstream activities. For example, a new point of contact is assigned to a key account or the address of the account owner changes. In this case, the sales team might respond by contacting a new customer contact, by assigning a new sales representative based on a new customer location, or by extending new offers that are based on recent questions. This approach can be wasteful and potentially risky if these activities are performed in error.

The account manager who is assigned to these key accounts can review the updates and then approve or reject them to ensure that the sales team responds only to accurate information.

Figure 7-3 illustrates the systems that act as a source for MDM data and a system that uses the MDM data.

In Figure 7-4, changes in one source system are submitted to MDM.

Figure 7-5 shows the business rules that are applied to the update. In the previous example, the account manager sees only updates for key customers. These business rules can use any single or multiple set of attributes as criteria for defining the information that should be reviewed. After an update is identified as one that needs review, a business rule determines the right individual or group to whom to route the update. A process automatically prioritizes and routes the work, guiding users through the appropriate decisions.

For some organizations, consumption of MDM data by business processes is contingent on trust. The business owners who are responsible for these processes must trust in the data before they are willing to include it. Trust is more than just being accurate and complete. They want to ensure that their business rules and constraints are represented. Business owners must trust that MDM data is compliant with their requirements (or the requirements of the data governance council). Policy remediation provides the assurances that MDM data is compliant.

Continuing with the example from the previous section, the organization has a policy that all platinum accounts have an account manager assigned. The organization also requires a customer’s SSN and address to be valid. In addition, if a patient is under age 18, they must have guardian.

Figure 7-6 shows an MDM update that results in a change to the name, ID, and address of the golden record.

Policies are implemented as business rules and are used to identify noncompliance by interrogating MDM changes. Noncompliant updates are routed to data stewards. In prescriptive UIs, data stewards have the choice to bring the update into compliance by modifying or exempting the update.

For some organizations, automated record resolution (or consolidation) is not enough. Investment in manual consolation and review is necessary when the high profile customer of an organization has duplicate records. Choosing which class of service, billing address, and primary contact is the correct one is critical to maintain high customer satisfaction. Correct linking of high profile customer accounts across lines of business ensures a consist customer experience. Through the entity consolidation process, by editing the golden record directly, data stewards can preview the automated collapsed record and identify areas of potential conflict. They can also manually select the attributes that survive or provide new attributes. Business rules should be added to this process to ensure that only high priority items receive data steward attention.

For example, two source systems (A and B) each create an account, A1 and B1. MDM patching identifies that account A1 and account B1 are the same customer. Account A1 has a platinum level of service, and account B1 has a bronze level of service. Because of the priority of the customer, the data steward is notified of this task and works to collapse the two accounts into the golden record. The data steward decides to use the contact information from the A1 account based on personal experience with the customer. The Account Manager is notified of their changes to the customer account and can then validate these changes.

Figure 7-7 shows three source system records in the green rectangle in the upper left corner of the figure. The lower two records in the green rectangle are newly added to the MDM hub. MDM matching identifies these three records as suspects or candidates (probable matches of each other). The entity consolidation process routes this task to the data steward to validate which items are matches and to select the attributes from the source records that should survive in the golden record.