An application of any sort needs all the right things surrounding it in order to deliver whatever content it was designed to deliver. When we think of applications in the Oracle EPM space, we are talking about Essbase Cubes, HFM Apps, Planning Applications, Financial Reporting. There’s many more than just that, but the point here is to focus on JUST the application and ensure it’s ready for your users.
Each app has its own set of things to check on, but the structure of each of these applications can be broken down into a few larger chunks:
- Application & Environment Settings
For these 5 areas, when you are trying to determine if an application is ready for your users, each has its own unique procedure and process, but the bottom line is that as an application administrator, you should be aware of changes, status, and operational readiness.
Application settings can be found in config files, registry hives, database tables and even in startup batch or shell scripts. Product documentation should be the place to find all these and if this is the first month you are even looking, take note of what these settings are. Then, for each subsequent check, you have a baseline to look at and know that things have not been tampered with. For Oracle EPM products, the base place to look for a listing of these settings is in the installation troubleshooting guide under the Deployment section for your version.
You should be aware of changes to outlines and metadata and any associated rule files which may have been affected by changes in app structure or layout. If changes have happened, then it’s your responsibility to ensure these changes did not impact the application performance. While that could be anything from a smoke test of loading a few key forms or reports all the way to profile testing for several applications working in parallel to deliver content, it’s a task that you cannot leave out when trying to ensure things are going to function normally.
Depending on your role, it may or may not be possible to get security-related changes. You may not even have a process in place to keep records of security changes that happen within the application, but if possible, you should be rolling that in as part of the checking that you do each month. Changes in security can have a great effect on the user’s ability to get to areas needed. If you don’t have access to security, it makes it almost that much more important that you know who does and understand what changes have been made so you can test accordingly and ensure individuals have the clearance they need.
Backups should happen periodically anyway – it’s never a bad idea to have a plan in case something goes terribly wrong – but if you are not doing this yourself, don’t depend on another team to get it right because it is YOUR application and you need to be responsible for it. Ensure the parts that you need to recover with are up-to-date and have been archived properly. This ensures a recovery path even in the worst-case scenario.
Finally, functionality – is the app doing what it’s supposed to? Test to ensure you can carry out the functions that your team will need. Sometimes it’s enough to test a single form or report, but in other cases, you might want a wider sample and a more complete testing suite. Although there are several out there, you know there is only one that I endorse – but USE SOMETHING. There are so many times testing is not done because it’s expensive or takes too long – figure out a solution because a full test can point out flaws well before you are airborne during a close cycle.
In the meantime, read about what your peers are doing to manage their applications. This white paper discusses how an educational organization used these principles to improve their environment and reduce their day-to-day stress levels.
When your Hyperion environments get out of sync, don’t let your workflow get out of sync too.