kscope14 200 gb diet
Post on 13-Sep-2014
171 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related