With the release of Oracle Hyperion Enterprise Performance Management (EPM) 184.108.40.206, the Financial Data Quality Management (FDM) toolset got a much needed overhaul. This tool has been popular with administrators and users of the Hyperion Financial Management (HFM) application software since it was known as Upstream. And as its capabilities expanded (and after it was renamed FDM), it has been a leading solution to cleanse and load data to Hyperion applications such as Hyperion Planning, HFM or Essbase due to its strong mapping and drill back capabilities. With the introduction of ERP Integrator (ERPi), this tool was given the capability to connect to a wide range of source systems like Oracle E-Business Suite (EBS), SAP BW or PeopleSoft.
However, FDM has always been restricted to a 32-bit Windows architecture, which limited scalability and throughput (the rate at which it could process data). With applications getting larger, and data refresh rates getting more and more into the realm of real-time availability, this was proving to be a significant bottleneck.
Enter FDM Enterprise Edition (FDMEE). Bringing all of FDM’s core functionality into the same J2EE platform that ERPi runs on, it also integrates Oracle Data Integrator (ODI) into on toolset. In previous versions, FDM, ERPI and ODI needed to be separately installed, configured and maintained, which made the solution more complicated to set up, not to mention enhance and maintenance. With the single 64-bit platform independent J2EE platform, the tool is scalable and much easier to install with the rest of the Oracle EPM system. This also makes it easy to update via patches applied with Oracle’s OPatch tool.
What’s more, FDMEE comes with full Life Cycle Management (LCM) support that it so much easier to build the solution once and then migrate it to Production or Disaster Recovery (DR) environments. Previously, the most commonly used approach was to recreate the solution in Production or DR environments.
So then what’s not to like? For new implementations, not much, and everything will be created fresh. For migrations from existing FDM solutions, VBA-based and VBScript-based custom scripting and adapter enhancements will need to be translated into the newer scripting tools that are Java-based. It is not a huge hurdle, as a large talent pool is available for Java based scripting tools like Jython. It is just something that needs to be kept in mind and planned for when considering the move from FDM to FDMEE. Also, a lot of the custom scripting for mapping will be reduced, now that FDMEE supports multi-dimension mapping (previously this necessitated getting creative with the “Import Formats” and a whole lot of VBScript-based custom scripts). Less code will lead to a more robust solution that can be maintained and extended by less technically-gifted personnel, like Finance managers who have a better understanding of the data.
With promised capabilities like integration with Oracle Data Relationship Management’s (DRM’s) Data Governance module, or the ability to source data from EPM applications, there are many good things on the horizon with this tool. All this makes this a great time to move to this tool. Just make sure to plan, to allow sufficient time to do it right, and to take advantage of the pluses that FDMEE can bring to your solution.
Author: Andy Tauro, Performance Architects