IBM Cognos: Metadata is What it’s all About
By Elwood Philbrick - Envisn, Inc.
IBM Cognos 8 and Cognos 10 are a big advancement over previous versions of Cognos BI and one of the key reasons for this is the capability that Framework Manager provides in being able to import and support all forms of data models. But defining Cognos metadata only in terms of what Framework Manager can do may be good for showing how it enables Cognos BI to provide a common view of the enterprise across multiple dimensions, but falls short of encompassing what BI administrators have to deal with on a day to day basis.
Why? Because from BI management standpoint, getting it into Framework Manager is the easy part. Once the metadata is in use across the enterprise, the administrator then has the challenge of understanding what’s being used, where it’s being used and how it’s being used. Managing this on a day to day basis in an enterprise BI environment can become all consuming for a BI admin.
The Only Constant is Change
The single biggest consumer of a Cognos BI admin’s time is managing change. Sure, they have to deal with keeping the environment operational, getting scheduled reports out on time, responding to user’s questions, support issues, adding new users, etc. But beyond that it’s managing change, writ large. To do that effectively requires three things: good information, efficient processes and intimate knowledge of Cognos BI.
In terms of information, you need to know basically everything about every object in the Content Store including users and their access profile.
Good Information
What you need to need to know is all of the key properties and parameters of all of the objects in the Content Store. This covers all types of objects and the individual attributes they have like jobs, schedules, etc. The multiple dimensions of this can become mind numbing quickly so let’s try to list the major pieces:
- Documentation – Having good documentation of all of the data that’s used in all models, packages, reports, cubes and queries is essential. It’s needed for doing an impact assessment of data changes on the content and actually making the changes when required. But content documentation is also essential when making changes to content, especially models and reports. Being able to see how joins are structured in a model can make it much easier to trouble shoot a report that does not perform well. Plus, with good documentation of content, the metadata can serve multiple purposes, enabling you to capture information on changes, the amount of content, etc. Properly done, the possibilities are endless.
- Usage – What content is being used, with what frequency and by whom? Having this information is essential to managing your environment. This applies to other areas as well such as being able to see what data items in packages are actually being used and how often. It can also be important in managing your IBM Cognos licenses. Usage is also important when doing upgrades. Nothing makes less sense than upgrading content from one version to another that’s not being used.
- Access privileges (security) – In an active BI environment, the single most time consuming activity for an administrator is working the issue of access and security. Whether it’s validating privileges, adding new users or modifying current ones, having accurate information in this area is critical. If you haven’t already tried to follow a thread of implicit security through multiple levels then you’ve never seen real complexity.
Processes That Work
Creating defined, replicable processes for dealing with recurring tasks in your BI environment is critical. These make it possible to get things done as quickly as possible but also in a way that’s consistently accurate. So what are the things that BI admin processes should do? Here are the top five:
- Handle routine tasks the same way every time with 100% accuracy. Many tasks can be very difficult or impossible to validate easily.
- Processes should have the fewest number of steps possible. Multi-step processes should be avoided wherever possible. An eight step process for adding new users and their access privileges is a recipe for disaster. If the person gets interrupted it’s likely they’ll have to start over.
- Minimize the risk associated with key tasks. Migrating or ‘promoting’ content from one environment to another (eg, dev>test >prod) is a regular activity of large BI environments but is often done with a high risk profile. One company we know of actually brought down their production environment for two days because they inadvertently overwrote the data sources for content being moved to production. Is also too easy to mistakenly overwrite security settings as well. Set up processes that minimize risk.
- Make sure that the processes are clearly defined and that people are trained in them. Turnover alone can often destroy what are otherwise may be well designed processes.
- Your processes should be self-documenting. This means that when you’re making changes you should have a record of them, ideally one that’s created automatically. This clearly ties into bullet 1 above. Many Cognos environments have to keep a record of all changes made to security. Doing this manually and expecting it to be both accurate and complete is a tall order.
Knowing How it Works
Succeeding at this obviously requires an intimate knowledge of Cognos BI and how it works. Training courses can help here in key areas, like the SDK for example. Even with this knowledge trying to create all of this on your own may be too much to expect. But some things, like have clearly defined processes for tasks is something everyone can do. Beyond that it you may need to hire more experienced help and even look for outside solutions to help with both the information you need and the processes handle routine tasks. In an upcoming blog we’ll cover how to evaluate how decide what is best for your needs.
Image by Phil Hawksworth