> Hi Dan,
> I received the Arbor White paper on the role of a MD DBMS
> in an overall data warehouse approach, and have a follow up
> The Enterprise Decision Support Architecture diagram depicts
> the planning and analysis activities going on at the desktop
> updating the Essbase DBMS. This would support the need for
> iterative 'what if' analysis for updating projections. However,
> there may also be a business need to take the final results of
> the 'what if' analysis and feed these final projections back
> into related operational systems and the enterprise data
> warehouse. In this situation the MD DBMS is not simply a
> DSS tool, but is functioning as a source of operational data.
> I didn't see anything in the White Paper addressing this issue.
> Do you have any comments or recommendations ?? Are companies
> using Essbase in this way ??
> Thanks, Joyce
This is a great note. I agree with you, and in fact when I present
the data warehouse architecture I show arrows representing moving data into
the OLAP data mart from the relational warehouse, and then back out
of the data mart back into the warehouse.
A real customer example that comes to mind is a budgeting application I
saw. I am thinking about the way a large bank uses Essbase for planning
and analysis applications.
They download their actual results from mainframe financials into
Essbase. Then they use Essbase calculation scripts to perform cost
allocations and other financial manipulations on the actuals to
generate suggested budgets.
Budget templates are then distributed to something like 3000 cost
center managers. These cost center managers then go through an iterative
budgeting cycle - that is they update their budgets, check in the numbers,
look at the effects their numbers have on their division, etc. The
budgeting cycle proceeds until the corporate budget process is completed
and then the corporate budget is consolidated and frozen.
The final step in the process is that the consolidated budget is exported
out of Essbase back into the data warehouse for distribution and historical
storage. The entire company has access to the data warehouse, not
everyone has access to Essbase. Also, the data warehouse is the
historical data store, not Essbase. If you would like to talk with the
people doing this let me know.
From a more technical point of view, it is my feeling that our customers
have not yet, to my knowledge, seen a need for synchronous replication of
changes made in their OLAP applications back into the relational source.
They have, however, seen the need for asynchronous or snapshot
replication. This tends to be infrequent and at the end of a planning or
budgeting cycle, so I think of the need as being temporally rather than
Does this explanation fit with how you are thinking about using OLAP ?
Daniel Druker Daniel Druker
14190 Wild Plum Lane Strategic Alliances
Los Altos Hills, CA, 94022 Arbor Software Corporation
Sunnyvale, CA, 94089
(408) 727-5800 x4027