EPMA or Classic Planning for Metadata in 11.1.2.4?
With the 11.1.2.4 release, Oracle has made significant improvements to Hyperion Planning. These range from form and task list changes to complete interface overhaul (Planning Simplified Interface). One of the biggest changes over the past few versions is how metadata is handled within Classic Planning applications. With so many changes it is worth revisiting an old topic, should I be using EPMA or Classic Planning administration for my metadata?
The last time I did this evaluation was in version 11.1.2.2, and I found many reasons to use EPMA in that version. If clients wanted to automate metadata loads, or share dimensions between applications, it was the best (and in most cases only) option. It was also the easiest to use administratively. Building dimensions was far easier in EPMA than in Classic Planning. In the following post I will re-evaluate these advantages EPMA had and provide some insight on when and where it should be used in the latest version.
Automation
Automation of metadata loads is important for companies. When processes run in the middle of the night, it greatly reduces user down time. It also reduces manual maintenance needed in the application. This is one of the big reasons I have recommended EPMA in the past. However, starting with the 11.1.2.2.300 patch, Classic Planning has been gaining ground. With that patch, it allowed the outline load utility to connect directly to a relational database, something that previously could only have been done with EPMA. Now in the 11.1.2.4 version, they have gone as far as building a scheduler within the application. Administrators can now schedule metadata builds within the planning console itself. This is only available is the application is built as a Classic Planning application. This option does not exist for EPMA. In this category, I think Classic Planning has overtaken EPMA.
(click to enlarge)
Administrative Ease
Manually creating dimensions has always been simple in EPMA. All the settings were displayed on the right, and with the grid spreader it was easy to make large scale changes across an entire dimension. On the opposite side of that, Classic Planning administration has always been sort of a hassle. Expanding the hierarchy to find members was rather cumbersome, and to change a setting you would have to open an entirely new window. Large dimensional changes within the application could take hours in Classic Planning but only seconds in EPMA. That changed significantly in 11.1.2.3. With this version, Oracle introduced the Smart View Planning Admin Console. Now it became possible to perform mass updates on dimensions from Smart View. The console is easy to use and with the Excel front end, it feels very similar to an average Essbase query. They also enable simple exports and imports of metadata with the 11.1.2.3 version. While creating a quick application is likely still easier in EPMA, I think dimensional administration is now easier with Classic Planning.
(click to enlarge)
Shared Dimensions
This has always been EPMA’s main advantage is that you can easily share dimensions between applications. If you have ever truly shared dimensions you know that maintenance is drastically simplified by having one dimension as opposed to many copies of the same one. This is still not available in Classic Planning, but in the current version it would be much easier to replicate something similar. You could now create the dimension in one application, export to a common location, and import that dimension into all other applications. That still requires more setup and process than sharing a dimension in EPMA. Because there is no out of the box option to share dimensions in Classic Planning, EPMA is still your best option for sharing dimensions.
(click to enlarge)
Data Movement to HFM from Planning/Essbase
Another advantage of EPMA in the past has been the ability to move data between Essbase or Planning applications and HFM via the Data Synchronizer. While there have always been alternative options besides EPMA, with the most recent version those other options have become easier than ever. One of the best options I have seen for this is using FDMEE to move data from Essbase/Planning to HFM. This can now be accomplished straight from the workspace and is very simple to setup if you have experience with FDMEE. ODI and EAL are two additional and viable options for data movement between environments. With all these options for data movement across platforms – I would say this is a toss-up. Even if I was already using EPMA, there are situations where I would choose other technologies over the Data Synchronizer.
Conclusion
Oracle has invested a lot of its resources into improving Classic Planning over the last few versions and it is paying off. In most new environments, I would choose Classic Planning over EPMA. However, there are still reasons to go with EPMA. Sharing dimensions is still only possible through EPMA and not through Classic Planning. There are also some small issues with dimensional replacements (as opposed to merges) in Classic Planning that have not been resolved by Oracle yet, such as user variables and planning data being deleted. That does require either a work around or a notice to users to avoid that functionality. For existing environments, the cost to change from one to the other may not be worth it if the current environment is meeting the current needs. The message is simply that it if you are upgrading, then you should be asking the question of Classic or EPMA again.
Free eBook Download
In the eBook “Having a Conversation with Data”, learn what the current BI infrastructure has been and associated challenges with the traditional approach. How important the user experience is in order to best maximize data’s value (think visualizations!!) to your organization and how to gain a competitive advantage with modern analytics platforms.
