SOA Patterns | Design Patterns | Reference Data Centralization


SOA Patterns > Service Implementation Patterns > Reference Data Centralization
Home > Design Patterns > Reference Data Centralization

Reference Data Centralization (O’Brien)

How can enterprise-wide reference data be abstracted, centrally governed and managed?

Reference Data Centralization

Problem

The same reference data often applies across different business services, leading to redundancy and governance challenges. This data can be business-specific data such as product codes, or can be generic data such as Countries, States and Counties.

Solution

The storage, management and access to reference data are centralized.

Application

A specialized metadata service and repository is employed and accessed using a dedicated reference data utility service.

Impacts

Services are subjected to increased performance overhead and risk.

Architecture

Inventory

Problem

Reference data is used extensively throughout applications and business services to capture and manage state, statuses and different variations of categorizations. It is not uncommon for the reference data to be duplicated throughout services and applications, causing significant redundancy and accuracy issues.

Reference data often requires version management and can be subject to complex hierarchies, including one-to-one, many-to-many and many-to-one relationships.

Solution

Reference data can be physically abstracted and managed as a dedicated part of the architecture in a central location to be accessible using a centralized reference data utility service. Business services and applications can access the reference data service and benefit from a consistent, centralized view of the reference data for both business-specific and generic reference data.

Application

A centralized reference data service is established to provide an official access point for the retrieval and management of reference data.

The actual application of the reference data will vary depending on the organization’s requirements. It may be employed in particular to perform the following tasks:

  • Providing master flat lists to applications and services, for example:
    • Get all Claims Types
    • Get all Rating Types for a Quote
    • Get all Address Types
  • Providing master hierarchical lists to applications and services, for example:
    • Get all Counties for a States
    • Get all States for a Country
  • Providing lookups and translations between enterprise and legacy reference data. This strategy is often implemented when a business service must connect to multiple legacy systems to perform the same activity depending on business unit, product line and so forth. The reference data values supported in the Canonical Schema will often be different from that which is required by the legacy system, necessitating translation.
Reference Data Centralization: Services and applications use the reference data service to retrieve and manage all reference data values and relationships.

Services and applications use the reference data service to retrieve and manage all reference data values and relationships.

Impacts

Because the reference data and its corresponding services are applied across the entire service inventory, a number of impacts can occur:

  • Performance requirements and latency becomes a factor. A reference data service can be designed with caching in mind to reduce these impacts.
  • Version management becomes more important. Without version management, the reference data cannot provide a picture over time and is subject to being the latest-only.
  • Legacy applications may not be able to access the reference data if they are not service-enabled. Duplication and redundancy may still occur and need to be managed effectively.