hyperion system 9 = enterprise essbase

The good old days of essbase, where you could install, configure, build, test, UAT and implement in 4-6 weeks are long gone with system 9.

The amount of involvement of IT for essbase implementations used to be limited to:

-acquiring a windows server
-provide a daily feed from the ledger
-backing up the server

All too many companies are currently operating under this assumption. It turns out that the backups are worthless 30% of the time anyway based on my experiences (don't forget to stop the service to backup essbase....)

So, while this is a bad situation, companies can get by and get their daily reporting completed.

Now, the new world order with System 9 is that things are much more complicated.

IT is going to have to be involved during the install. The architecture of System 9 essbase is much more complex. There are numerous services (~6-8) that must all be running for even 1 user to be able to log into essbase. The security now leverages the authentication provider of your company (ldap or active directory). This means that when an employee gets terminated they will no longer be able to get into hyperion systems automatically. This make the security auditors smile.

Backups, instead of an afterthought, are now a critical item on the task list. There are additional items that must be backed up correctly other then just the app folder. The penalty for non-compliance is not just losing the data in the cube, it's actually losing all security settings for the entire hyperion environment. This means that no one can log into anything hyperion, not even the excel addin. I've already heard a few stories about clients that didn't have their open ldap backed up and experienced an outtage. Security had to be rebuilt from scratch. This is no small feat given that now security for all hyperion products is managed from one console. So if you had 50 users all getting into essbase, analyzer, and reports you'd have quite a lot of work ahead of you. If you follow the recommended backup process then this should not be an issue but given that hyperion is typically a system that IT wants no part of, extra care should be taken to ensure that the backups are taken correctly and are in fact usable.

Dependencies on the startup of the numerous services. If the services get started in the wrong order no one will be able to log in. This means a special script is going to need to be used when stopping and starting the server and that IT is going to have to kick this off to bounce the server. Given the frequency of microsoft patches and the number of people involved in bouncing servers, does anyone this this will get overlooked?

As with any computer system, if the backup procedures are implemented there should be minor pains felt when such instances do occur. Don't get me wrong, as hyperion moves their products more into the enterprise wide environment these changes are necessary and welcomed.

consulting story:

(

On a recent project I was in charge of security for a hyperion portal that utilized performance suite, essbase, analyzer, and reports. This was on pre-system 9 software. The security hoops to get 1 new user into the new system was mind numbing. Each product had it's own security to maintain. The products for this 500 user system were the following:
-essbase - 65 security filter groups on 6 applications
-reports - 8 security groups
-analyzer - 8 security groups
-performance suite - 15 security groups

So a production transmittal to add 500 users to the system was huge. Not to mention the steps that the help desk had to go through in order to add 1 new user to the system. While each tool had it's own list of users that were scripted, some tasks, like the user assignment to groups in reports could not be automated. The analyzer bulk load (in 7.x) was not the easiest to get working as it was pure java and we didn't have a java coder just lying around. To be expedient, we ended up maintaining the performance suite by hand.

)

This is one example of why system 9 is good for us (us being consultants and customers, especially the help desk) I know there are a whole lot of nasty/messy upgrades out there just waiting to be done and some sleepless nights for some lucky consultants.

It still makes one think about the good old days when our worries were only:
-is essbase up (we'd run it in the foreground to see what's going on)
-keeping track of the latest excel/vba code for your user interface