For organizations working with streamlining their master data management processes, data governance is the best way to add process, validation logic, and organizational approval to uphold data standards.
In Oracle’s DRM product, Data Relationship Governance (DRG) was released in the 188.8.131.52.500 version of the product to allow organizations to define these processes on top of their existing master data management hub.
Enterprise Data Management Cloud Service (EDMCS), is Oracle’s new MDM cloud product, has its own flavor of data governance baked into the application itself.
Today I will compare the features and functionality of these applications, and then deep dive into specifics of each tool. Please keep in mind that EDMCS is brand new!
Compare and Contrast Governance: EDMCS vs. DRG – Current State
Considering EDMCS is a brand-new product (and still in the “early adopter” phase) the built-in governance into the process shows much promise. Expansion still needs to be done in order to be on par with the features available in classic DRG; but so far, the rails are put in place to get there. Below is a table of features available in each product at this time (as of January 2, 2018):
|Feature||EDMCS Requests||DRG Workflow Requests|
|Built In/Required for all hierarchy data imported into the system||Yes||No|
|Can be submitted manually by a user||Yes||Yes|
|Can be submitted in bulk via a file||Yes||Yes|
|Has enrichment steps?||No*||Yes|
|Is expandable to have many steps for organizations with difficult processes?||No*||Yes|
|Validates data on basic logic before commitment to repository||Yes||Yes|
|Validates data before commitment to repository based on customized business rules||No*||Yes|
|Allows user commentary?||Yes||Yes|
|Allows upload of supporting documents?||No*||Yes|
|Allows for notifications either in-app or by email?||No*||Yes|
No* – Will hopefully be features that will come with age to the product
Deep Dive: EDMCS Requests
EDMCS allows Data Manager users to create nodes in contexts for the use of downstream applications. The data model for EDMCS, varies greatly from the DRM model, however the fundamentals of getting new master data and updates into the system are the same: either by manual updates from a user or from an uploaded file.
Every time a change is submitted to EDMCS, either by a user or by a file upload, a request is generated. The request are generated initially in a “Draft” mode (similar to DRG drafts), and allows the users to visualize the changes in their views prior to committing them.
This is one fundamental difference between DRG and EDMCS: visualization before changes are committed.
Depending on the type of change that has been submitted, EDMCS shows an icon next to the change in the view of the hierarchy or list. This is a visual cue showing how the change would affect the hierarchy, and thus the downstream application – in this example I’ve added 101002, Test CC, to the hierarchy. It is NOT committed to the hierarchy; but it is highlighted in green and has a icon on the left (the plus in a circle) notating that it is a new node, which is requested to be added. Once the request is committed it will be in the hierarchy:
Actions that are allowed in EDMCS [which produce Requests] include:
- Adding a node
- Removing a node
- Deleting a node
- Updating node properties
- Inserting a node
- Moving a node
- Reordering nodes
- Adding a Top Node
- Selecting a Top Node
This is how each of these actions will be visualized before being committed:
After creating a draft Request in EDMCS, you can also load comments about the request. There is an icon in the browser which allows you to create the comment for others to review at a later time. If you bulk upload requests via the file upload feature, the file will also become an artifact to the Requests and available for review at a later time.
Finally, Requests are validated before submission. This occurs inherently before submission to forbid any issues being committed, or can also be validated by the user. Currently, there are simple “out of the box” validations that are in place (no duplicating members, invalid characters, etc.) but eventually custom validations should become available.
One thing to note, is that although EDMCS governance process is currently in place for all users at all times, there is currently no Enrichment or Approval type steps available in the governance process. Users can only Draft Requests, Submit Requests, Review Request Drafts/Submissions, or Delete Drafts. Once a Request is submitted, the changes are committed to EDMCS and an additional request would need to be drafted and submitted to revert a change to the hierarchy or list. I do expect for this to be expanded in the future, and Requests would have approval or enrichment stages depending on the views updated or the type of users submitting the requests.
Deep Dive: DRG Workflow Models
Like I said earlier, classic DRM did not have a built-in governance model until 184.108.40.206.500, when DRG was introduced. Some organizations leveraged the DRM API to make custom workflow applications that sent data back to DRM, or did offline approval processes before things could be entered by a data steward.
DRG now allows for the configuration of guided workflows for users to submit data to DRM. DRG works on a series of Tasks + NAG Security = Stages. Also, there is no limit for the number of Stages that can be configured.
DRG Workflow Models are required to have at least 2 Stages: Submit and Commit. This means that a provisioned user has to submit a request via a task, and that the change be committed to DRM. They must be in this order, and Submit must occur first and Commit must occur last in the workflow. In a way, this is similar to the EDMCS basic Request model – there is a submission and then the change is committed.
DRG, however, allows for expansion past these two Stages. Enrich and Approve stages are also available to be added to the process, and as many of them can be added as necessary.
For example, say a task in a submit step would be for a user to update properties that are pertinent to Hyperion Planning; and then maybe there is another task for another user to update properties for FCCS; these can be generated into two Enrich Stages into the current process, which would generate the following stages: Submit, Enrich, Enrich, and Commit.
Taking it further, after all property updates, perhaps a general EPM administrator must approve the change before it should flow through to downstream applications; an Approval Stage can be added – creating a workflow model with the following Stages: Submit, Enrich, Enrich, Approve, and Commit.
Actions that are allowed in DRG Workflow Tasks include:
- Add Node (Leaf & Limb)
- Remove Node from Hierarchy
- Delete Node from DRM
- Move a node
- Update Node properties
- Insert Nodes into a hierarchy
- Inactive a node
DRG allows for the workflows to be configured with as many tasks as possible to be completed, as allows for split-requests, separation of duties, and requiring multiple NAGs to fulfill a stage.
HB’s Summary: EDMCS Requests vs. DRG Workflows
I hope you enjoyed this comparison of EDMCS vs. DRM/DRG for data governance capabilities. Obviously, because EDMCS is such a new product it has some ways to go in terms of customization to business processes; but it is clear that the rails are there for Oracle to expand its capabilities. Probably my favorite thing about EDMCS so far, is that requests are visual to the user before they are committed to a hierarchy – which will make things so much easier for training & user adoption.