Oracle Data Relationship Management Book

Getting Started with Oracle Data Relationship Management (DRM)

Welcome to the first book on Oracle Data Relationship Management (DRM)!

Organizations commonly face challenges with the management of key data elements across organizational systems. The introduction of ERP systems, web-services, and modern development platforms has created an environment for improved data element sharing, but challenges still remain for centrally managing these data elements across the organization. Master Data Management (MDM) is the construct commonly mentioned when discussing organizational maturity around core business data referred to as master data.

Oracle DRM provides a scalable platform for managing master data in an organization. The solution provides a framework for implementing an effective data governance strategy, and serves as a secure central repository with security, workflow, and the necessary integration to external upstream and downstream systems.

The following topics are covered in this chapter:

  • Master Data Management
  • Oracle DRM Capabilities
  • DRM Use Cases
  • Benefits of a DRM Implementation

Master Data Management

An increased emphasis on system integration and organizational analytics in the past two decades has drawn to light the challenges and issues organizations face with their management of data elements across the enterprise. Data elements are the heart of system functionality and play a major role in system operations and the generation of enterprise metrics. The cleanliness and consistency of data elements across systems can have a major impact on the quality of any output generated and any effort to generate metrics in a business. Many organizations experience situations where similar data elements and constructs have vastly different definitions – depending on the source system – which creates issues when interpreting system outputs. Solving these challenges highlights the need for systems and processes to centrally manage data elements across the enterprise.

Master Data Management (MDM) is an organizational construct for the central management of data elements in an organization. The MDM concept is an organizational shift from silos of data elements, typically managed in a system, to an enterprise view of an element and its relationship across the enterprise. MDM initiatives can start within one organizational area and branch out into different parts of the organization. But, as is the case with any large scale organizational initiative, the most effective methodology is a top-down approach with executive sponsorship so that silos of information can be broken down. This is typically as much a political challenge as a technical one.

Benefits of Master Data Management

The benefits of Master Data Management are seen across all levels of the organization. Many additional benefits of MDM and Oracle’s DRM software, as it pertains to MDM, are discussed throughout this publication. The following is a list of benefits discussed within the book:

  • Consistency across organizational systems for building and reporting enterprise metrics.
  • Common definitions for data elements that can be tracked across the organization, keeping reports containing source data from various systems in synchronization.
  • The central management of all aspects of data elements allowing downstream systems to obtain a common set of definitions and relationships.
  • Central tracking of the metadata for data elements and the relationship of data elements to one another in the enterprise, commonly referred to as hierarchies, which keeps critical organizational reporting structures in synchronization.
  • Business Rule validations can be run against the metadata to ensure all agreed-upon rules are enforced in a centrally managed repository.
  • Auditability of a data element, its metadata, and its relationships in the enterprise is significantly easier and more transparent with an MDM solution.

Master Data Management Implementations

The implementation of an MDM initiative is commonly completed through a set of processes by which the data elements of an organization are collected or created and then managed and distributed to external systems. The goal is to have all downstream systems use the same data elements, definitions, hierarchical constructs, and metadata through central management and governance. Another key aspect to an MDM implementation is the ability to enforce business rules to ensure that the master data conforms to predefined rules prior to exporting to downstream systems.

Implementing MDM within an organization requires more than just technology, and governance processes are undoubtedly already in-place at organizations that facilitate successful MDM strategies for data elements. Most of these processes are tied to job functions and roles. For example, the creation of a new General Ledger (GL) account requires approval by different groups within the organization. This simple example provides a scenario that can illustrate different levels of master data management maturity within an organization.

  • At Level 0 of MDM maturity, the process is siloed and each system has the ability to manage their accounts and account structures separately.
  • At Level 1 of MDM maturity, the process is coordinated in a manual fashion and an email notification is sent to the administrators of the different systems; there is no proactive way to know the Account Structures are in synchronization across the different systems.
  • At Level 2 of MDM maturity, the process is coordinated in a manual fashion and the account is added to a central MDM tool. Properties for each downstream application are managed separately in the MDM product and business rules are implemented to validate that the account meets all predefined data governance and formatting rules. The account structure is synchronized to downstream systems at the required frequency for each system.
  • At Level 3 of MDM maturity, the process is coordinated through a workflow tool and the account is added to a central MDM tool after being approved and enriched by all of the relevant stakeholder groups. At each step of the enrichment process, business rules are implemented to validate that the account meets all predefined data governance and formatting rules. Lastly, the approved account structure is synchronized to downstream systems at the required frequency for each system.

 

Organizational MDM Maturity Model

Organizational MDM Maturity Model

 

Data Governance

Data Governance crosses a large set of functional areas within an organization and consists of the appropriate mix of people, processes and technologies necessary to centrally manage data across the enterprise. Data Governance initiatives drive the need for technical MDM solutions, but there are also scenarios where the implementation of technical MDM solutions are the starting point for a data governance initiative. In either case, the need for a data governance strategy is critical or else the technical MDM solution becomes a central repository of siloed information and not a true enterprise-level view of the organization’s master data. While data governance initiatives can create bureaucratic and political issues within the organization, it is important to appropriately and efficiently scope the rules for the governance of master data in the organization.

The diagram below outlines the potential negative impact to the output of systems when the master data is managed in silos and the organization does not have a sound overall data governance strategy.

Lack of Master Data Management Practices Provide Inconsistent Information across the Enterprise

Lack of Master Data Management Practices Provide Inconsistent Information across the Enterprise

Effective Master Data Management Practices Provide Consistent Information across the Enterprise

Effective Master Data Management Practices Provide Consistent Information across the Enterprise

Data Governance Process Considerations

Efficiency is a major factor behind successfully implementing data governance in an MDM initiative. The creation of master data elements needs to happen rapidly to support business processes in most cases, and many governance initiatives impart layer upon layer of approvals that slow down the ability to create and/or broker the master data element to satisfy functional needs.

With the knowledge that governance initiatives can break down the effectiveness of master data or the functionality of the systems themselves, it is important to design the leanest approach for the creation and management of master data in the organization. This efficient governance approach should be applied to both the data elements as well as the properties that are collected for each data element.

Oracle Data Governance Software

With the direct relationship between data governance and MDM, Oracle recently released the Oracle Data Relationship Governance (DRG) package within its DRM offering. The Oracle DRG package enables different organizational resources to interact through defined governance processes inside DRM. This concept allows for the seamless governance of data elements directly on the master data platform through a configurable workflow. The Oracle DRG platform is discussed separately in chapter 8 of the book.

Oracle Data Relationship Management

Oracle Data Relationship Management (DRM) is a software component of both the Oracle Enterprise Performance Management (EPM) product suite and the Oracle Master Data Management (MDM) product suite that facilitates Master Data Management (MDM) inside an organization. Oracle’s DRM software can be applied as an MDM tool for all types of applications, but is commonly integrated with other Oracle Hyperion applications due to the hierarchical nature of data element relationships in the application. A growing trend with DRM is to utilize the product as a GL Segment authoring tool using the DRG approval processes for ERP systems such Oracle e-Business Suite and PeopleSoft Financials. DRM software provides a significant number of capabilities and functionality to aid in the management of master data inside an organization.

DRM Architecture in Oracle Hyperion 11.1

Understanding DRM’s architecture is the key to understanding the features of the product. Upon installation of the DRM application, the following components are automatically installed on the server:

Oracle DRM Architecture

 

  • Console – The Console component of DRM allows for the stop, start, and restart of DRM services. The feature also contains the ability to check application logs and is the module where updates are applied to the database when DRM is upgraded or patched. The DRM application backend database utility is located in the console, and the console is used during the initial install of DRM.
  • Web-Client – The Web-Client is the primary interface where most of the work is performed inside DRM. It is the user interface that permits access from system administrators down to the end-user. The module allows for the configuration of each of the system components, modification of hierarchies, and the addition of data elements and metadata.
  • Migration-Client – The Migration-Client component of DRM allows for the migration of DRM objects from one environment to another. The component is a very useful tool for the ongoing maintenance of DRM, especially if there is interest in creating new DRM objects in a development or test environment prior to moving to the production environment.
  • DRM Batch Client – The DRM Batch Client component is the module used to perform automation using batch scripts. All of the functions that can be performed in the web-client may be performed using this module, but the MDM Connect component allows for functions to be completed in a bulk and automated fashion. A scheduling tool can even be used to schedule the batch scripts.
  • Oracle Data Relationship Governance – The Oracle Data Relationship Governance (DRG) module is a separately licensed product and provides the workflow and governance feature-set.

Data Relationship Management Terminology

DRM has a specific terminology that is not completely consistent with other products in the Oracle EPM product suite. An understanding of DRM’s terminology is important to ensure understanding into the concepts described later in the book as well as for discussing the product with other DRM administrators and developers. Additionally, in order to be truly effective with a DRM implementation, users must be able to translate DRM terminology into language used by administrators of subscribing systems. The content in the next paragraph describes some of the most commonly used terminology to provide a solid foundation for working with the product.

A useful capability of the DRM product is the ability to create and maintain separate Versions of master data. Versioning capability provides the ability to take snapshots of master data at a specific point in time or perform what-if analyses.

The Hierarchy in DRM is a collection of nodes that are organized to represent a business structure within an organization. A typical hierarchy within an organization may be the structure of organizational departments or a global chart of accounts. Multiple DRM hierarchies may be structured in DRM to represent a full picture of a business hierarchy. The additional hierarchies commonly include alternate rollups of the same structure for reporting purposes.

A Node in DRM represents a single element of master data. Nodes are the core elements in DRM. A single node is structured inside a DRM hierarchy and is described by attributes. An example of a node includes a single account in a chart of accounts or department in an organizational structure.

Nodes are broken into two distinct categories through a system attribute to define the role of the node in the structure. The first is a Leaf, which is a node that only exists at the bottom-most level of the structure. A leaf may not have any nodes underneath it in the structure. In an account structure, a leaf node would be the natural account segment, such as 111000. The other type of node is a Limb, which is used to describe the parent/summary nodes of the structure from the top node down to the bottom of the hierarchy. It is possible to allow limb nodes to be at the bottom-most level of the structure, but it is more effective to assign bottom-level members as leaf nodes. Assigning leaf nodes to the bottom of the structure allows DRM developers to perform specific checking into the integrity of structures, especially for integrations with subscribing systems that require the distinction.

In the account structure illustrated below, a leaf node would be the natural account segment, such as 100111 and the limbs are the summary/ parents of the leaf all the way up to the top node of the hierarchy, to include 100, Cash, Assets, Balance Sheet, and Account – Balance Sheet.

Oracle DRM 1

The attributes to a node (data element) are called properties. Properties provide significant flexibility in managing information about a node as well as specific node formats for subscribing systems. Chapter 3, Building the DRM Data Model provides additional information on the value of properties in DRM. Properties can be sourced as well as derived, allowing for the use of logic to generate content about a node or the position of the node in the hierarchy.

DRM provides the ability to perform a check on the data entered into any area of the application as it applies to constants or other values in the application. Each constraint is referred to as a validation, and validations can be run during data importing, user interactions, and even during a batch export cycle. These validations are key to keeping clean and accurate data in the application.

It is important to understand that in Oracle DRM, metadata is a term that refers to configuration objects (e.g. property definitions, queries, exports, etc.) within the software; data refers to the hierarchies, nodes and properties that make up the master data for the application. The term metadata in DRM is different from common definitions, where the nodes, properties, and hierarchies are referred to as metadata and the financial numbers at the intersections of these dimensions are referred to as data.

Data Element Management & Hierarchy Capabilities

Data element management is at the core of the capabilities of the software. DRM software starts with the concept of a hierarchy, which are business definitions of the relationship of data elements to one another in a business construct. For example, the organizational structure of departments is a common hierarchy seen across many environments. These hierarchies contain multiple levels which are commonly ragged, where some parts of the hierarchy contain different numbers of levels than others. Hierarchies in DRM are defined through the creation of parent-child relationships between data elements. Multiple hierarchies can be setup depending on the business need for a business hierarchy structure or subscribing (downstream) system.

In addition to hierarchies, each data element in the hierarchy contains a set of system-defined and administrator-defined fields for capturing attributes. The attributes are defined at a central level in the application and can be manually populated or derived from other values in the application. Attributes can also be controlled with security, allowing controls on the properties to be used across the application.

Integration Capabilities

Another core capability of DRM is the ability to obtain and broker data in an organization. DRM provides functionality for importing from source systems as well as exporting to subscribing systems. DRM serves as a platform-agnostic hub in the organization, allowing for the import and export from any system.

Populating Hierarchies in DRM

There are a couple of ways to populate hierarchies in DRM. The first way is to utilize import functionality, which can accept either a file or a database connection as input. Once the hierarchy is loaded into DRM, it can be blended with the existing hierarchy to bring the DRM hierarchy in synchronization with the source system. The second method is to use the action script module, which has a specific format and allows bulk changes. Both processes are executed in an automated fashion using batch scripts or directly in the DRM Web Client. Additionally, many organizations impart a change data capture (CDC) process in a relational database when loading to DRM, where only changes are loaded into the application (to obtain performance benefits). The import and change data capture process are described in more detail in Chapter 6 of the book.

Exporting from DRM

DRM provides the ability to export to any system in a variety of detail and formats. Standard and commonly used exports allow for the target to be a staging database or text file, but the DRM software also contains web services integration along with some native integration with the Oracle General Ledger and Oracle Enterprise Performance Management Architect (EPMA).

Standard Export Methods

The standard methods for exporting dimensional data from DRM are used to generate content to text files as well as Oracle and MS SQL Server relational databases. Exporting from DRM provides one of the most useful features of the product: allowing businesses to drive application content based on business definitions and use attributes and targeted exports to generate content for the downstream systems. More specifically, most subscribing systems only contain parts of the business data element structure of interest. In some cases, these structures are part of a larger structure and adding that entire structure to the application results in extra maintenance and may potentially have a negative impact on performance. In these specific circumstances, DRM shines with its export functionality. The DRM application can generate the specific needs for each application based on the requirements of the subscribing system while maintaining the entire structure of the business.

In specific cases, many large businesses maintain multiple financial systems and these systems may require different levels of granularity within the accounts dimension. For example, the planning and budgeting system may require that data is inputted and reported upon at the natural account level, while a consolidation system may only require the parents of the natural accounts level of detail. This scenario is depicted in the diagram below.

Balance Sheet Hierarchy Subscription Example

Balance Sheet Hierarchy Subscription Example

 

Web Services, Oracle GL, Oracle Hyperion Enterprise Performance Management Architect (EPMA) Integration

While there are significant benefits to using standard exporting functionality, additional integration points exist. The most advanced integration point is the use of web services to query the application and integrate DRM with other external applications and Oracle products. DRM also integrates with the Oracle General Ledger of Oracle e-Business suite and the Oracle Hyperion Enterprise Performance Management Architect commonly referred to as EPMA. These three approaches provide additional levels of integration for the application. The method to leverage each approach is defined in a separate document in the Oracle EPM documentation library under Oracle Data Relationship Management. Detailed explanations of these capabilities are outside the scope of this publication as the goal is to provide knowledge to create custom DRM integrations for any downstream system that may be encountered. While native DRM to EPMA and Oracle GL integration are not inclusive of all Oracle applications, there is an expectation that additional Oracle products will integrate with DRM as the solution progresses and additional use cases are defined.

Versioning Capabilities

Versioning is one of the most important and heavily used features of DRM, where the creation of multiple versions of the same hierarchy are created, modelled and utilized. The versioning capability allows users to setup what-if scenarios, model future reorganizations or new fiscal year changes, and support mergers and acquisitions. The export features of the product require the specification of both the version and the hierarchy, allowing for the export of different versions of a hierarchy for use with subscribing systems.

Security Capabilities

Security is a major concern in the management of enterprise data. The management of data inside an organization can involve a complicated split of roles and responsibilities. The DRM product provides a very robust security model, allowing for security to be applied at any level of the hierarchy or data element in the software. Security is tailored to business requirements through the configuration of groups and property categories, which determine the level of access (read-only or write) that each user has for specific hierarchies and nodes. Additionally, roles are assigned to each user to identify the user as an Administrative user, Interactive user or Workflow user.

Audit Capabilities

DRM helps organizations maintain compliance with Sarbanes-Oxley and other financial regulations by providing detailed audit information. DRM maintains a detailed audit log in the relational database repository which contains information on all of the changes applied to data in the application. The audit data is easily queried through the audit interface in the DRM application. The audit interface is very detailed, providing the opportunity to search on a number of criteria and obtain detail on the changes performed.

Workflow Capabilities

The ability to create workflow inside the product exists through the procurement of the Oracle Data Relationship Governance (DRG) module. While the ability to integrate with Oracle’s SOA suite and Oracle BPEL exists in the current architecture, the Oracle DRG package provides the ability to easily configure workflows for a lower total cost of ownership approach to managing the governance aspects of master data with custom integration.

Benefits of DRM Implementation

DRM provides significant benefits to a business especially in the areas of organization and efficiency. While most organizations have managed without a formal MDM solution, most attempt to tackle these solutions with custom approaches in silos. In addition to the more obvious benefits, DRM also provides the ability to perform calculations and derivations as well as methods that handle accuracy and control over data elements in the organization. The following sections provide a summary of the common benefits of a DRM implementation.

Single Source, Efficiency, and Organization

The most commonly achieved benefits are through the creation of a single source of master data. The orchestration of data into the system for central management through a set of import approaches provides a means to consistently manage content throughout the solution. The flexibility to organize and manage business hierarchies with the capability to export portions of hierarchies to subscribing systems provides the efficiency and consistency required to effectively manage and share data elements in an organization. These features, coupled with the audit and reporting features of the solution, provide the benefits needed for successful MDM.

Derived Business Logic

The ability to automatically base properties in the application on logic is a major benefit of DRM. Creating these derived properties is highly powerful, saving business users time by removing the need to manually maintain properties that are derivations from other data in the organization or DRM itself. These derivations also apply to an inheritance feature, allowing property derivations to be inherited from the hierarchy structure itself. An example of inheritance is the configuration of an Account Type property within a hierarchy containing a chart of accounts. In the example, a user could set the Account Type property to Expense for a specific member in the Income Statement hierarchy. The Account Type property could be configured so that all child account nodes of the parent would inherit the Expense value from the parent assignment.

Cleanliness and Control

Within the DRM application, the ability to configure the application to implement business rules that validate each dimension member exists. These business rules can be completed through the use of properties or validations, which provide powerful capabilities for keeping the master data solution clean and accurate. An example is the management of restrictions to a hierarchy of a chart of accounts. In this example, there is an interest to restrict account nodes in the hierarchy that start with specific characters, such as AC. A property can be created to evaluate the validity of the node by setting a True or False value to determine if the node is structured correctly in the hierarchy. DRM also provides the ability to create validations and reports on the derived element to report on the accuracy of data stored in the application. Validations may be placed directly on the creation of the node in the application or run in batches, ensuring data elements match rules.

Another feature of DRM is the ability to control the structures in the application. DRM contains a robust security model, which may be defined at all levels in the hierarchy and to specific roles and objects. Additionally, the Oracle DRG package provides the out-of-the-box workflow and governance capabilities for managing the governance of master data in an organization. The security and governance features of the application provide the necessary controls for the successful management of data in the application.

Use Cases for DRM

The most common use for DRM is the management of financial hierarchies that are sent downstream to different Business Intelligence or Enterprise Performance Management Applications, including Hyperion Planning, Hyperion Financial Management, Hyperion Profitability and Cost Management as well as stand-alone Essbase applications. A growing trend (now that the DRG module is in place) is to utilize DRM as the Enterprise Resource Planning (ERP) General Ledger (GL) segment authoring tool and subsequently integrate GL Segments and hierarchies with e-Business Suite or PeopleSoft. In addition to these use cases, DRM may also be used in other facets throughout an organization to manage content. The following sections highlight common use cases of Oracle DRM software in an enterprise.

Master Data Management

The challenges of managing master data across an organization require software to facilitate the management of data elements, hierarchies, and data attributes. The primary focus and use case for DRM is the management of master data across the enterprise. With the ability to manage business hierarchies, import and broker content, manage versions, and facilitate governance, DRM provides all of the features necessary for managing the master data of an organization.

Hierarchical Solutions

While DRM is primarily identified as an MDM product, the DRM solution is focused around the structuring of content in a hierarchical fashion. As such, DRM can be used as a system to build and manage areas of the business. Examples include the management of assets, a portfolio of investments, or employee reporting structures. While some of this content can also be seen as master data, DRM can be used to store numerical values in the properties values of the nodes, allowing for numerical attributes such as the square footage of a store to be generated after export.

EPM Dimension Management

Since DRM started as a major feature of the EPM product suite, it is no surprise that DRM relates well to the management of dimensions inside the EPM product. DRM is commonly used in organizations for specifically managing business hierarchies, especially when multiple systems are consolidated into a single structure. DRM provides a great solution for facilitating user interactions with hierarchies in the EPM solution as well as for managing and injecting custom members into a standard structure for budgeting and forecasting activities. While direct integration exists through the Enterprise Performance Management Architect product, environments usually focus on using custom exporting into a relational source and then importing into EPM applications. Since DRM is an open development platform, it does not contain all of the constraints necessary for each EPM application. However, the use of validations enforces the restrictions necessary for building required EPM application constraints into the designed model.

System Migrations

Migrating from one system to another may require the transition of data elements from an old system format to the format required by the new system. The restructuring of content along with data mappings, changes to node formatting, and the refactoring of attributes can be easily handled in DRM, especially when business users are required to perform input and make organizational changes in the migration.

Workflow & Approvals

With the Oracle DRG software package, the ability to configure approval workflows with data elements exists for use in the DRM solution. Functionality allows DRM to be used as a workflow approval product for changes to a hierarchy, nodes, or properties based on a pre-defined workflow model. This capability makes the implementation of relatively simple workflows for data elements much more feasible than the previous architecture that required BPEL and Oracle SOA Suite. Examples include staffing models, investments, and risk management requirements.

Summary

The goal of the first chapter of this book was to provide an overview of the Oracle DRM software product, features, terminology, solutions, and benefits. The chapter opened with an introduction into Master Data Management (MDM) and the first section outlined a framework for the different levels of organizational MDM maturity that are observed in MDM initiatives. This section was followed by a discussion on the relationship between master data initiatives and data governance, and the Oracle DRG solution was introduced with the purpose of facilitating the governance of master data inside the DRM product.

Oracle’s DRM software was detailed at length with an introduction into the capabilities of the software product, including data management, hierarchy, and integration, versioning, audit, and workflow capabilities. An overview of the architecture of the solution and specific terminology was introduced, providing the technical knowledge necessary for the rest of the book. The chapter transitioned into use cases for the DRM software product, including both common and unique approaches to using DRM in an organization. The chapter concluded with an overview of the benefits a DRM solution can bring to an organization.

The first chapter set the stage for the book and introduced the product. Later chapters walk through the steps of an implementation and dive into the specific functionality of each section of the product, demonstrating best practices and techniques used by experts. Let’s get started!

Oracle Data Relationship Management BookShow Me The Book

Leave a Reply