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. 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. 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. There is no “Archive Data” feature!
Can HFM do this automatically?
It’s D.I.Y.
But How?But How?
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. 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. Case Study: Codename VentiCase Study: Codename Venti
114GB of data in non-essential scenarios
46.5% of the database
12. What’s Done is Done…
Historical application will only contain data
that was reported
Much smaller application that will not expand
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. 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. 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. Two choices:
● Old data in new structure
● Old data in a static structure
A lean and hungry look…
Don’t overthink
history!
17. Application Type: Classic or EPMA?
If EPMA when?
● Start project in EPMA
● or convert later?
Synchronize Applications
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. 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. 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. 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. 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. 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. 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. Migration Process
● 2 Applications now
● Lifecycle
Management: now
moves data!!!
● Data retention
policy
● Responsibility?
Finance vs. IT
● Define clearly,
please?
Brave New World…
26. Reduced DB
Created a process to limit DB growth
Kept History
Final Thoughts or Dancing Days…
