"How do I make use of new FDMEE functionality?"
"What is the risk factor?"
"Does FDMEE stay true to its FDM roots?"
All questions commonly expressed and ones that I will do my best to address in a two part blog piece. Part 1 will cover the various changes, similarities, core functionalities around FDM, and what to consider before upgrading to FDMEE. I will talk more around the migration piece in Part 2; "Take Time and Review Your Design: FDMEE Migration Advice."
Starting with release 18.104.22.168, Oracle Financial Data Quality Management (FDM) and Hyperion Financial Data Quality Management ERP Integration Adapter for Oracle Applications (ERPi), are combined into a single product; Financial Data Quality Management, Enterprise Edition (FDMEE).
Change Means Options
Some of the note-able changes from the traditional FDM product include:
- Target adaptors are integrated
- The need to download adaptors no longer exists (unlike with previous versions)
- Most of the functionality that was hidden within the adaptors is now in ‘plain view’ as part of the rules
- Provides audit trail functionality
- Functionality will source financial data through direct connection (and sourcing from the ledgers)
Staying Close to Home
But true to its FDM roots, it still provides leading functionality:
- Helps to ensure data integrity and mapping consistency, allowing easy reconciliation of financial data
- Helps users with data error investigation, identification and correction
- Provides flexibility to meet all levels of complexity in your integration
With the release of Oracle Hyperion Enterprise Performance Management (EPM) 22.214.171.124, the Financial Data Quality Management (FDM) toolset received a much needed remodel. This tool has been popular with administrators and users of the Hyperion Financial Management (HFM) application software since it was known as Upstream (after the capabilities expanded, it was renamed FDM).
Now 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, limiting 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 one 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, enhance and provide 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 thru patches applied with Oracle’s OPatch tool.
What’s more, FDMEE comes with full Life Cycle Management (LCM) support. Now it is far 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, everything will be created fresh. 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 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.
Reasons to upgrade to FDMEE
- Classic FDM has some limitations that are now covered by FDMEE. For example, when multi-dimensional mappings were needed, most of the people used mapping scripts which don't perform so well. In FDMEE, we have a new mapping type called Multi-Dimensional mapping. This new mapping type will probably replace all your mapping scripts. In addition, you can use look-up dimensions in FDMEE to support your multi-dimensional mappings.
- The more locations you have, the more you will have to maintain. With new data load rules you may simplify your location structure. Two locations for two different file types may be replaced by one location and two data load rules having each one import format.
- Import process is almost always the bottle neck in Classic FDM. Mapping process is performed during the import process and 90% of the customers having performance issues during import follow this rule: Wrong mapping logic design -> poor performance during import (I have seen source files with 1000 rows taking more than 30 minutes...) It's a perfect chance to review your mapping logic in order to get the best performance.
- You will have to re-write your scripts (import, mapping, event, and custom). Even if you keep VB for event and custom scripts, you will have to do some changes as VB Script is replaced by VB .NET. On the other hand, if you decide to use event and custom scripts in Jython...you will have to completely re-write them. Import scripts (dump) support Jython only. Integration scripts are not supported anymore as import scripts so they need to be implemented in BefImport event script (Jython or VB .NET). And lastly, VB mapping scripts are not supported anymore so you will have to re-write them as Jython or SQL mapping scripts (or replace by multi-dimensional mappings). That being said, you will have a great opportunity to review your code which sometimes is not as efficient as you think. Also, if you forgot commenting your code, don't forget to do it now :-)
Need to learn more about the functionality and conversation around FDMEE?
Check out Part 2 of my blog; "Take Time and Review Your Design: FDMEE Migration Advice."