Examples: Hierarchy of products in production at all my customers in the aerospace industry in Japan Or, Hierarchy of costs centers associated with distribution in the Province of Ontario in the country of Canada Example of shared semantics – Turkey the product, may not mean the same thing as Turkey the country.
BACK STORY: - For many software vendors and Global 5000 enterprises, Reference Data Management (RDM) is a relatively new offspring of Master Data Management (MDM) functionality. - RDM provides the processes and technologies for recognizing, harmonizing and sharing coded, relatively static data sets for “reference” by multiple constituencies (people, systems, and other master data domains). - Such a system provides governance, process, security, and audit control around the mastering of reference data. - In addition, RDM systems also manage complex mappings between different reference data representations and different data domains across the enterprise. - Most contemporary RDM systems also provide a service-oriented architecture (SOA) service layer for the sharing of such reference data. - Prior to the availability of commercial RDM solutions, organizations built custom solutions using existing software such as RDBMS, spreadsheets, workflow software (business process management or BPM) and other tools. - Such systems often lacked change management, audit controls, and granular security/permissions. - As a result, these legacy solutions have increasingly become compliance risks. - Because reference data is used to drive key business processes and application logic, errors in reference data can have a major negative and multiplicative business impact. - Mismatches in reference data impact on data quality affect the integrity of BI reports and also are a common source of application integration failure. - Just as businesses no longer build their own CRM, ERP, and MDM systems, so too are organizations beginning to acquire commercial RDM solutions, which can be easily tailored or configured and have the full ongoing support of a major software vendor. - Increasingly, many large enterprises have begun to make RDM their initial test case or proof-of-concept for their MDM evaluations. - As a consequence, MDM vendors are rushing to market RDM solutions to apply an MDM approach for centralized governance, stewardship and control. - Clearly, managing “simple” reference data will prove to be a key sales entry point for large enterprises and their MDM vendors. - Additionally, RDM can be expected to become a "ramp up" point of entry for many organizations planning for CUSTOMER, PRODUCT master and other domains, as well as an entry point into master data governance. - Moreover, RDM is needed in both operational and analytical MDM use cases where the capability is often used to provide attributes, hierarchies and KPIs.
An easy example of adaptations are customized hierarchies. For example, the geographic hierarchy used by: Finance may remake the geographic hierarchy to reflect the corporations legal organization (operating units vs. tax havens) ERP system/Supplier management may organize their countries / localities by manufacturing facilities Shenzhen vs. Hanoi vs. Canton, OH Sales economically similar countries (developed vs. middle income vs. emerging) OECD Countries
Coming to market during 2013-13 are RDM solutions characterized by multiple, diverse levels of integration with market-dominant MDM hubs (IBM, Informatica, Oracle, SAP) as well as repackagings of existing mid-market MDM capabilities to address RDM business needs (e.g., Microsoft's RDM product for Microsoft Master Data Services and Oracle's ongoing sales campaign for Oracle Hyperion DRM, etc.).
USD US Dollar American Samoa, British Indian Ocean Territory, Ecuador, El Salvador, Guam, Haiti, Marshall Islands, Micronesia, Northern Mariana Islands, Palau, Panama, Puerto Rico, East Timor, Turks and Caicos Islands, United States, Virgin Islands Reference data intersects with multiple domains (and other reference data sets). Often these relationships involve multi-cardinality. In our trivial example, unlike JPY and CNY, USD (like the Euro) is used as the official currency in multiple countries. More complex examples would include financial reporting. The US is currently transitioning from GAAP to IFRS; this requires the adoption of a new rules that affect how accounts are classified and treated (in essence new reference data with the same identifiers, but different rules). This means that the chart of accounts of an organization, organized for GAAP, will need to be remapped and new hierarchies created for IFRS. The need to document reference data, and their complex connections to other domains requires the platform to have robust data / semantic modeling.
When dealing with reference data, simple versioning is often not enough. This is because there are relationships between versions. The platform needs to be able to model inter-temporal relationships. In the example beneath, without maintaining the linkages between versions, an analyst would not necessarily recognize that 2013.221114-8 were split from 2007.221119 (perhaps assuming, based on the description that 221119 and 2221114 were equivalent because they both mention solar power. We see the issue in reverse with 2013.31124 which is a union of 2007.311222-3. However, we cannot treat this relationship as a database-style foreign key because novel additions in a later would not necessarily have an antecedent in the prior edition.
Managing versions is not always a matter of going back in the past. When we think about private reference data (financial and organizational hierarchies, employee organizational changes) it is often modified when corporate actions / change takes place. For the organization, understanding how changes to this reference data affects not only downstream applications, but other linked domains is important. This is especially true when making modifications to hierarchies because often identifiers are re-used between periods. This means that the platform needs to support not just past, but also the ability to simulate and assess the impact of future changes. Current period hierarchies are necessary, but insufficient for performance analysis. Transactional data records the attributes, identifiers and hierarchies that were official at the time of their of execution. This reference data changes over time (especially in cases of reorganization). This means that the analytical system needs to have access to current and prior versions of reference data. Without consistent definitions (or translations) the analysis will be comparing apples to oranges. Access to future versions (due to reorgs) can be useful for when modeling the impact of change.
Coming to market during 2012-13 are RDM solutions characterized by multiple, diverse levels of integration with market-dominant MDM hubs (IBM, Informatica, Oracle, SAP) as well as repackagings of existing mid-market MDM capabilities to address RDM business needs (e.g., Microsoft's RDM product for Microsoft Master Data Services and Oracle's ongoing sales campaign for Oracle Hyperion DRM, etc.).
RDM field reports aaron zornes (new york city - october 2013) v4 print
Product Evaluation Criteria
& Field Reports for the
Leading RDM Solutions
8 th Annual MDM & Data Governance Summit
New York City
October 20-22, 2013
Chief Research Officer
The MDM Institute