Introduction
As more organizations begin to embrace the Oracle software as a service (SaaS) of Enterprise Performance Management (EPM) Cloud offerings, there is an often overlooked but important decision that needs to be made early in the adoption cycle - what toolset will be used to integrate data into the EPM Cloud Service products such as Planning and Budgeting Cloud Service (PBCS), Financial Close and Consolidation Cloud Service (FCCS), or Profitability and Cost Management Cloud Service (PCMCS).
Herein we are going to explore the two primary data integration options that are available to customers and the pros and cons of each. The conclusion provides a recommendation that can be applied to organizations of all industries and sizes as they plan their journey into the Cloud.
The Encounter
Oracle continues to grow its Cloud service offerings both in terms of customer volume and functionality. The changing landscape of software and infrastructure has facilitated a number of organizations to adopt a cloud strategy for one or more business processes. We cannot refute the aids of the Cloud, as due to this software is regularly improved, the hardware is possessed and preserved by Oracle, and application upgrades are shown as a historical thing. While the shift to the Cloud is a broad topic with many considerations, herein our focus is the data integration toolset, and more broadly, the integration strategy.
When customers shift to Cloud, they are repeatedly educated that the Cloud service contains a section named Cloud Data Management which can address all of the data integration requirements for the Cloud service. Honestly, this is an overly optimistic view of the capabilities of Cloud Data Management. Data integration requirements can drive solutions that range from very simple to incredibly complex, and this large spectrum demands a more holistic assessment of the integration options. It is impracticable to assess the thorough solution necessities in a software sales cycle, the important query that every organization should have when bearing in mind their data integration plan for EPM Cloud Services is - what are my options?
Cloud Service Data Integration Options
As with any software offering, there are numerous potential solutions to a given requirement. While assessing software choices, options are normally gathered into two classes - buy versus build. A 'buy' choice is acquiring a packaged software offering. The Oracle EPM Cloud Services are an instance of a buy decision. In addition to prebuilt functionality, an important advantage of a packaged subscription is maintenance for the solution including future version releases. A build resolution means making a routine solution which is explicit to a single association. The last one is usually unsubstantiated by a software merchant, and range of capabilities and advancement are both subject to the skillset of the individual or team that developed the solution.
Herein we focus on embalmed resolutions as those are more thoroughly line up with the often-expressed goal of adopting a Cloud approach that is streamlining the solution and its possession. The choices such as ODI or the rest API are all valid, these are considered build options in the build versus buy decision and thereby are excluded from this analysis.
Considering packaged submissions for integration with Oracle EPM Cloud Services, the two main options available to customers are FDMEE and Data Management. FDMEE is a separate on-premises solution whereas Data Management is a combined component within each of the Oracle EPM Cloud Services. Before comparing these products, it is necessary to highlight the purpose and capabilities of each.
FDMEE
Financial Data Quality Management, Enterprise Edition (FDMEE) is a purpose-built application for integrating data into the Oracle EPM suite of products. This solicitation comprises predefined reasoning for loading data to the on-premises EPM applications of HFM, ARM, Hyperion Planning, and Essbase. Additionally, FDMEE (as of the 11.1.2.4.210 release) can integrate data directly to the EPM Cloud Services of FCCS, PBCS, PCMCS, and Enterprise Planning and Budgeting Cloud Service (EPBCS).
FDMEE as an ETL: Financial Data Quality Management Enterprise Edition can lightly be mentioned as an ETL-type application. The ETL is incorporation procedure for extracting, transforming and loading data. FDMEE is not a true ETL tool because it is not intended to handle the extremely large volumes of data (millions of records in a single execution). For handling large volumes of data, a pure ETL tool such as Informatica or ODI would theoretically be a better fit. Financial Data Quality Management Enterprise Edition offers many core functionalities as ETL tools. It has the capability to extract data from a diversity of sources, transform the data to the EPM dimensionality, and load the resultant data to EPM applications.
FDMEE is different than pure ETL because FDMEE was designed keeping business user in mind. ETL solutions are generally owned and operated by the IT department. ETL executions are scheduled, and any deviation from the defined process or timeline often requires coordination between the business user requesting the off-cycle execution and the IT owner of the ETL solution. The Financial Data Quality Management Enterprise Edition is regularly managed and preserved by business users. The FDMEE operators have the capability to apprise alteration reasoning through a web interface with tiny to no coding awareness required. Users can schedule FDMEE jobs or execute them in an ad-hoc fashion as data is needed. The end-to-end process is completely within the hands of the business users.
FDMEE adaptors: The Financial Data Quality Management Enterprise Edition offers strong and authoritative extract abilities comprising prebuilt adaptors to source data from Oracle EBS GL, PeopleSoft GL, HANA, J.D. Edwards Enterprise One GL, SAP GL, HCM and Business Warehouse. All these adaptors offer the reasoning and coding required to source data and remove the need for organizations to define and maintain custom extract queries. This is a significant value-add of FDMEE. Additionally, Financial Data Quality Management Enterprise Edition can source data from any relational source as well as any flat file format. These three methods, 'prebuilt connecters, relational association, and flat files' guarantee that Financial Data Quality Management Enterprise Edition is capable to utilize closely any data source required to support the EPM systems to which it is intended to load data.
Data Conversion in FDMEE: The conversion proficiencies, which is identified as mapping are another main aspect for FDMEE. Often the transformation that occurs during a standard ETL process is accomplished through SQL queries that must be designed from scratch. FDMEE uses SQL to execute conversion in the background, the mapping logic is input in a web interface that looks and feels very much like an Excel worksheet. Source system values are aligned to target system values in a columnar grid format. Financial Data Quality Management Enterprise Edition maps provision multiple mapping methods including Explicit (One to One), Between (continuous range mapping to a single value), In (non-continuous range mapping to a single value), Like, and multi-dimensional maps where numerous source system sections are used to find an EPM target dimension value.
Data Loading in FDMEE: FDMEE further differentiates itself from standard ETL solutions in its load processes. Load procedure is resolution-built for incorporation into the Oracle EPM product suite. Not only does this ensure a seamless load of data to the target EPM application, but also it comprises prebuilt logic that improves the data load process. For example, without any additional build effort, Financial Data Quality Management Enterprise Edition can perform calculations in the target EPM application to perform tasks such as currency translation, data clearing or aggregation. While standard ETL tools can certainly achieve this, Financial Data Quality Management Enterprise Edition offers this proficiency natively and needs no further build effort outside of organizing the integration to perform these actions.
FDMEE Value- Add Landscapes
Audit Controls in FDMEE: Because FDMEE stores its transformation logic within the application, users are able to investigate the data conversion that was applied, to better recognize how a source system data point was converted to a target system intersection. FDMEE has the capability to track changes to the renovation logic. FDMEE can track who the was the user and when he or she altered the transformation logic. FDMEE application tracks the conversion logic before and after the change so the effect of the change is understood. Finally, FDMEE provides a tremendous amount of activity-based logging. FDMEE application captures each accomplishment of the ETL (the Workflow) process and captures thorough information such as the user performing the process, start and end times, and in-depth technical actions that allow for not only debugging but also for performance and process tracking. Over and over again internal or external auditors enquire for proof to support, that the data in a reporting application is latest, precise, and comprehensive. As the data is regularly transmuted throughout an ETL process, the preconfigured Financial Data Quality Management Enterprise Edition reports and user interface capabilities can be used to easily validate the transformation effect. As well, a number of reports are available to audit the overall process execution -when it was run and by whom. These powerful tools can be used to demonstrate the rationality of data inside the EPM application.
Drill options in FDMEE: Financial Data Quality Management Enterprise Edition provides functionality known as drill back and drill through.
Drill back is the action of moving from the EPM application to the FDMEE application to investigate the source records that make up the balance from which the drill back was initiated. Drill back is native to any EPM system to which FDMEE loaded data. The main requirement to this functionality is that the drill back should definitely be originated from an input level intersection to which data was loaded. It specifies that drill back cannot occur from parent levels within any of the hierarchies. This is undoubtedly a zone where the community would like to see Financial Data Quality Management Enterprise Edition drill back developed. Appropriate training of the process of drill down and then drill back can regularly overcome this apparent limitation.
Drill through, by contrast to drill back, is not native to each source system from which FDMEE can extract data. Drill through is provided natively with the preconfigured adaptors to the Oracle branded GLs as well as SAP R3 and ECC. For non-Oracle or non-SAP data sources, the drill through is dependent on the capabilities of the source system. Financial Data Quality Management Enterprise Edition drives a drill through request in the form of a 'http' request. The ability to drill through to the source system is thereby depends on the source system having a handler for the web request. Any system that can accept the web request could in-theory be configured to support drill through from FDMEE.
Cloud Data Management
Cloud Data Management is intended to allow an organization to adopt a pure Cloud solution for Oracle EPM deployments. Cloud Data Management is a module within the Oracle EPM Cloud Services. It is built using the same code line as on-premises FDMEE. Cloud Data Management can integrate flat files. It includes all the on premises FDMEE transformation capabilities including SQL mapping which can accommodate complex transformations. It includes the prebuilt logic to natively load data to each of the Oracle EPM Cloud Service offerings. Cloud Data Management can integrate with other Oracle Cloud Service offerings including the ability to source data from and load data back to Fusion G/L Cloud. As well, it can source data from other Oracle EPM Cloud Services.
Variance between FDMEE and Cloud Data Management
While the main transformation and load capabilities of FDMEE are available within Data Management, some of the key features of an on-premises deployment of FDMEE have been disabled.
The below shown table highlights the accessibility of FDMEE features in Cloud Data Management:
| Topics | FDMEE | Cloud Data Management |
Pre-built connection to Oracle branded ledgers | Yes | No |
Pre-built connection to SAP ERP and DW | Yes | No |
Direct connection to relational data sources | Yes | No |
Data Synchronization( Hybrid Mode) | Yes | No |
Import, Custom and Event Scripting | Yes | No |
Custom Reports | Yes | No |
Flat File Processing | Yes | Yes |
Pre-built connection to Oracle Fusion GL | Yes | Yes |
Mapping | Yes | Yes |
Multi-Period Processing | Yes | Yes |
Data Synchronization( Full Cloud Mode) | Yes | Yes |
Automation | Yes | Yes |
Drill Through | Yes | Yes |
A key feature that is not available in Cloud Data Management is the ability to connect to on-premises systems. This applies to both the systems for which Oracle has created adaptors as well as those that require additional application configuration. For example, if an organization is utilizing Oracle E-Business Suite (EBS) or SAP General Ledger, Cloud Data Management is not able to connect to either of those systems. To assimilate data from on-premises systems to the Oracle Cloud Service products such as EPBCS or FCCS using Cloud Data Management, a process needs to be developed to transfer a flat file to the Cloud instance and then invoke a Cloud Data Management process. While this is certainly achievable using Oracle's EPM Automate command line utility, many organizations prefer to avoid flat file integrations when possible.
Role of EPM Automate: Cloud Data Management is most often used in conjunction with a light weight on-premises command line utility known as EPM Automate. At a minimum, EPM Automate is required to transfer data files to the Cloud Service instance in which Cloud Data Management is deployed; however, multiple EPM Automate commands can be threaded together to create a lights-out end-to-end process for data integration. A data integration task flow may contain the following steps:
1. Login to the Oracle EPM Cloud Service instance
2. Upload a data file
3. Initialize a Cloud Data Management routine to process the data file
4. Execute calculations in the EPM Cloud Service product (e.g. EPBCS)
5. Execute a Financial Reports (FR) report in the EPM Cloud Service
6. Download the report output to an on-premises location
7. Log out of the Oracle EPM Cloud Service instance
8. Generate and send an email with the FR report attached
EPM Automate helps Cloud Data Management function as a somewhat more fully integrated solution for the Oracle EPM Cloud Services. The utility EPM Automate is not limited to Cloud Data Management; it can and often is used in on-premises FDMEE deployments as well.
Further Comparisons:
Scripting: Another feature of FDMEE that is not available in Cloud Data Management is the ability to use scripting. Scripting allows the FDMEE application to be extended beyond the standard out-of-the-box features. Scripting enables us to achieve common functions like connecting to a relational repository and extracting data or generating email status messages for lights out data processes. The scripting language that is used by FDMEE is either Visual Basic or Jython. Both of these languages have the ability to interact with the operating system, including that of the FDMEE application server. This creates a significant risk in a Cloud-based deployment. A malformed or malicious script could cripple an entire Cloud deployment. Because neither language has the ability to remove the specific functionality that is potentially harmful to the Cloud environment, Oracle has simply disabled all scripting ability for Cloud Data Management.
The inability to use scripting reduces the capabilities of Cloud Data Management. The criticality of data integration is generally a snubbed portion of an Oracle EPM project. Integrations can be complex as there are numerous systems from which data can be sourced in a variety of formats. While many systems can produce data files that can be easily consumed by Cloud Data Management, others produce files that require additional processing in order to be consumed. This is generally achieved through scripting. Since Cloud Data Management does not support scripting, any additional manipulation of a source system extract would need to be accomplished either by another application/process or through manual intervention. This is suboptimal and generally avoided by most organizations due to the added complexity or data risk. The scripting capabilities of FDMEE help to eliminate this risk.
Custom Reports: Another feature of on-premises FDMEE that is not available in Cloud Data Management is the ability to create custom reports. FDMEE and Cloud Data Management are one of the few products in the Oracle EPM stack that come with a number of preconfigured reports. These reports provide not only access to the financial data processed through FDMEE/Data Management but also to critical process and audit information including map modifications. While Oracle has done a remarkable job delivering reports with significant value-add, there are instances where the reports need enhancement. In other cases, where a new report is needed to address a specific requirement, unfortunately, Cloud Data Management does not provide the ability to change or author reports.
Delusions
Unfortunately, there is some level of misunderstanding or misinformation in the marketplace about the capabilities of FDMEE and Cloud Data Management. One of the biggest misconceptions about FDMEE and Cloud Data Management is regarding the drill through to source system capability. The common belief is that drill through to the source system is only available for data that was loaded through on-premises FDMEE using one of the source system adaptors for E-Business Suite (EBS), PeopleSoft, J.D. Edwards, or SAP.
This is 100% inappropriate on two fronts. First, the adaptors are used solely to extract data from the source system. The use of the adaptor is undeniably separate from the capability to drill through to a source system. Drill through to source systems is available for any system which supports a web request for data, even those from which FDMEE or Cloud Data Management has not sourced data. Second, and to some degree in concert with the first point, drill through is absolutely available from Cloud Data Management to on-premises systems even though Cloud Data Management does not support the use of source system adaptors to integrate data from on-premises systems. While there are certainly design and configuration requirements to support drill through from Cloud Data Management, it is available and supported by Oracle.
Cloud Drive Considerations for Multi-Product EPM Organizations
The inability of Cloud Data Management to connect to on-premises systems also applies to Oracle EPM applications such as Hyperion Financial Management (HFM) or Hyperion Planning. Many organizations are 'walking' their EPM landscape to the Cloud. In other words, for those organizations that have multiple Oracle EPM products currently in use, the acceptance of the Cloud is done in a stepped fashion. For example, an organization may transition their Hyperion Planning deployment to EPBCS before transitioning their HFM application to FCCS. Many organizations have been comfortable adopting PBCS while choosing to wait for FCCS to continue maturing.
Another reason organization takes a stepped approach to the Cloud is that transitioning both financial close and planning processes at the same time creates risk. This risk can manifest itself in any of the three project levers:
Choice: The idea of scope risk is that migrating multiple processes at the same time can be a long, complex project. While the mantra that the Cloud is faster and easier is often promoted, the reality is that a project in the Cloud can have just as many complexities as an on-premises deployment. Moreover, the prebuilt value-add content of the Cloud services can often mean an adjustment to the existing business processes used in the Oracle EPM applications.
Timeline: Moving multiple processes to the Cloud simultaneously definitely adds timeline risk. Moving a single process like Financial Planning allows an organization's resources to stay focused on a single project work stream. Often the key team members within an organization that are involved in an EPM project tend to overlap, at least in some fashion, even for processes as distinct as financial close and financial planning. Undertaking a project to move multiple processes to the Cloud concurrently requires these resources to spread their efforts across more than one work stream. This can lengthen the overall project timeline and add risk that project milestones are missed due to resource constraints.
Budget: Transitioning multiple processes to the Cloud concurrently can be more expensive than a multi-phased transition. One might argue that the costs should at least be equivalent or even less with a project that migrates multiple streams concurrently. The argument for lower overall cost would be attributable to the idea that certain project tasks such as testing and migration would benefit from concurrency and only needing to be performed once as opposed to across multiple projects. However, as noted above in relation to timeline risk, projects that migrate multiple business processes to the Cloud generally leverage more external resources (consultants) due to the nature of internal resource constraints.
As an outcome of these risks, establishments often find it advantageous to separate, the move to the Cloud into multiple projects that do not run in parallel. This means that an organization will be operating in a hybrid mode - a mix of on-premises and Cloud applications. Often, there is a need to exchange data between the close solution and the financial planning solution. Cloud Data Management enables the exchange of data between Oracle EPM Cloud Services (e.g., FCCS à EPBCS); however, it does not provide native functionality to achieve this data exchange in a hybrid mode. By contrast, on-premises FDMEE natively provides the ability to exchange data between on-premises Oracle EPM systems and Oracle EPM Cloud Service products. While processes can certainly be created to allow the exchange of data between on-premises EPM systems and EPM Cloud Service applications, it requires custom development that often requires in-depth knowledge of the application programming interface (API).
Judgment Aspects
For an organization facing the choice between on-premises FDMEE and Cloud Data Management, there are a variety of factors that contribute to the final decision.
Software Possession
First, an organization needs to determine if additional software needs to be procured. For organizations that currently have the Oracle EPM stack deployed on-premises, especially HFM, there is a high likelihood that FDM Classic (prior generation of FDMEE) is already owned. Any organization that has licensed FDM Classic is entitled to FDMEE without any additional licensing expense. FDMEE licensing is fairly straight forward. The software is licensed on a per user basis by specific functionality. Every organization that procures FDMEE needs to pay for the software itself. This portion of the licensing gets you the software but does not include any of the functionality to connect to source systems using the Oracle preconfigured adaptors or to the Oracle EPM products. Each of these things is licensed separately. In addition to the core software license, there are three licensing options in the FDMEE functionality tier:
1.HFM Adaptor: Provides the logic needed to natively integrate with HFM on-premises deployments
2. Adaptor Suite: Provides the logic for multiple integrations. First, includes all of the Oracle source system preconfigured adaptors (e-BS, PeopleSoft, J.D. Edwards E1). Second, includes the ability to integrate with on-premises Hyperion Planning and Essbase applications. Finally, the adaptor suite provides the ability to integrate from an on-premises FDMEE deployment to the Oracle EPM Cloud Service products that leverage an Essbase data repository i.e. PBCS, FCCS, & PCMCS. TRCS is also on the roadmap. While ARCS does not leverage an Essbase data repository, on-premises FDMEE utilizing scripting can integrate with it. The adaptor suite must be licensed to integrate with the Oracle EPM Cloud Services.
3. SAP Adaptor: Provides the ability to source data from SAP General Ledger (ECC or R3) as well as SAP Business Warehouse (BW). This source adaptor is licensed separately because Oracle needs to pay royalties to the partner (BristleCone) that developed and maintains the adaptor. The need to procure FDMEE can certainly be a restrictive especially for organizations that are attempting to adopt a pure Cloud model.
There are numerous factors that should be weighed before abandoning the idea of procuring on-premises FDMEE:
Figure of Cloud Services
Another important decision point in the choice between on-premises FDMEE and Cloud Data Management is the number of Oracle EPM Cloud Services to which data needs to be integrated. This concern is part of the overall EPM integration strategy for an organization. For organizations that have or anticipate having multiple Cloud services (e.g., PCMCS and PBCS), on-premises FDMEE is worth exploring. Integrations in Cloud Data Management are specific to the instance to which Data Management will load data. For example, if Cloud Data Management within the PBCS instance is used to load data to PBCS, that Cloud Data Management application cannot be used to load data to the PCMCS instance. A completely discrete Cloud Data Management application within the PCMCS instance would need to be created in order to load data to PCMCS.
An extra layer of complexity with Cloud Data Management is when data needs to move between instances; for example, loading actual consolidated results from FCCS to EPBCS. The Data Management application within the FCCS instance cannot push data to the EPBCS instance; data must be pulled from FCCS using the Cloud Data Management application within EPBCS. Conversely, if budget or forecast data needs to be loaded to FCCS, the pull of data from EPBCS would need to be initiated from the Cloud Data Management application within the FCCS instance. The need to exchange data between applications highlights a current shortcoming of Cloud Data Management. The user initiating the action must always evaluate from which instance the integration needs to be performed and log in appropriately. While this is not a show stopper, it is definitely a training issue and one that could be viewed as a suboptimal end user experience.
Lastly, it should be noted that the inability to share core metadata (including security) objects across Oracle EPM Cloud Service instances results in duplicative maintenance of those items across the multiple Cloud Data Management applications. On-premises FDMEE by contrast has the ability to connect to multiple Cloud instances as well as on-premises EPM environments from a single FDMEE application. This allows data to be loaded to and exchanged between applications using a single, common application. Since on-premises FDMEE is a single application, core application elements including security can be shared across different integrations.
Below are some questions that need to be considered when deciding between on-premises FDMEE and Cloud Data Management:
• Will my integrations need to be fully automated including email status alerts? If so, then on-premises FDMEE will be preferred.
• Are my data files in a consistent format? This means that I can import the raw data file into Excel and each field is populated consistently in each data row? If so, Cloud Data Management will very likely be able to process the file. If not, FDMEE scripting may be required to properly process the data.
• Does the organization expect the need for custom reports? This is hard to know with a high level of certainty. For large organizations that have vigorous audit requirements and users with highly specific reporting requests across other EPM products, it is likely that the ability to generate custom reports will be necessary, and on-premises FDMEE would be required. The majority (80%+) of organizations find the out-of-the-box FDMEE/Data Management reports to sufficiently address their needs.
True Cost of Ownership
To properly calculate the true cost of ownership of FDMEE or Cloud Data Management, we need to consider not only the financial expenditures but also the human capital expense associated with owning and maintaining a solution. Often Cloud Data Management is presented as having a lower total cost of ownership. From a financial expenditure perspective, this is very likely true.
First and foremost, Cloud Data Management does not introduce any incremental software cost. The Data Management module is included in the subscription price for the Oracle EPM Cloud Service instance. While the Cloud subscription is a recurring cost similar to annual maintenance, this cost will be paid regardless of the integration approach used, and as such, the initial software cost and on-going annual maintenance cost of on- premises FDMEE must be considered. Second, an on-premises FDMEE deployment requires additional hardware. This hardware can be physical or virtual. It can be within the data center of the organization, or it can be installed on hardware owned by an Infrastructure as a Service (IaaS) provider such as Oracle. Depending on the hardware deployment method (physical/virtual), there is capital expense and depreciation expense or operating expense that must be incurred.
Finally, the Total Cost of Ownership analysis often includes a discussion of the cost of future advancements which can be a somewhat flawed analysis. While the prior two components are certainly valid and factor into the upgrade discussion, the upgrade point is somewhat twisted. First, Oracle has stated that there will be one more major release to the on-premises software (version 11.2) that will be supported through December 2030. Any version of on-premises FDMEE that would integrate with the Oracle EPM Cloud Services would require the most current version which is 11.1.2.4. This means that there would only be one significant version upgrade of an on-premises FDMEE deployment. While patch set updates will be released at certain intervals, organizations can defer an upgrade or patch set update until a time that aligns with their needs and business processes.
Conversely, the Cloud is patched every month with new functionality being introduced. These updates do not always apply to the Data Management module, but when they do, a certain level of regression testing befits an organization to ensure the patch did not impact any functionality currently in use. Moreover, a full version upgrade of the Cloud has yet to occur. When such a major upgrade does occur in the EPM Cloud Services, an organization will certainly need to perform the same level of testing to the system as one would with an on-premises deployment. The core basis for challenging the cost of Cloud upgrades being lower is that the Cloud needs to be tested more frequently. Each time the Cloud is patched/updated, there is time required to evaluate if testing is needed and if so, to actually execute the test. An organization cannot defer the Cloud updates for more than one or two cycles and as such will consistently need to test. In contrast, an on-premises FDMEE application can be upgraded on a cycle defined by the organization. If no new functionality or bug fix is required, an upgrade can be delayed forever. As a result of the more frequent and mandatory testing cycles, the true cost of upgrades in the Cloud is higher because the administrators are more frequently undertaking testing activities.
Software and hardware costs are an important part of the TCO analysis; however, the analysis should also include the human cost. As previously noted, Cloud Data Management lacks certain features - direct connections to on-premises systems, automation email alerts, and the bi-directional hybrid or Oracle EPM Cloud Service data movement. The lack of these features often means more manual maintenance and workflow executions for administrators and end users. This erodes productivity and certainly has a cost associated with it. Moreover, the confusion of which Cloud Data Management application to use for data movement between the EPM Cloud Services can frustrate end users and administrators. This suboptimal experience can impact the perception and perceived value of the EPM Cloud Services and therefore should also be considered in the TCO analysis.
Logistic ETL Criteria
Some organizations have a distinct ETL standard that is usually a system such as Informatica or ODI. Prior to the arrival of the Cloud, these standards would sometimes not be applied to the Oracle EPM suite of products and, in particular, Hyperion Financial Management (HFM) since FDM Classic and later FDMEE were purpose-built to allow end users to integrate data to these systems. The on-demand need for data throughout a financial close cycle was often better served by FDM/FDMEE. With the introduction of the Oracle EPM Cloud Services, this decision must again be assessed particularly as it relates to maintaining on-premises software. The necessities that drove the use of FDM Classic or FDMEE - drill back, on-demand execution, end user maintenance of transformation logic (mapping) - are certainly still valid; however, the features that Cloud Data Management lacks may be improved by an existing ETL tool.
Consider this example: an organization needs to integrate data from an on-premises Oracle PeopleSoft general ledger to PBCS. One option would be to utilize on-premises FDMEE and its native connections to PeopleSoft to source and load the data to PBCS. Utilizing batch automation and scripting, an email status report would be generated. The process would be able to be initiated on-demand or scheduled to run at set intervals. But if the organization has not procured on-premises FDMEE licenses or is looking to abolish the licensing, then the ETL tool on which the organization is standardized may be used in concert with EPM Automate and Cloud Data Management to achieve an FDMEE-like integration.
A solution using the latter may look something like the following:
1. ETL tool executes a procedure to query data from PeopleSoft and generate a flat file.
2. ETL tool uploads the output to the Cloud Service instance using EPM Automate.
3. ETL tool initializes a Cloud Data Management workflow process using EPM Automate.
4. ETL tool executes a Cloud Data Management report to determine workflow status using EPM Automate.
5. ETL tool downloads the report output using EPM Automate.
6. ETL tool emails status report to required recipients.
The latter option is nearly on par with an on-premises deployment of FDMEE with a couple of cautions. First, the sourcing of data from PeopleSoft is provided as an out-of-the-box solution with FDMEE whereas in an ETL/Cloud Data Management approach, the extract query would need to be defined and maintained by the organization. Second, the level of detail that could be included in the email status generated by an ETL tool would not be as detailed or robust as an on-premises FDMEE solution. There are multiple reasons for this.
First, EPM Automate has limited return codes. The execution of a Cloud Data Management workflow process returns a success or a failure like most command line executions. However, success in this instance does not indicate that the workflow process completed without error; it simply means that the initialization of the workflow process was successful. As such, in order to determine the status of the workflow execution, a Cloud Data Management report needs to be run. Second, the workflow status report will provide workflow status, but it will not include detailed error information in the event of a failure in the workflow process. This information is housed in the Cloud Data Management relational repository, but reports to provide that information are not currently available, and as previously noted, custom reports cannot be created for Cloud Data Management. In contrast, an on-premises FDMEE deployment provides not only the ability to create custom reports but also access to the relational repository in which the detailed error information is contained. FDMEE scripting or custom reports can be used to provide this more detailed and actionable information to the appropriate users.
Data incorporation within the Oracle EPM Cloud Services is an extremely important topic. We explored the on-premises and Cloud-based options, including the features and functionality of both as well as important considerations such as the total cost of ownership. The last remaining question to answer is: which tool should my organization use? Unfortunately, there is not a singular answer to that question.
On-premises FDMEE functions as a data hub within the EPM environment. Data can flow to and from on-premises applications (ERPs, Data Warehouses, on-premises EPM systems) seamlessly to and from the Oracle EPM Cloud Services. Integrations can be fully automated and centralized to a single touch point. This functionality; however, comes at an additional cost to an organization. Conversely, Cloud Data Management has no additional software licensing costs or infrastructure overhead. That said, there is a human capital cost of ownership associated with the reduced features and functionality of Cloud Data Management.
Organizations with straight forward integration requirements - no automation alerting, consistent file formats, no integration to on-premises systems into a single Cloud service may find the 'built-in' nature of Cloud Data Management to be convincing. Organizations that have a multitude of integrations with varying degrees of complexity, a need to integrate from on-premises systems including Oracle EPM products, a need to restructure integrations through advanced automation, a need to integrate data into multiple Oracle EPM Cloud Services, or any combination of these factors, will certainly favor an on-premises deployment of FDMEE.
Any organization facing the decision of which integration toolset best addresses their needs should consider each of the factors highlighted above and weigh them against the financial and human costs of each potential solution.