The 200 GB dietor

“how I archived off thefirst 10 years of my application!”

Michael Malandra

FocusServicesPeopleMethodologyCustomersPartnership

15 Years700+ clients

1000+ projects

About Edgewater Ranzal

We offer a full spectrum of EPM/BI Services

Dashboards & Scorecards, Financial Analytics & Reporting, Operational Analytics, What-if Analysis, Query & Reporting, Visual

ExplorationFinancial performance, Legal,

Segment & Mgmt Reporting, Financial Close

HFM Optimization, Performance LabSOX Compliance Support

Strategic Finance, Planning, Budgeting, Forecasting, Workforce Planning, Capital Planning, Project Financial Planning

Data Integration, Financial DataManagement, 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

BusinessIntelligence

EnterprisePlanning

Infrastructure

Training &Support Services

ProjectManagement

DataServices

Costing & Profitability

Mgmt

Support Services – Infrastructure & Application Support Contracts

Key Teach Course Delivery: Planning, Essbase, Financial Reporting, Smart View, HPCM, HFM,

FDM, DRM, OBIEECustom Training Delivery: Process & Reporting

HPCM Standard & Detailed Models, Waterfall Allocations, Activity Based Costing, Customer, Product & LOB Profitability

To Archive or Not Archive?

On Average Applications:

� that are 2-3 years old can average 10GB to 15GB

� 25GB to 50GB are alsocommon

� 100GB to 300GB are rare

� 500GB and 1TB are mythical…

Too much of a good thing…

� Determine the current DB/schema size

� Every Scenario/Year has its own table

� 1 GB = 1024 MB = 1,073,741,824 Bytes

Data Analysis

� A large application doesn’t inherentlymean “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

There is no “Archive Data” feature!

Can HFM do this automatically?

It’s D.I.Y.

But How?But How?

� 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…

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…

Case Study: Codename VentiCase Study: Codename Venti

� 114GB of data in non-essential scenarios

� 46.5% of the database

What’s Done is Done…

� Historical application will only contain data that was reported

� Much smaller application that will not expand

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

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

� 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…

� Two choices:

●Old data in new structure

●Old data in a static structure

A lean and hungry look…

Don’t overthink history!

� Application Type: Classic or EPMA?

� If EPMA when?

● Start project in EPMA

● or convert later?

Synchronize Applications

� 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?

� 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

� 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.

� Multiple Year KPIs

● Will cause some overlap in years between applications

� Cash flow

● Load entire TB in stub period (12/2009)

Rules, final thoughts…

� 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

� 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

� 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…

� Migration Process● 2 Applications now

● Lifecycle Management: now moves data!!!

● Data retention policy

● Responsibility? Finance vs. IT

● Define clearly, please?

Brave New World…

� Reduced DB

� Created a process to limit DB growth

� Kept History

Final Thoughts or Dancing Days…

Michael Malandra mmalandra@ranzal.com

Pittsburgh, PAUSA

+1.724.759.8572www.ranzal.com