KScope14 200 GB Diet


Published on

Mike Malandra, Ranzal lead consultant, presented the 200 GB Diet, or “How I archived off the first 10 years of my application!” at KScope14, about archiving data in Oracle Hyperion Financial Management (HFM).

Published in: Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

KScope14 200 GB Diet

  1. 1. The 200 GB diet or “how I archived off the first 10 years of my application!” Michael Malandra
  2. 2. Focus Services People Methodology Customers Partnership 15 Years 700+ clients 1000+ projects About Edgewater Ranzal
  3. 3. We offer a full spectrum of EPM/BI Services Dashboards & Scorecards, Financial Analytics & Reporting, Operational Analytics, What-if Analysis, Query & Reporting, Visual Exploration Financial performance, Legal, Segment & Mgmt Reporting, Financial Close HFM Optimization, Performance Lab SOX Compliance Support Strategic Finance, Planning, Budgeting, Forecasting, Workforce Planning, Capital Planning, Project Financial Planning Data Integration, Financial Data Management, Data Warehousing, Master Data Management &DRM, ETL Services, Automation Project/Program Mgmt, EPM Road Maps, Application Reviews, Business Requirements, Process Change, Documentation Installation, Upgrades, Migration, System Monitoring, Backup and Recovery, Disaster Recovery, Load Testing, Hardware Sizing, Exalytics Benchmarking Consolidation Business Intelligence Enterprise Planning Infrastructure Training & Support Services Project Management Data Services Costing & Profitability Mgmt Support Services – Infrastructure & Application Support Contracts Key Teach Course Delivery: Planning, Essbase, Financial Reporting, Smart View, HPCM, HFM, FDM, DRM, OBIEE Custom Training Delivery: Process & Reporting HPCM Standard & Detailed Models, Waterfall Allocations, Activity Based Costing, Customer, Product & LOB Profitability
  4. 4. To Archive or Not Archive?
  5. 5. On Average Applications: that are 2-3 years old can average 10GB to 15GB 25GB to 50GB are also common 100GB to 300GB are rare 500GB and 1TB are mythical… Too much of a good thing…
  6. 6. Determine the current DB/schema size Every Scenario/Year has its own table 1 GB = 1024 MB = 1,073,741,824 Bytes Data Analysis
  7. 7. A large application doesn’t inherently mean “slow” Remember - DB and application performance are independent ● but DB performance can influence app… Application performance is a function of data usage ● And rules. And application tier hardware. Before you begin
  8. 8. There is no “Archive Data” feature! Can HFM do this automatically? It’s D.I.Y. But How?But How?
  9. 9. Define “Archive” ● Need to access the historical data ● Reduce the data set going forward Create a second read only “historical” application Keep only required scenarios ● Actual, Actual at Budget rates, Actual at Forecast rates The patient must minister to himself…
  10. 10. Answer 2 Questions: 1. Will I go to jail if I delete this data? 2. Could I be fired if I delete this data? Risk Assessment or Let’s kill all the lawyers…
  11. 11. Case Study: Codename VentiCase Study: Codename Venti 114GB of data in non-essential scenarios 46.5% of the database
  12. 12. What’s Done is Done… Historical application will only contain data that was reported Much smaller application that will not expand
  13. 13. Tomorrow, and Tomorrow, and… To restrict the expansion of the new application, institute policies that will limit size Keep Forecasts only 2 years Other scenarios will be used as needed then the data will be dropped after 12 months
  14. 14. Good Riddance… Old application was 245GB New Applications are 83GB A reduction of 161GB or 66% Institute policies to prevent growth for non-essential scenarios
  15. 15. Saying goodbye to old data, now what? Upgrading?? ● If yes, then leverage converted Application for data validation and create 2 new apps ● If not, can the environment handle another application? Benefits of new applications – no junk! ● Invalid records and unnecessary data! ● Keeping only relevant data (smaller applications) Parting is such sweet sorrow…
  16. 16. Two choices: ● Old data in new structure ● Old data in a static structure A lean and hungry look… Don’t overthink history!
  17. 17. Application Type: Classic or EPMA? If EPMA when? ● Start project in EPMA ● or convert later? Synchronize Applications
  18. 18. Beginning balances? ● Do your customs have adjustment members? ● Will your rules work with a new start year? Historical Data? ● Journals or not? <ECT> can be loaded to <EC> ● Load in local currency, not in Parent Currency Questions to Consider?
  19. 19. One rule file or two? ● One rule file is easier to maintain but the current file will need to be updated ● Leverage Hs.ApplicationName() sAppName = HS.ApplicationName() If sAppName = “NewApp” Then Do something… Else Do something else… Rules
  20. 20. Does the rule file have a start year variable? ● If yes, create a condition in which the variable has two options sAppName = HS.ApplicationName() If sAppName = “NewApp” Then nStartYear = “2008” Else nStartYear = “1998” ● In not, add an empty year to the beginning of the application…nStartYear -1 Rules, cont.
  21. 21. Multiple Year KPIs ● Will cause some overlap in years between applications Cash flow ● Load entire TB in stub period (12/2009) Rules, final thoughts…
  22. 22. Who sees the History? Making the App Read Only ● Make Scenario security classes Read only ● Security Class access is most restrictive to least restrictive Users will see the stub year ● Years do not have security ● Over communicate this during Training and Testing Security
  23. 23. Smart View ● New application connections are needed ● Communicate via Training and Testing Financial Reports ● Can only connect to one application ● Only certain reports access the Historical app Reporting
  24. 24. Data Validation ● What level of detail needs to be validated? ● Tools to use? FDM? Excel? ● Responsibility? ● Data validation can derail your project if not properly defined! Something wicked this way comes…
  25. 25. Migration Process ● 2 Applications now ● Lifecycle Management: now moves data!!! ● Data retention policy ● Responsibility? Finance vs. IT ● Define clearly, please? Brave New World…
  26. 26. Reduced DB Created a process to limit DB growth Kept History Final Thoughts or Dancing Days…
  27. 27. Michael Malandra mmalandra@ranzal.com Pittsburgh, PA USA +1.724.759.8572 www.ranzal.com