An Essbase Support Model

(also from the archives - circa 1998)

i've seen a bit, being out and about in the field.

Here are some of the things I think would be crucial to an ongoing Essbase support function. In no particular order of importance.

1. Centralized account authority. Someone who centrally issues accounts and monitors activity on all servers. This should be someone separate from those who gives access to the individual cubes and filters within.
   
   
2. A high level person who maintains an ongoing dialog with DW / and or legacy systems folks. Sooner or later there is going to be some conflict over the best way to deliver end-user applications. You need to get ahead of this process and negotiate the efficiencies of OLAP access vs relational access for all users. Right now we are at the beginning of the OLAP application development period. Just because it's Finapps now doesn't mean its not Call Center Apps tomorrow.
   
   
3. Also metadata planning and repository stuff should also be a primary function of this liason with data production staffs. You need to insure that all data production issues are related to the OLAP staff. If your company is just moving to client/server, NT or ERP this is especially important. Know where the data is coming from at an enterprise level, and be on the cc: list for changes to dataflow.
   
   
4. A Business Systems Analyst should have some Essbase experience, or at least have a good idea of what kind of systems could be built in the OLAP area. Get someone who knows where all the analytical bones are buried.
   
   
5. A centralized liason to Arbor. This is the person whom should track all calls to tech support, be aware of maintenance, license and patch issues. Should be in touch with Arbor regarding seminars, Dimensions, product introductios, enhancements, 3rd parties, OEM vendors and other Essbase users in your industry and geography.
   
   
6. Get a high priced OLAP DBA and guarantee job security. Pay your own employees now, or pay $100/hr consultants who don't know your business later. I guarantee you it will become an issue within one year of your first implementation. Not because Essbase is not a Porsche, you just don't want your Porsche wrapped around a tree.
   
   
7. Leverage Essbase training (formal or informal) with every group you do business with. If you create an app with the Inventory folks, overtrain one of the power users.
   
   
8. Create cross-functional decision teams for each project. Gut a business guy who could care less about technology but is focussed on the bottom line. Get a technophobic nudge who cares about fonts, colors, ease of use, and how many 'clicks' they have to do. Get a power user who wants to do everything and revolutionize the whole company. Get a hotshot developer who keeps saying 'yeah we can do that'. Get an old-head skeptic from IS who won't be convinced even after the system is built. Get used to the dynamic of balancing all these demands and be determined to build a first-rate system that will last for at least 3 years.

Roll out functionality quick, get feedback from the nudge. Get the business guy's chalktalk and use his terms - show that the system logically follows his idea of how the business is supposed to be run. Get a clear idea from hotshot how fast she can deliver new code. Listen for the skeptic's warnings and prove him wrong. Show him why.

Deliver chunks of success which please coaltions of these folks, get *them* to roll it out to the end users. Take all blame, share all credit.

Next time you ask to create a functional team, you'll see a kindergarten forest of raised hands.

--

Now. A seasoned Essbase DBA (somebody who has taken all the courses and built and maintained at least 2 cubes), should be able to recognize potential OLAP apps everyware. Such a person should not be afraid of tuning, and should be able, independently to handle anything technical that Arbor tech support recommends. You should get all your Excel macro jockeys, Access programmers, Foxpro pros, and SQL Server folks prepared to report into that DBA. They should be responsible for being able to know and represent business rules in the Essbase paradigm. To understand the cycle of (Build, Load, Calc, Report ) Anybody who is prepared to call themselves an NT expert should learn something about Essbase, because Essbase is what makes NT valuable, not the other way around.

Such a DBA, in a non-distributed environment, should be able to handle all the cubes needed. If you are going to use distributed OLAP and go cross-platform then you'll need two, in my opinion - especially if you build an NT&UNIX multi-partition application.

However in any case, that DBA should be able to understand, once explained, the business rules and businss model of any cube, but they should not be responsible for generating specs for that and maintaining all that. So I am suggesting that your main Essbase DBA be more of a data architect not a specialist in Finapps or Inventory or Manufacturing. That way you can leverage the NT specialists (macro jockeys, VB programmers) interests in familiarity with Essbase the same way they would be of SQL understanding thats where the more serious enterprise-wide/mission critical planning apps are built.

So if you could have a DBA who is capable of describing Essbase comprehensively to a VB guy who understands with the aid of a Business Analyst all the reporting, analysis, modelling, and planning needs for a particular department - then you have the basic team of 3 which can build a first rate app. Then you leverage the interests of the VB/front end programmer and the Analysts in Essbase knowledge, and you can do well.

If you have a more formal project planning culture and require a project leader and gantt charts and all that, then you should have two *real* programmers on the team. Again, Essbase is not idiot proof. Yes, you can go 60 mph in first gear in a Porsche...