Hyperion Planning

DRM Administrator: Day in the Life

Ladd Moravek

The purpose of this article is to provide a window into a mature, real-world Oracle Data Relationship Management (aka. DRM) environment and the reoccurring administrative tasks involved in keeping this powerful metadata management tool working for the business users that rely on it.  The company is a large multinational financial services firm (privacy concerns prevent us from revealing specific, identifying company information), and the Oracle DRM application is an enterprise-wide solution for all downstream reporting and planning solutions used by the company’s CFO organization.

Oracle’s GL module is the primary source system for both data and metadata.  Some of the company’s smaller international subsidiaries use non-conforming, indigenous, non-Oracle GL systems.  DRM is used as a central metadata hub for all downstream reporting and planning solutions including Hyperion Financial Management, Essbase and Hyperion Planning.  Multiple dimensions, like accounts and entities, are organized into one or more hierarchies and are managed month to month by versions that contain the changes to metadata made in a given period.  The CFO organization relies on “data stewards” to manage and manually update key reporting dimensions through their respective DRM hierarchies.  The dimensions critical to both management reporting and statutory reporting managed by the “data stewards” include account, entity, and reason codes.

Note:  Oracle Data Relationship Governance can be used to automate many data governance activities, but after a review, it was determined that this tool was not an appropriate fit for this environment.   

The following sections summarize the reoccurring administrative activities required to meet the needs of the business.

Version Management

According to Oracle’s DRM User Guide, “Data Relationship Management organizes sets of related data into versions. A version is a single, independent set of data that can represent a period of time or a business scenario. Data within each version is categorized into hierarchies, nodes, and properties.”  For our company, version management is part of the monthly financial close since each version represents a given month-year combination.  The DRM administrator is responsible for managing the workflow for each version and for staging the version for the new month.

 The workflow for a version is controlled in DRM by its status, which is controlled by the application administrator.  The following are the standard version status settings:

• Working - Users can make changes to hierarchies (within the constraints of their assigned security privileges).
• Submitted - Only administrators can make changes to the version. Approved ’Change Request Forms’ must be submitted by the data stewards to initiate any changes. A version is set to ‘Submitted’ on work day minus one of a given close.
• Finalized – The version is locked down. No one has the ability to edit the version.
• Expired – This status is used to archive a version.  No one has the ability to edit the version.

At the end of each monthly financial close cycle, the current version is locked down (set to ‘Finalized’), and a new version is created and made available for use by the data stewards by making a copy of the current month, naming it based on the next month-year combination and saving the newly created version.

Note: Per Oracle’s DRM User Guide, If a version is not saved, then it remains “detached from the database and changes are made in memory only and will be lost if the application is stopped.”

In addition, the system preference settings for both ‘DefaultCurrentVersion’ and ‘DefaultPreviousVersion’ are updated to reflect the new values for the current month’s and previous month’s versions.  These two preferences are frequently used with DRM exports, which rely on their values to automatically determine which version should be used by a given export (see Automation section below).

Automation of Inbound and Outbound Updates

Two automated processes are used with DRM in this environment to import and export data. Both of these automated processes are actively monitored by the DRM administrators to ensure and verify accurate completion.  Also, the DRM administrators are required to make periodic updates to both the automated import (Inbound) and export (Outbound) processes (for example, creating a new export definition).

The DRM Inbound Interface utilizes imports, blenders, and action scripts:

• Imports – Used to import data from external sources (Oracle GL and Non-Oracle GL sources). In general, imports “are always performed on new, empty versions created as part of the import process”. This version is temporary and is merged with the current default version using a blender.
• Blenders – Used to “combine elements of two different versions into the same version”. After the blender is run the temporary version created by the import is deleted, leaving the updated current default version. 
• Action Scripts - Used to automate bulk changes with each record in the script representing a single action. The final step in the Inbound Interface uses an action script to update all the properties for new and changed member nodes in the default current version.

The DRM Outbound Interface utilized multiple exports, which update SQL tables or generate flat text files depending on the destination application.  For example, HFM and FDM are updated using a SQL staging table that is populated when a set of DRM exports are run.

User-defined Properties

According to Oracle’s DRM Administrator’s Guide, “Property definitions are used to manage the attributes of versions, hierarchies, and nodes in Data Relationship Management. Properties can store a variety of different data types including text, numeric, date, and references to other data objects. Properties can store explicit values, use inheritance to automatically assign values to descendant nodes, or be calculated based on a formula or lookup table . . . User-defined property definitions can be created by application administrators to manage additional attributes that are necessary to support business or system integration requirements.”

User-defined properties are heavily used in this instance of DRM to seed the metadata of multiple down-stream applications including FDM, HFM, Essbase and Hyperion Planning.  Administrators are often tasked with updating existing properties or creating new properties for new or existing down-stream applications based on end-user needs and requirements.  The following are examples of user-defined properties:

• HFM Security Class – This property mirrors the security classes created in HFM.  It is assigned to nodes in the hierarchies that contain entity structures.
• Account ICP Override Map – Used to control intercompany relationships between account nodes in HFM.
• FDM Location – Used to enable security in FDM by location
• BSO Formula – Contains the formulas for dynamic outline members for BSO Essbase cubes and Planning applications.

Security

For all Hyperion applications in our Company’s enterprise performance management environment, existing and new users are managed by a separate enterprise wide systems security group.  The DRM administrators mange the security infrastructure within DRM, specifically, the node access groups.  Node access groups determine the access that users have to limb and leaf level nodes and their respective properties.  If DRM access for a user or group of users needs to be adjusted, that can handled by modifying the node access groups assigned to the user or users, or it can be handled by modifying the node access groups assigned to a particular node of section of a hierarchy.  Alternatively, a new node access group can be created, depending on the situation.  Consideration needs to be given to node access level and ‘leaf vs. limb’ access.

The following Node Access Levels control the type of access a user has (per Oracle’s DRM Administrator’s Guide):

• Read - Enables read-only access; no changes permitted
• Limited Insert - Enables insertion of a node for which the user has (at least) global insert privilege.
• Edit - Enables property values to be edited
• Insert - Enables nodes to be inserted, moved, or, removed
• Inactive* -  Enables nodes to be inactivated and reactivated
• Add - Enables nodes to be added or deleted

* Not used with this company’s instance

Leaf access determines what actions can be done to ‘Leaf’ nodes, and limb access determines what actions can be done to ‘Limb’ nodes.  For example, from a specific node in DRM, a user might have ‘Add’ permissions to any leaf nodes, but only ‘Read’ permission to any of the limb nodes.  In this case, the user can only add or edit a leaf node but only view any corresponding limb nodes.

Validations

Validations are user-defined (in this case administrator defined) business rules that can be enforced against various application elements, primarily against property values in this specific instance.  Validations can in be manually run in a batch as needed, or they can be a real-time business rule that prevents DRM users from making mistakes as they are performing actions.

This company’s validations are primarily designed to prevent metadata issues in downstream applications and batch validations are regularly monitored by both data stewards and application administrators.  Some of these issues include invalid characters, names or descriptions that are too long, incorrect member settings/values, and to ensure that critical properties are not ‘null’.

Batch validations are designed to return a listing of any members that violate the validation’s business rules.  This makes it easier for data stewards and application administrators to ensure that the current version is “clean” for the DRM Outbound to run successfully.

Conclusion

DRM is a powerful relationship management tool that enables users to maintain and update metadata.  Regular administrative activities are required to ensure the application continues to meet users’ needs.  The preceding discussion covers the reoccurring administrative tasks for a specific environment and is not intended to be an exhaustive list. 

E-mail: info@thebean.co