FDMEE – What’s Next
For those of you that have read my blog (or the one for FDM Classic) for a long time, you may know that I used to be a Hyperion Administrator for a large Medical Device Manufacturer – Boston Scientific. Their slogan during the time I spent there was: Delivering What’s Next. I just spent time with Oracle FDMEE Product Management and Development this past week. I want to share with you some exciting roadmap items about what Oracle is intending to deliver next. As a side note, I search for a Boston Scientific image with the Delivering What’s Next tagline but alas I couldn’t find anything with fair usage rights so work with me folks; Amazon’s Prime Air drones, delivery; get it? It works right?
Oracle Safe Harbor
“The following is intended to outline out general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in Oracle’s products remains at the sole discretion of Oracle.”
Translation: Everything I share below is subject to change. This includes the timing as well as the functionality ever actually making its way to the product. Do not rely on this information to make purchasing or project decisions. Ok, now that we have that out of the way, let’s get to the fun stuff.
This Changes Everything
The biggest near term change (post 220.127.116.11.200) coming to FDMEE is the ability of the application to process and load textual information. Wait a second Tony, FDMEE already processes and loads textual information in each of the dimensions. Yes, you are correct but now FDMEE will be able to load textual based information as “data.” This means that FDMEE will be able to load Smart Lists and other textual based information to the Planning repository. This is a significant change and one that addresses a weakness of the product that Essbase and Planning gurus have often “noted.”
This change means that FDMEE will no longer be able to only interact with the Essbase repository of a Planning application and instead will give you the option to interact with the Planning repository through the Planning API or directly with the Essbase repository using the existing functionality. The Planning API opens up a world of integration possibilities; think Outline Load Utility capabilities. Awesome right? Well I certainly think it is.
Moreover, FDMEE will now be able to natively process data files that have multiple data columns. Consider a common Essbase format – a series of measures/accounts across the columns and a single row for each “set” of data. In FDMEE, this meant needing to pivot the data prior to importing the data file. In the future, FDMEE will simply (and intelligently in some cases) read the data columns and populate multiple data records in FDMEE as well as a select dimension which can also be driven from the column headers. This is a fantastic feature that will make FDMEE able to handle even more file formats – and not just limited to Essbase & Planning integrations.
So the naysayers (you know who you are) will likely immediately say: FDMEE is already slower than load rules, adding in the overhead of the Planning API is only going to slow things down. And to be honest, that was my immediate thought and question to Oracle. But alas, they have some pretty smart people out there in Redwood Shores and they already thought of that. The load of data to Planning will have a switch that allows data (including textual information) to be loaded using the Planning API or use the legacy Essbase load method when loading only numeric data.
Additionally, there is discussion of a “direct load” capability where all of the FDMEE mapping & audit features are essentially bypassed and data will simply be passed through the FDMEE repository and to the target application which would likely Essbase or Planning. This additional feature will bring more data load performance parity relative to legacy methods like Essbase load rules. All of these enhancements are really opening up a world of opportunity in FDMEE – specifically for Planning and Essbase integrations – that previously did not exist. Existing times for this application.
I Want It Now
So if you are excited as I am about these new features, the next logical question is: when is this coming to an application near me? Well, that’s not entirely certain. We saw the framework of the textual data load in a development environment in the first week of May. It is scheduled for the Cloud 16.07 release which is July(ish) with a subsequent rollout to on-premise FDMEE in a PSU (.210 or .300) and the timing is “after PBCS.” So what does that mean in everyday speak, it means Cloud first. This is not a surprise especially with the focus of Oracle on growing the Cloud capabilities. That said, Oracle realizes how much of a differentiator Hybrid (a.k.a. on-Prem integrating with Cloud apps) FDMEE is and the functionality should follow the on-prem deployments soon after the Cloud release if I were a betting man.
Some Other Fun Features
Along with the significant features noted above, FDMEE roadmap includes the following features:
- PBCS Cloud to Cloud data movement (16.06; soon)
- Integration with additional Oracle Cloud Services including inter-cloud data movement
- Updated UI
- Enhanced Fusion G/L integration
- Limited Scripting with Groovy (in PBCS FDMEE)
- JSON support
These are just a few of the additional features (possibly) coming to FDMEE. Stay tuned for updates as they become available.