Very Computer

I am very interested in your feedback.

Was the white paper helpful / not helpful ?
Was it too technical / not technical enough ?
Do you agree with the concepts it discusses ?
Do you have any requests for additional / related information ?

Thanks,

- Dan

Home:                                           Office:
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

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

     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
designated
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
transactionally triggered.

Does this explanation fit with how you are thinking about using OLAP ?

- Dan

Home:                                           Office:
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