Request a Consultation

CheckPoint Consulting Blog

Though normally used primarily for management of financial master data, Oracle's Data Relationship Manager may be able to help your organizations technical documentation strategy. The software’s ability to: import data from sources systems; supplement and augment that data; govern such updates; and export the data, makes it a perfect tool to be your central repository for technical documentation across your organization.

The aim of documentation should be two-fold. First, it should act as a reference for technical aspects of the system (i.e. a reference for methods, fields, data dictionaries, etc.) However, it should also foster a pragmatic fundamental understanding how systems work. Organizations struggle achieving either of these aims. There are numerous reasons for this, but here are a few:

  • Documentation is spread across the organization on individual machines, network folders, SharePoint sites, shared drives, wiki pages, etc.
  • Systems change but documentation rarely gets updated
  • The individuals that have the most insight into the big picture often do not have the time to create adequate documentation

To create a useful documentation system, we need to (1) centralize it and (2) make it more efficient to create and maintain. This is where DRM can help us.

Software systems and modules often store their “configuration” data in relational databases or structured files (often xml). With a little work, such data sources can be brought in to DRM in a hierarchy view. As soon as the configuration data is in DRM, these configuration objects are easily navigable in DRM’s friendly user interface. This feature alone allows clear visualization of how these data systems are constructed. Additionally, such configuration data serves as a good baseline for documentation to build on top of.



This may be difficult to conceptualize at this point and, to fully explain this system, something more than a blog post is likely required. However, the above example may shed some light on how this system would work. Illustrated above is an example of connecting to EPMA and bringing in the properties from an Essbase application. As soon as the properties exist as members in DRM, the purpose and other relevant information about the properties can be documented. As soon as the hierarchy of configuration objects is built, properties can be added to track things like: functional ownership, technical ownership, purpose, etc. Further, a supplemental tool (a wiki page, for instance) can be used to provide even more detail. DRM can integrate with such a tool to provide color to the object. (shown below)



Additionally, any changes to source systems requiring a documentation update can be automatically captured and a DRG workflow can be automatically kicked off to prompt a user to update the documentation. The above system makes it more efficient for the people with knowledge of the system to explain the importance of each cog and gear of the system, it forces documentation to be updated when systems change, and it centralizes all of the organization’s documentation in one location.