Last time we started to discuss the strategy for applications to transition to using master data services. At the top of our master data services stack, we have the external- or application-facing capabilities. But first, let’s review the lifecycle of data about entities, namely: creating a new entity record, reading a record for an existing entity and updating an entity’s record.

We would normally add “retirement” of an entity’s record as well, but instead we can fold that into a more general categorization of “transition” of entity data, which includes retirement or deletion as well as conflation of one entity record with another when the two records are determined to represent the same real-world entity.

The goal of providing application-level master data services is to augment existing capabilities with the benefits of MDM: unique identifiability, identity resolution, uniform identifiers that can be shared across different enterprise applications, improved data quality and standard representation of common reference information.

That being said, some of the services that can be exposed to the applications include:

• Searching for an existing record for an entity and determining membership in the data set. For example, when there is an attempt to add a new customer into the data set, first check to see if the customer is already known.
• Retrieving one or more existing records that may represent an entity. Here, an example happens when one or more master records match with a provided set of identifying attributes. In that scenario, a process might be adjusted to let an actor determine if the data in any of the returned records is close enough to the provided identifying attributes to presume equivalence.
• Creating a new record for an entity, once it can be determined that the entity does not already have a record in the system.
• Assigning a standard, unique identifier that can be used across the enterprise.
• Enriching provided entity data, which can include standardization with the master representation, formatting according to shared business rules, cleansing of recognized flawed values, and validation in relation to shared master reference data value domains (such as official values for states of the United States).
• Cross-reference lookups, in which one known identifier is leveraged to connect to the unique master identifier, then to other application identifiers for the same entity.
• Relating sets of records based on defined master relationship types such as family, household, company or other types of affinity relationships.
• Looking up relationships – given an entity’s record, find all sets of relationships and those who are related to the entity based on those relationships. An example is finding all individuals who share a family mobile communications account.
• Breaking or deactivating a relationship (if it is determined that the relationship no longer holds).

Of course, applications may want to invoke these capabilities as batch services (providing collections records and expecting the side-effects of the enumerated services to take place).  Increasingly there is a desire for real-time integration, as well. In addition, these service transactions should result in maintaining historical tracking in case there are any needs for review and/or roll back.