Envisn's IBM Cognos Blog

Is Cognos 10 a Big Deal?

Thu, 19 Jan 2012 17:41:00 GMT

January 19, 2012 by Rick Ryan - Envisn, Inc.
In an interview two weeks ago, IBM’s new president, Virginia Rometty, cited Analytics as the single most important focus for the technology company going forward. Analytics is what makes it possible to put the flood of Big Data to productive and profitable use. Other areas of IBM’s focus are enabled by Analytics. Smarter Planet is essentially about being able to mine all of the sensor data now available from multiple real time sources. And Cloud Computing makes it possible to access massive data sources from anywhere.

The big challenge is how to deal with the Big Data tsunami. It’s only of value if you can integrate it, organize it and then answer the two most important questions:

What does it mean?
How can we use it?

Watson and other new technology within IBM will play a role here but the reality is that this is where BI and Cognos 10 come in. Why? Because it is already well established in the market and its infrastructure already exists today in most companies. So take a solid platform, make it better and use it to create and enable the future around Analytics you want to create.

So since the introduction of Cognos 10 some 15 months ago now, one has to ask the question, is Cognos 10 a big deal?

Right Plan - When IBM acquired Cognos three years ago some expected that Cognos might be subsumed within Big Blue and become nothing more than a new heading in the product catalog. Nothing could be further from the truth. Cognos has become a cornerstone of the analytics focus within IBM and Cognos 10 is a big part of what’s driving the growth in this space. How did this happen? IBM recognized what Cognos offered not just to its existing customers but saw the potential for even greater growth through the ability to broaden the BI platform with Predictive Analytics, TM1, Planning, Statistics and full integration within IBM. IBM made a significant investment in Cognos 10 and the returns are coming in. Year over year growth is as good, or better, than anything Cognos has seen in recent years.
BI Everywhere - Business Intelligence has been around long enough now and in so many organizations that its widespread use is leveraging even greater adoption. This, plus the ability of mobile apps to put BI anywhere is pushing it down and out within companies and organizations. People need and expect access from anywhere and at any time. Cognos 10 makes this possible.
Big Picture - Because Cognos 10 is part of a much larger, integrated set of offerings by IBM, customers have more options in terms of growth as their own needs evolve. The integration of Cognos with existing IBM technology such as Lotus looks totally seamless as does that with Microsoft.
It’s the Platform - A broad spectrum of analytics requires a platform fully capable of delivering it all. Cognos 10 does that very well. Cognos 10 has the broadest level of integration of any BI platform on the market. What’s more, it is well positioned for the future. All of the remaining issues of full web integration of PowerPlay OLAP have been addressed along with integrated collaboration and broad data source usage.
The delivery model is in three levels:
i. Solutions: Customer – Industry – Functional Area
ii. Capabilities: Reporting & analysis, dashboards, In-memory, planning iii. Platform: Access – integrate – model – manage – deploy
User driven – The ease with which users can now create their own dashboards, interactive graphics and active reports to build their own work platform is impressive. IBM and Cognos listed to customer frustrations around “studio hopping”, difficult and limited interactivity (sound familiar) and the need for simple user interfaces. Then they did something about it. Cognos 10 is clearly the most user friendly BI platform out there.
Performance – The latest release of Cognos 10 is 6X faster on queries, 40% faster on cubes, and 90% faster on TM1 than the previous version. The initial release of Cognos 10 in the fall of 2010 was also better across the board than Cognos 8.4. Customers can expect that improvements in performance and scalability along these lines will continue going forward. IBM has shown it can deliver.
Lifecycle Management – The Cognos Achilles heel for a long time was the difficulty of upgrading and migrating from one version to another. Cognos 10 addresses most or all of these issues and more improvements in this area are coming.

Summary

So is Cognos 10 a big deal? At this point the answer is an unequivocal yes. It’s clear that the Cognos product set has clearly benefited by being part of IBM. It is broader and deeper than if Cognos had remained a stand alone company and it is the clear leader in its market space. Users have clearly benefited in some key areas, particularly in ease of use and broader capabilities. But what is really significant is how well positioned Cognos 10 is going forward. It is a strong platform that positions IBM well in Analytics as it reinvents itself for its next 100 years.

© 2012 - Envisn, Inc. – Cognos Metadata Management. All rights reserved.
Image by Horia Varlan

IOD 2011 - What's New in Cognos 10

Fri, 18 Nov 2011 18:11:00 GMT

November 18, 2011 by Rick Ryan - Envisn, Inc.
It would be easy to talk about what’s new in Cognos 10 from the recent IBM Information on Demand (IOD) 2011 event in Las Vegas only in terms of new user capabilities but that would miss a big part of what’s going on here. There are new user capabilities that matter but it’s important to focus on the major trends here as well. This article will attempt to do both.

When it was first announced a year ago Cognos 10 raised the bar on Business Intelligence and at the same time BI began to be positioned by IBM as part of the larger umbrella of Business Analytics. BA is a broader offering of analytical capabilities than traditional BI and encompasses things like workforce performance analysis, sales performance analytics, predictive analytics, governance, and risk and compliance management. That said, it’s clear that at least within IBM, BI is the point of the spear.

The major trends within Business Analytics that are driving IBM are:

Demand for agile analytics – Pushing down and out within the organization. People need it now and mobile devices make this a physical reality.
Broad spectrum of analytics required – A platform needs to be there to deliver it all and to manage it all.
The Wild West of data – It’s both big and personal, not just internally generated but the flood of external data as well. Big Data is the tsunami of data that companies need to deal with today and most of them are not prepared for it. A statistic presented by IBM said that 90 percent of the world’s data was created in the past two years. Staggering!

In terms of BI IBM sees it in terms of three levels that all need to be worked at the same time. These are:

Solutions – Finance, risk management, industry specific applications, etc.
Capabilities – Reporting & analysis, scorecard/dashboards, in-memory, planning & budgeting
Platform – Access – model – manage – deploy

The specifics of what’s new in Cognos 10 for IOD 2011 include the following:

Cognos on the cloud – you can now create a C10 on the cloud in 45 minutes.
Faster performance – 6X faster query performance, 40% faster on cubes, and 90% faster on TM1.
Mobility – Native iPad application allows you to work offline via Active Reports. You can leverage the existing C10 infrastructure and reports on your iPad.
Business Insight Workspace – This is 2X faster than last year. Plus you now have:
• Geospatial reporting – highly interactive graphics.
• Real-time widgets – Ability to stream live data (example: customer feedback/complaints).
• User customizable charts for standardized dashboards.
• Live drill down by dashboard users.
• Tighter use of the workspace available – 30% more on the desk view.
Integrated collaboration – The ability to use different capabilities across a common platform(s) and create collective intelligence within the organization.
Real time updates to a multi-dimensional plan – widgets are available to change assumptions instantly.

Summary

IBM Cognos BI is morphing more right now that at any time in its history. Better products, better platforms, seamless integration and greater ease of use make it essential at all levels and across all functions within the organization. But while it’s changing in some ways the important thing to notice is the prominence it has finally achieved in terms of the transformational capability it has for continuous improvement in results. For those that have been around this space for a while it’s really impressive to see the capabilities match the marketing.

Image by Woodleywonderworks

IBM IOD 2011: IBM Cognos Framework Manager Unleashed

Wed, 12 Oct 2011 18:42:00 GMT

An Innovative Approach to Modeling Complex BI Projects

October 12, 2011 by Rick Ryan - Envisn, Inc.
With the IBM Information On Demand (IBM IOD 2011) event in Las Vegas less than two weeks away many of you may have already made plans to attend and started to schedule your sessions. For those of you still undecided about which sessions to attend, our blog this week may help make up your mind.

The Boeing Company, an Envisn customer, has one of their people making a presentation on the Business Intelligence track. Larry Bob, BI Architect, will be giving a session titled “IBM Cognos Framework Manager Unleashed: An Innovative Approach to Modeling Complex BI Projects”. Session number is 1724. Boeing is a leader in the use of IBM Cognos BI and Larry has played a major role in organizing large data sets in a manner which minimizes complexity in the modeling process.

The program guide abstract for Larry’s session describes it:

The Boeing Company faced a multitude of challenges managing the many IBM Cognos Framework Manager models it generated to the Finance community. Attend this session to see the solution that meets these primary design principles:

Everything is modeled once and only once
Multiple developers can easily develop in Cognos Framework Manager simultaneously
Model testing and the need for regression testing is minimized
Design is optimized for maintainability
All applicable content can be made available to a given user group in a single package.

Beyond that we asked Larry the following four questions. His response is shown below each of the questions:

Why should people come to the session?
LB - If you use Framework Manager and you have more than one developer, more than one subject area, and want to learn the leanest, most efficient way of modeling your data – this is the session for you.
What do you plan to cover?
LB - The journey from simplicity to complexity, the search for delivering consistency in an efficient manner while optimizing the end user experience, and the Framework Manager modeling methodology we deployed. The session will walk thru the architecture in detail and include “musts” for success.
What constitutes a ‘complex’ BI project?
LB - Any BI project with more than one developer and/or more than one subject area where consistent presentation in the Cognos BI suite is desired.
What are the key takeaways from this session?
LB - Step by step instructions for implementing this methodology in your environment and the benefits from using it.

This will be an interesting and informative session. I have seen Larry’s presentation and it’s impressive. It's an excellent example of what a skilled Framework Manager modeler can do in a large environment to advance both simplicity and excellence at the same time. You don't want to miss this.

***************************************************************

UPDATE

Larry has graciously made the slides from his presentation available
and you can find them here:

http://www.slideshare.net/Envisn/iod-2011-1724-bob

***************************************************************

A couple of other sessions you might also want to consider attending at the IOD include:

BBI-1672
Implementing the System Management Methodology (SMM) for IBM Cognos Administration

This session will introduce you to the System Management Methodology (SMM) for IBM Cognos Administration. The SMM is a collection of examples and methods for managing and trending the health and performance of your IBM Cognos BI installation. This session will walk you through the process of implementing the SMM and review sample objects included in the package.

Session Type: Best Practices/Deployment
Speaker: Dean Browne, IBM

BBI – 2723
Streamlining the Lifecycle of your Business Intelligence Solution

Streamlining the lifecycle management of your BI solution is critical to responding quickly while controlling costs. Join this session to hear how IBM Cognos addresses the discipline of lifecycle management, and ensures that you can cost-effectively manage your BI solution when initially deployed and as it changes over time. This session will include demonstrations of IBM Cognos BI capabilities and show you how to handle the lifecycle management of your deployment.

Session Type: Technical Overview
Speaker: Andreas Coucopoulos, IBM

Managing Multiple IBM Cognos Content Stores

Wed, 21 Sep 2011 10:55:00 GMT

September 21, 2011 by Rick Ryan - Envisn, Inc.
Purpose of this blog article is to share with you the following:

The role of multiple content stores in a typical IBM Cognos BI installation
How these content stores are similar and how they are different
Best practices for managing multiple content stores

As customers move to take advantage of what’s new in Cognos 10 the role of the content store is even more critical. It has more in it and more users relying on it. Most Cognos BI installations will have three distinct environments:

Production – Delivering BI content to end users.
Test or Pre-Prod – Validating the functional readiness of new or changed content.
Development – Authoring new content or modifying existing content.

Some installations may have additional environments in the BI delivery chain.Some may have less. In small to mid-size installations, for example, it’s not uncommon to see just a production and a development environment. In this case development also serves as the test environment.

We have also seen instances where there is only a production environment. Development and testing co-exist with production in a single environment. This is high risk and not recommended as it is too easy to make mistakes with content around things such as security, data sources, etc. Content that has a different purpose at a given point in time should be in a different environment.

Production Content Store

In a production BI environment there is not a lot of room for error. For environments where there are hundreds or thousands of users there are almost always policies and procedures which dictate what can and cannot be done in the production environment and how it must be done. Some of the more important best practices include the following:

Content is organized for easy access by users:
a. No deep folders or multiple clicks to access content
b. Content is clearly labeled reflecting what it is
c. Structure is uncluttered and easy to navigate
Criteria in place for what’s ready for production
Rules for managing My Folders
Backup and recovery procedures are in place and routinely tested
Capability for managing and validating security real-time
Data sources are validated on an on-going basis
Unused content and excess output is removed
Metadata management tools
Managing schedules, triggers, distribution lists, etc.
On-going monitoring of content and user usage

Test or Pre-Production Content Store

The Test or Pre-production environment is similar to production but is also different in many ways. Best practices here include:

Security should represent production
Data sources are active (versus what are usually static in dev)
Need the ability to compare to production for:
a. Security
b. Metadata
c. Data sources
d. Content counts (getting rid of old or unneeded test content)
Test criteria are in place (when is it ready for production?)
Record of what has completed testing
Metadata management tools
Log file of what has been moved to production (who-what-when) -See Figure 1
Version control for content
Major focus on change management
Backup and recovery procedures are in place and routinely tested
Usage tracking (is the content really being tested?)

Development Content Store

The development content store is where all new content is authored or created. Here the most important best practices include:

Security model reflects development environment only
Policies and procedures designed for development only
Data sources are typically static but representative of production
Criteria in place for moving content to Test or Pre-prod
Log file of what has been moved to Test or Pre-prod
Folder structure reflects author/developer needs
Metadata management tools
Tools in place to assist authors/developers in diagnosing problems in development content -See Figure 2

Summary

There are a couple of themes that run through the best practices of all environments:

Change management is a constant – This is by far the major activity for Cognos administrator and they need to be able to handle the activities associated with this quickly and accurately. And this means they need tools that can help in this process. The tools should help in all areas of change management and enable you to work in all environments and across them at the same time.
There are key things you need to monitor and manage as an administrator. What are they? They may differ from one installation to another but they may include:
- Usage – content and users
- Growth in content and users
- Potential problem areas such as broken lineage, missing objects, etc.
- Security – validating on a regular basis
- Data sources – right ones in the right places

What are the key things for your environment? Think about what you are already doing and build your own list from there. The important thing is to identify and use them.

Image by Seattleclouds.com

Cognos Content Store - Top 10 Key Metrics

Tue, 02 Aug 2011 10:55:00 GMT

August 2, 2011 by Elwood Philbrick - Envisn, Inc.
The purpose of this article is to identify key metrics that administrators should monitor or pay attention to in terms of their production Cognos Content Store. Many of these can directly impact overall performance as well as user satisfaction.

Size – Most administrators of large Cognos environments have no idea how large their Content Store is. It’s good to know, but by itself this may be the least important metric of those listed here since size alone really does not tell you much.
# of objects by type - Knowing the mix of object types in your Content Store can be very useful. The relationship between the number of reports and queries relative to the number of packages or models can be helpful particularly as you begin to track these relationships over time. Instead of relying on one or two very large packages for everything, a better strategy is to create packages that are specific for an area or function such as sales, logistics, marketing, etc. Figure 1 shows an object count summary by type for a sample production Content Store.
Saved output – In most mid size or large environments the amount of saved output is usually significantly larger in terms of file size than the number of objects in the Content Store. Users may be saving output from reports over time and many of these can be very large. If you don’t already have a policy in place for this you probably need to get one. Figure 2 is an example showing total saved output and the detail for Sales folder in a sample Cognos Connection.
Rate of growth – You should be tracking the rate of growth in terms of the number of objects as well as saved output. This issue becomes more critical in environments that are large and/or are growing rapidly. Being able to monitor rates of growth in terms of the areas mentioned above can be a key indicator of real or potential problems in your CS. Tracking growth should be done no less frequently than on a monthly basis.
Unused objects – Ideally you should be able to track usage of both content and users across your Cognos environment. If you have content that has not been used for a period of time, say 2 – 3 months or more, it likely is a candidate for being removal. Being able to purge public folders of unused content makes it easier for users to find the content they really need. Also, user licenses that are not being used can be reassigned to new users.
Objects with broken lineage – Lineage breaks can occur because a package was modified and published without understanding the impact on reports or queries that are using it. Or because a data item(s) no longer exists. Being able to identify and fix objects with broken lineage before users even know there is a problem reduces calls to the help desk as well as the number of frustrated users. At any given time the number of objects with broken lineage in a typical production Cognos Content Store is somewhere between 10% and 15%.
Missing objects – Like broken lineage, missing objects can result in a null response when users click on a report to run it or are waiting to receive a schedule report. An example might be where a user has created a view of a report but then that report somehow gets deleted. Or a distribution list mistakenly gets deleted and the recipients do not get their reports.
Duplicate objects – Identifying two or more copies of the same object across the environment may indicate a need for better user training.
Version Creep – Keeping versions of models, packages or other objects far beyond their needed time period can often result in poor performance over time. If you do not need versioning then do not turn it on.
Excessive report creation – If you see an excessive number of reports being created it’s an indicator that users may not understand how to use bursting or prompts.

Summary:

Managing your Cognos Content Store starts with knowing what’s in it, how large it is, how fast it’s growing and where the growth is taking place. The metrics discussed here may not all be appropriate for your environment or even the right ones. But it’s a place to start and begin the process of getting your Content Store aligned with your BI strategy and plans.

Image by tomas_fitnesscoach

Cognos License Auditing & Capabilities

Fri, 15 Jul 2011 19:33:00 GMT

by Elwood Philbrick - Envisn, Inc.
The purpose of this article is to help Cognos administrators address the need for Cognos license tracking and how best to do it. Administrators are usually the ones tasked with Cognos license auditing and insuring compliance with their license agreement.

Why track licenses in Cognos?

Many Cognos administrators typically don’t worry about Cognos license auditing or license compliance unless they are being audited on their license usage or it’s in preparation for the annual support renewal. IBM appears to be more aggressive about the license compliance issue than when Cognos was a standalone company. From their perspective this is just an issue of keeping honest people honest. As an IBM Cognos customer, however, you want to avoid a situation where the result of an audit is a large, expensive surprise in order to “true up” for what you are using versus what you purchased. This can be avoided by having a regular process of comparing what you’re actually using against the number of licenses you purchased.

The term licenses and capabilities are often used interchangeably. And while they do imply the same thing, there are some differences. Licenses typically connote what you actually purchased in terms of user licenses for certain features or functions within Cognos. Capabilities relate to these but from the perspective of what is actually available for a given user to use.

Your licenses need to be tracked against the license bundle(s) or model that you purchased those licenses. That may seem obvious at one level but its implications can be confusing to some. Our work to create the Cognos license and capability tracking feature within our NetVisn product was a real eye opener. In talking with Cognos it became obvious that looking for a standard model or structure behind how user licenses were sold would not provide the results we were looking for. Why? Because in most cases these were packaged and sold in a way that best met the customer’s needs at a given point in time. This makes sense because it typically results in the customer getting what they need for their unique requirements at a competitive price. Another proof of this is that our own customers pointed out the need to be able to count and aggregate licenses in a flexible manner since license audits are only one of the reasons for tracking licenses.

Get it your way

Figure 1 shows a partial listing of capabilities within Cognos 10 that can be assigned to users via the security tab of IBM Cognos Administration. Some secured functions have sub-categories for more detailed control of capabilities. Report Studio, for example, has a bursting feature to control who can edit and run burst reports. In this example we are looking for counts on Metric Studio, PowerPlay Studio, Query Studio and Report Studio.

In Figure 2 we see the results of this license count selection. It shows the total and detail of users for two of the functions selected; PowerPlay Studio and Query Studio. In this example each has six users and we can also see the names of those six users.

This level of granularity is important in auditing and tracking IBM Cognos licenses and capabilities. It provides the administrator with the ability to:

Determine how many of a given license type are currently in use and by whom.
Identify which functions and sub-categories are assigned to specific users
Easily map actual licenses in use against those purchased.
Provide lead time for planning and budgeting for additional licenses

Doing the actual count of licenses can be difficult and tedious since the manner in which access to capabilities is granted can become complex. Most environments assign capabilities to groups and roles rather than named individuals since it makes management easier. Individuals that need specific capabilities are assigned to a group. A second group may also need this same access and in some cases the same individuals could be members of both groups. Here the problem is potential double counting which would over count the number of actual licenses in use.

Tracking licenses and capabilities manually in a small or mid size environment may be possible but it will be difficult to get and maintain a perpetual count over time. In a large or complex environment you will likely need a third party tool or utility that can track these automatically. If you go this way you need to clearly understand the rules being used for what gets counted and how it’s counted. This is critical in terms of having to defend your numbers in the event of a license audit.

Summary

All IBM Cognos environments at one time or another will be faced with the need to do an audit of their licenses. It may come for a number of reasons and administrators need to be able to count and track licenses and capabilities in multiple dimensions. If you are going to purchase or create a tool or utility for doing this you need be clear about the rules it uses to insure that it is accurate and has the level of precision for what you need to track and measure.

© 2011 - Envisn, Inc. – All rights reserved
Image by de schepper

Consolidating or Merging Cognos BI Environments

Mon, 06 Jun 2011 20:15:00 GMT

by Rick Ryan - Envisn, Inc.
Managers or administrators are often faced with the task of consolidating or merging Cognos BI environments. This may result because of mergers, cost savings or simply a desire to have fewer environments to manage. Invariably the consolidation involves users and content that will be merged into a new or existing environment and this requires careful planning and flawless execution in order to be done successfully. The purpose of this article is to help you identify what you need to know and how to plan and execute a successful merger of Cognos environments.

Scoping out the merger

A project like this is a big deal and not to be taken lightly. A merger usually involves merging one existing environment into another one. But it could also involve merging two or more environments into a new one. An example would be merging two Cognos 8 environments into a new Cognos 10 one.

The first thing you need to do is to scope out the environments to be merged. This requires a lot of detailed analyses in order to get the data needed to prepare a plan. Some of the things you will need to know include:

Are the environments more similar or dissimilar?
The number of users and the amount of content.
Do any of the same users exist in both environments?
Does any of the same content exist in both environments?
How will the security model differ (if at all) between source and target?
Can you identify and eliminate any unused content?
Special issues – dependent on the specific needs of the environments

If this involves more than two environments that are being merged you will need to get the same information for the others as well. In many respects the task will be significantly easier if there is no overlap between users and content between the environments to be merged. Why? See the diagrams below:

Separate and distinct Environments: Where the source and target environments are dissimilar and have no overlap there are fewer things you have to deal with. However, where the source and target environments similar it is likely that there are more things you will need to address before merging the two environments:

Similar or Overlapping Environments: In the above diagram both source and target are similar raising the possibility for multiple issues on common data sources, folders, models, etc. Identifying and resolving these issues can be tedious and time consuming but absolutely necessary for a successful merger.

Creating the plan

Once you have collected the information you will need to identify and layout the key tasks to be done and get them in the right sequence. Most problems in a project like this occur when key steps are missed or placed in the wrong order. The planning should include:

Collect the needed detail information
Decide how common issues will be dealt with
Decide how to deal with unused content
Modify, if necessary, the security model in the target environment
Map the tasks to the timeline
Review the plan with key constituencies
Test and validate
Communicate the plan to the users
Execute the plan

If you want to avoid the “big bang” approach of a deployment and do the merger in a more controlled manner you can use a product like NetVisn which allows you to simply move the content from the source to the target at a measured pace. And if you have to move hundreds, or even thousands of users, this can be a huge risk reducer. It also has the advantage of validating all objects as they are being moved to insure that all dependent objects are moved together and that they actually work in the new environment. Using a deployment package is an “all or nothing” approach that can instill fear in even the most careful planners. But for many this may be the only alternative.

Summary

Merging or consolidating Cognos environments can be a challenge even if they are small of mid-sized. In a large environment the difficulties are magnified. Creating a plan that reflects the specific needs of the environments to be merged is essential for success. Using tools that make the task easier and minimize risk can help insure success and reduce the time and effort involved.

© 2011 - Envisn, Inc. – All rights reserved
Image by: RaGardner4

Migrating Cognos BI from LDAP to Active Directory

Fri, 29 Apr 2011 12:15:00 GMT

by Elwood Philbrick - Envisn, Inc.
At one time or another many Cognos BI managers or administrators are faced with the task of upgrading their security model. This article will focus on a best case scenario for moving from LDAP to Active Directory (AD) for managing security in Cognos BI.

Why Active Directory?

Most large Cognos BI environments move to Active Directory sooner or later. There are a number of reasons for this, but simply stated it’s because: Active Directory is a stable, scalable, secure and proven identity management and control system whereas a custom developed LDAP solution is not. Custom LDAP solutions lack these attributes and are cumbersome to manage.

How this often plays out is that Cognos BI managers are given a timeline for moving to Active Directory and then left to figure out how best to do this. It’s generally not a pain free process.

The Challenge for Cognos BI

What you’re trying to do here is to take your Cognos content from an existing access structure and migrate it to a new one. While this is conceptually a simple task, there are some things that make actually doing this somewhat difficult. The major one is that the new environment causes a new CAMID to be created for every user. When this happens there is no linkage back to the users My Folders, distribution lists, etc. It’s as if every user is new user. Obviously, current users expect to have access to what they have today, particularly their personal content.

Create a Plan

You will first need to create a plan that covers mapping your existing LDAP structure to Active Directory and then re-linking users My Folders back to the new environment. The steps are:

Create a map of your current LDAP structure - Here you need a map of your current groups and roles and all the users associated with them. This can be difficult to create but someone well versed in the Cognos SDK could automate the creation of this map. Alternatively, you could use a Cognos Security tool like NetVisn and its Security Report to give you a complete view of all groups, roles and user accounts. This report needs to look into groups to see the specific users and how they are placed in groups that reside within the LDAP itself.
Preserve users My Folders from the current environment - You’ll be backing up this content in order to reconnect it to users in the new environment. Remember that each user will be given a new CAMID in the AD environment.
Create the new structure of groups and roles for the AD environment - This is the perfect time to give some careful thought to how you can make the new environment better reflect your current and future needs. Once you have created the new structure, then use the map created in step 1 to assign users to the new groups and roles. Once you have done this then re-associate groups and roles with folders and public content.
Re-map the My Folders into the new environment - In this step you are re-linking the personal My Folders from step 2 back to their owners. This is the ‘fun’ part and may take some time. IBM Cognos has a utility that provides some help in doing this but it is not automated and it is not a supported utility. But here again, NetVisn can greatly simplify this by using its Cognos promotions feature to do both step 2 and step 4 with significantly less effort. It also makes it easier to validate that this whole process has been done accurately.
Validate & test new AD environment – The final step is to do some testing to insure that everything from the old environment has been accounted for and is where it should be in the new environment.

Summary

Migrating from LDAP to Active Directory offers a lot of advantages but needs to be done with careful planning and execution. This should be treated as a separate project and not made part of any upgrade. IBM Cognos recommends that you not change security models during a version upgrade within C8 or C10 or from one to the other.

© 2011 - Envisn, Inc. – All rights reserved
Image by Paul Nasca

IBM Cognos 8 Content Manager Browser Tool

Fri, 18 Mar 2011 15:33:00 GMT

by Elwood Philbrick - Envisn, Inc.
A frequently asked question is whether IBM Cognos provides any tools for helping administrators manage their BI environment. The answer is both yes and no. IBM Cognos does provide a tool that enables users to browse their Content Store. A link for downloading this tool is at the end of this article.

What it covers

The Cognos 8 Content Manager browser tool provides a tree view of the objects in the Content Store. The major categories are:

Capability – Shows what studios are available, scheduling, lineage, etc.
Configuration – This is the detail of the Cognos installation settings as currently configured
Directory – The structure of the user groups and roles along with Personal Folders
Public Folders – Shows all of the public folders and the objects that they contain including reports, queries, views, packages and versions, etc.

As you navigate up and down the branches of the tree within these categories you will see the detail properties on the right side of your screen for whatever object you have selected. So if you were looking at a report, for example, you can see all of the properties and parameters of this report. If you chose “specification” here it would give you the detail specs for this report including data lineage. The problem, however, is that this can only be viewed or opened in Notepad, and when doing that you get a mega dump of XML like content that can be difficult to parse for consumable information. So yes, you can drill down into the detail but when you get it you may not find it very useable.

The tool also has a search capability so you can search selectively for virtually anything in the Content Store. This includes wild card searches as well. There apparently is a limit on searching, however, since you could encounter a Content Store lockout if the Record Read Limit exceeds 5000. But if you are looking for something specific and can narrow your search this feature can be helpful.

How it’s best used

Areas where this Content Manager Browser Tool can be useful are for finding things and looking at relationships between objects. Thus, if you wanted to know which package, or version of a package, that a particular report was using you could easily find that by first finding the report and then looking at the properties section to find the package being used. If you wanted to look at the folder structure of your Cognos environment it is easier to use this tool for browsing that than to try and do this in the Cognos portal itself. You can quickly drill down into the tree structure to see both personal and public folders. The tool also provides a snapshot for all settings and properties for all objects in the Content Store and the Cognos software configuration. So if you know what you need it’s relatively easy to look it up. Basically, it is most useful when looking for point to point relationships between objects and for finding the detail properties of individual objects.

Limitations

While useful, the tool has some limitations:

An obvious one is that navigation up and down the tree structure can be tedious and time consuming.
No ability to see one-to-many relationships. A frequent question that arises is which objects use this model or package or how many models or reports use this database table?
It also does not have any capability to aggregate or analyze any of the objects or properties. Cognos administrators spend a great deal of time doing two things: managing change and trying to get answers to specific questions, often very detailed ones. Both require the capability to aggregate and analyze in multiple different ways.
Effective presentation – While all of the detail like specifications, data lineage, etc. are there, it is not really available in a consumable manner. In those rare instances where you have to wade through this for that one piece of data you need, it’s likely to be something you’ll only do once.

Summary

The Cognos 8 Content Manager Browser Tool may be helpful when you need to know specific detail about an object or folder structure or license capabilities. To go much beyond that will require a more robust third party tool such as NetVisn.

You can find the download here: Cognos 8 Content Manager Browser Tool

Image by takomabibelot

The Out of Control Content Store

Mon, 21 Feb 2011 20:30:00 GMT

or The Monster that Keeps Growing

by Rick Ryan - Envisn, Inc.
Do you know how big your Content Store is? Do you know how fast it’s growing? And where, and why? If the answer these questions is no, then you’re not alone. Most Cognos administrators don’t really have their arms around this issue either. Not having the means to easily answer these questions is a big part of the issue; it’s hard to manage what you can’t measure.

In the five plus years that Cognos 8 has been available there have been a number of trends underway in terms of how it’s used. Probably the most interesting one is the dramatic increase in the amount of overall content in the Cognos environment, and thus, the increase in the size of the Content Store. It’s not uncommon to see Content Stores today that are over 100 Gb in size. That’s a lot of stuff, especially if you don’t know what it is.

Why the Dramatic Growth?

Back in the days of Cognos Series 7, and even into the early days of ReportNet and Cognos 8, most Cognos environments developed a standard suite of reports for their users that was intended to cover what the users needed in the way of reporting. Thus, marketing, sales, finance and other departments or groups each had reports created for them that were designed by others to meet their needs. That was the plan anyway. But the problem was that trying to determine what users needed and how that changed over time really didn’t work too well. Users always needed something different for their unique needs.

Thus began the move to letting users create their own reports so they could get what they wanted when they wanted it. It also resulted in more license sales so Cognos liked it too. It appears that user training to pull off this shift was somewhat uneven at best. As advanced as the BI tools are today, it can still be a challenge for users to create exactly what they need for their reporting, especially if it involves the proper use of prompts and/or bursting. Users will often experiment in creating reports until they get what they need. But the saved output from what they’ve created could remain there forever.

Users are now using their personal folders to create their own reports, schedule them, email them etc. They can also create views on public reports to create a custom version of a standard report. These things, coupled with no rules on saving report output also increases content rapidly. All of this has resulted in an explosion of content over time. In large Content Stores the number of Cognos objects such as reports, models, packages, etc. is typically dwarfed by the amount of saved output. It would not be unusual for a Content Store of 100 Gb to be comprised of 20 Gb in Cognos objects and the other 80 Gb to represent saved output.

Is Big Always Bad?

A large Content Store in and of itself is not necessarily bad. But it can become a problem when it begins to affect performance. We saw one instance where someone decided that the right strategy was to back up a very large model each week to a different file location. It soon began to have noticeable impact on overall BI performance. This is only one example. Imagine what happens when others do similar things without understanding the impact. Your Content Store is going to grow organically but that should be the result of new users and new content focused on real user needs.

Bending the Growth Curve

Get control of your Content Store. Here are some specific things you can do to tame its growth:

Monitor Content Store growth on a regular basis. In a previous article we talked about how to use the IBM Cognos utility or you can use a product like NetVisn that will provide broad insight into your Content Store.
Training – Probably the single biggest area of potential payback:

-Administrators and modelers need to know how they can unintentionally create growth issues. As an example, inadvertently or intentionally creating package versions on large models will also result in rapid CS growth.
-Train the user community – Users who are trained to do the basics well can go a long way to eliminating aberrant growth. Plus, it helps them get what they need faster and without pain.

Set and enforce retention policies – You should set some rules on how much saved output users can retain and for how long. Get user input before setting any rules.
Archive – There are many reasons why some report content needs to be archived. There should be a policy and process in place for the best way to do this. I am told that IBM Cognos has heard the need for this from their customer base and is planning to respond to it. We’ll see.
Clear out orphan content – In any large environment users are being added and deleted on a daily basis. Many times users are removed from the LDAP without their content being deleted.

Summary

Uncontrolled Content Store growth is a major issue in large IBM Cognos environments. Get out in front of your CS growth before it becomes a serious problem. Waiting too long will result in an out of control Content Store with limited options for correction.

Photo by natural gas

Managing IBM Cognos BI Security Using Inheritance

Tue, 18 Jan 2011 16:52:00 GMT

by Gary Larsen - Envisn, Inc.
If you manage an IBM Cognos environment you know that security can get complicated very quickly. By carefully organizing content in hierarchies and using security inheritance you may find this task a bit easier. Here are some ideas which may be helpful in you environment.

Security Inheritance

On the properties page of every object in Cognos is a permissions tab which begins with this option:

When this option is checked, the security defined on this properties page will immediately affect the security on all descendant objects unless they also override access permissions.

One of the advantages of inherited security is that a new object (report, query, job, etc.) automatically acquires security from an ancestor. The same is true if an object changes folder locations.

Clearing Object Overrides

On the same properties page is the follow option:

If you take the caption of this option literally you would assume the purpose would be to clear all the security overrides for the immediate children. In fact, this option will clear the security overrides of all ancestor entries!

This can be a quick method to re-initialize the security hierarchy at points in the content tree but be aware that security overrides located deep in the hierarchy will be removed. There is no need to ‘blast’ your security settings as this is done automatically.

Permission Basics

Think of how Cognos users require access to reports and the data they contain. For a particular report here would be the common permissions:

Group and Role Naming

The current preference in applying security in Cognos is to use Cognos namespace groups for content security and Cognos namespace roles for capability permissions, although it is not uncommon to see externals groups and roles being used also.

When creating groups for content security it’s helpful to understand the various business domains that use Cognos and how that will impact access to content. You will know how this is defined in your environment, but this may be by business division, geographic area, department, etc.

A useful strategy in naming groups would be to include both the domain segment name and the type of access. For example:

Division1 Read, Division1 Exe, Division1 Write

And also groups for global access:

Global Read, Global Exe, Global Write

This will be helpful when setting the permissions for a folder containing content related to a specific domain:

Summary

Make your environment easier to manage by combining a group naming convention which implies content permission, and using security inheritance so that access permissions are maintained only in key locations of the content hierarchy. Implementing a consistent, clear naming convention significantly minimizes confusion and errors which can occur in managing IBM Cognos security across your environment.

Image by purpleslog

Download the Ebook:
Mastering IBM Cognos Security

Cognos Metadata That Matters

Fri, 17 Dec 2010 16:39:00 GMT

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

Scaling Up Cognos BI

Thu, 18 Nov 2010 14:16:00 GMT

By Elwood Philbrick - Envisn, Inc.
Cognos BI growth models
Cognos BI environments typically grow in two ways. The first way is with an initial deployment of BI in an environment that is clearly defined and bounded, typically up to 300 or fewer users. This generally follows a defined process of software purchase, content creation, training, initial rollout and full deployment over an appropriate time frame. Growth comes only as the organization grows with new people being added to the user base.

The second way starts out the same as the first but then it grows in large chunks or steps. An example might be a company that acquires BI for one or two functional areas, and once it’s proven itself, then deploys it to other functions or divisions across the company. Or it may grow through acquisitions that are then brought into the common Cognos BI environment. This may even involve different BI platforms that have to be moved over to Cognos.

Issues faced in scaling up Cognos

Growth that comes in big chunks is much more of a challenge than organic growth over time. Think about it. You currently have two functions, say finance and marketing, that currently total 500 users and now you have to bring on manufacturing and logistics that will have 450 users. You have to nearly double your user base in whatever timeframe you have been given and then grow it again and again.

The four major areas that pose a challenge to BI directors or managers in dealing with large increases in growth are:

Security – Creating a security model that can accommodate all future growth may not always be possible. The best you can do is to become well versed in Cognos security and then structure your security model around the core principals on setting up Cognos security. Practical experience goes a long way here. For Cognos administrators this is far and away the largest pain area that they experience. Work to create a model that can accommodate change and growth.

Training – Probably the most under invested area of Cognos BI deployments is user training. But training that is well structured and delivered has an incredible ROI. It not only makes it easier for users to get up to speed in terms of using the tools, but the big payoff comes from them being better able to make better business decisions which is what it’s all about. Just being able to share common business information across and between functions has a huge payback. Trying to cut corners here does not make sense. Give users the training they need and also clearly spell out any rules or guidelines around personal folders, saved output, etc.

Personal Content – Once a BI environment has been in place for any length of time the amount of content in personal folders will significantly exceed the amount of public content in the Content Store. In fact, the strategy of many organizations today is to have users create their own reports rather than have authors or developers write reports for them. This strategy can work, but if you don’t have some rules in place here you will likely see this area explode over time. If each user creates 5 new reports per month, and never eliminates any, what happens? Run the numbers; the results may surprise you.

Another factor compounding this issue is the ease with which users can now create content on their own. Every new version release of IBM Cognos BI has made this process even easier and Cognos 10 is no exception.

License Management – Unless you have an enterprise licensing model the task of tracking licenses is another challenge you have to deal with. This can be difficult depending on your license model and how it is deployed. We have covered this in a previous blog, Counting IBM Cognos Licenses, which you may want to read. The best advice is to try and get out in front of this issue early and stay on top of it. You may need to look for a solution that can help you in this area.

Be prepared

Those organizations that have had to deal with growing in large increments have learned how to address some of these issues. After the first large increment it may get easier if you have been able to take the learnings from it and build them into your planning for the next one. But there will always be some surprises that you did not expect. The best advice is to focus on careful planning and flawless execution. Anyone got any other issues that they think need to be addressed in dealing with large incremental growth in Cognos BI? Share it with us and other readers in the comments section.

Photo by Ben Heine

Counting IBM Cognos Licenses

Wed, 10 Nov 2010 15:53:00 GMT

By Gary Larsen - Envisn, Inc.
The purpose of this article is to help the Administrator determine how many users have access to licensed capabilities in IBM Cognos and identify who they are.

One responsibility that generally lands on the IBM Cognos Administrator is to monitor the use of each purchased Cognos license. This is required to both maximize the utilization of the licenses and to make sure that your organization is in compliance with the IBM Cognos license agreement.

Licensing IBM Cognos BI - Types and Capabilities

A common practice in the sales cycle is to be presented with bundled license options. The bundle names can change but are used to simplify the calculation of your license requirements. For example, a BI Professional Author might have access to the Query Studio and Report Studio. A BI Professional Analyst might have access to those studios plus the PowerPlay8 Studio.

The first step in managing Cognos licenses is to translate the various bundle names into a count of the actual capabilities (if this has not already been done in the Cognos license agreement).

Using the simple examples above, 10 Pro Authors and 5 Pro Analysts would translate to the following capability counts:

Query Studio 15
Report Studio 15
PP8 Studio 5

Understanding Capability Permissions

Access to IBM Cognos capabilities is defined in the security tab of IBM Cognos Administration. Within the Capabilities section is a list of Secured Functions, some of which will relate to the license types (Analysis Studio, Cognos Viewer, etc.) and others which do not, such as the ability to Schedule objects.

Some Secured Functions have children of type Security Features for more fine grained control. The Report Studio function, for example, has a Bursting feature to control who can edit and run burst reports.

Access permissions are defined in the properties page of the function or feature. A user must have both Execute and Traverse permissions in order to perform the feature or function.

Granting Permissions with Groups and Roles

While it is possible to grant individual users (accounts) access to capabilities, groups and roles are generally used for this purpose as it makes the management easier. Using the earlier example, a Pro Authors role could be created and granted access to the Query and Report studios. Accounts added to the Pro Authors role would gain access to both studios.

This is a rather simple example as security in most IBM Cognos environments use a combination of both Cognos and external namespace groups and roles and can get complicated very quickly. This is described in detail in a series of blogs:

http://www.envisn.com/envisn-cognos-blog/bid/43351/Mastering-IBM-Cognos-Security-Part-1

Counting Capability Access by Account

So there must be an easy way to get a list of all the accounts which have access to Report Studio, right?

Well, this really depends upon the complexity of your security environment, but generally answer is no. Let’s look at a few scenarios to get an idea.

a) A single external group contains all the accounts which should have Report Studio access. In this case we could just view all the members of the group in IBM Cognos Administration.

b) A second external group also needs this access. We can view those members also, but there could be accounts which are members of both groups which should not be double counted.

c) A Cognos role is created and used to set access to the Report Studio capability. The two external groups are then added as members to the Cognos role. Now the accounts are two levels removed from the capability making them even more difficult to count.

With some effort it is possible to navigate through all the hierarchies of groups, roles and accounts and manually build a list of account capability access. This approach may be manageable in some environments but in a large and/or changing one this would be tedious and time consuming.

Using the SDK to find Members

One solution to automate some of the data gathering for license counting is to use the IBM Cognos SDK.

One example is to return members of a Cognos or external group/role. This is done using the query method with the search path of the group/role and setting ‘members’ as one of the properties to be returned:

query(searchPath, properties, sortBy, options)

There are also some very useful functions which can be used in the ‘searchPath’ parameter of the query method. One of these is the expandMembers() function which will recursively expand group and role memberships returning a list of accounts.

But none of these are easy or automated and can get progressively more difficult with growth and changes over time.

Cognos Technical Partner Solution

NetVisn is a comprehensive administration solution for all IBM Cognos BI environments. One of NetVisn’s many features is to dynamically keep track of changes and accurately report (real time) on all aspects of Cognos security including capability permissions and thus, Cognos license counts.

Photo by Serge Melki

What’s New in IBM Cognos 10 - IOD 2010

Wed, 03 Nov 2010 14:05:00 GMT

By Rick Ryan - Envisn, Inc.
At IBM's annual Information on Demand (IOD 2010) event in Las Vegas last week the big news was the introduction of Cognos 10. Is this a big deal? We'll let you decide. How you feel may have a lot to do with whether the new things are important to you and your organization.

IBM Cognos 10: The Big Picture

IBM Cognos 10 is the first major BI release since Cognos 8 was released in 2005. Cognos 10 presents a more integrated user interface along with a broader offering of analytics and technology. The recent acquisitions by IBM of SPSS, TM1 (Applix) and Clarity are now part of the offering.

Broader Scope of BI

IBM Cognos 10 is a bold move to broaden its scope beyond BI to include group decision making, integrated statistics and mobile BI. The goal is to focus on integrating a broader role for BI into the decision making process with the ability to actually record and track decisions and then measure results against them.

Cognos 10 is also a move away from role defined capabilities and the whole issue of "studio clutter" that confused some of its BI users in the past. Business Insight as it's called, enables users to aggregate and organize BI with analytic and planning content within a unified interface. Users can access increased functionality without having to change studios or interfaces. This seamless slide into expanding functionality is virtually unnoticeable in actual use.

Why Cognos 10 and not Cognos 9? The most consistent answers here centered around two areas; First, it's considered a major release and thus warrants being a 10 not a 9. And second, TM1 (Applix) already has a 9.x release on the market.

New Things in Cognos 10

Life Cycle Management is the capability to handle upgrades from one version to another. They made a big deal of this at last week's event. No doubt in an attempt to pre-empt the groans from those in the audience that remember all too well the pain associated with version upgrades in the past. It appears that they have done a lot of work to make this process uneventful. Plus, it's now possible to run reports and queries in both Cognos 8 and Cognos 10 at the same time and then compare the processing differences. This should reduce the testing needed in version upgrades.

Dynamic Query is a new feature that results from performance enhancements. With this feature enabled, reports, queries and cube building are shortened. This is done by caching and query routing techniques. Results indicated performance improvements of up to 30 to 40 percent.

Statistical Integration is the result of SPSS being integrated into the analytics umbrella of Cognos 10. Based on what I saw, the future of this looks impressive indeed. SPSS has added a Modeler capability making it easier for non-statisticians to benefit from predictive modeling in a much broader business context. increasing the potential for improved business performance. Those with the skills to harness its power can get some big benefits quickly.

Active Reports allow users to receive self-contained interactive reports by email. This extends the reach of BI to mobile and offline workers that can work on these active reports and perform what-if scenarios if required. Mobile workers are the fastest growing market segment for BI and making it easier for them to work anywhere keeps the market growing.

Platform Enhancements designed to make life easier for those that have to support the platform. These include optimized query generation, life cycle management and performance enhancements. As BI environments have grown in size throughput has become more of an issue. These enhancements help minimize potential bottlenecks as more users are added to the environment.

Social Networking is achieved with the integration of Lotus Connections and Business Analytics. With IBM Cognos 10, key information can be shared by groups or communities and forms the basis for decision making that connects people to the event. All of this is captured and used to improve decision making practices.

Is IBM Cognos 10 Worth the Wait?

What was announced at IOD 2010 required a great deal of work by a lot of people to pull off. The new user interface along with better integration of increased functionality is impressive. For users it will make the Cognos experience much smoother and should also scale well. The response from the customer base seemed to be very positive with a lot of users anxious to try it out.

Cognos 10 - To sum it all up:

Broader role for BI - BI has now become Business Analytics.
More unified user interface with integrated analytics.
Improved performance and platform enhancements.
Social networking that enables collaborative decision making.

Note: Not a lot of information was available on licensing details around C10 or what current users might face when upgrading from their current license mix. In response to questions asked about this, it was recommended that users contact their account manager for detailed information.

Photo by PSD

Cognos Security – How It Gets Messy

Mon, 25 Oct 2010 17:20:00 GMT

By Rick Ryan - Envisn, Inc.

“If you think about, it gets all messed up.” – Yogi Berra

Yogi Berra wasn’t talking about IBM Cognos security when he made that comment but he could have been. This article will cover the whole process of security and its ongoing validation.

What happens in many environments is that although they may start out with a clear structure and plan for how security will be implemented and evolve over time, it just never seems to turn out as planned. It just gets messy! Most environments begin with a couple of hundred users and a small number of groups, and as they evolve over time, the original security structure just collapses under the weight of its own complexity.

Security Ambiguity

Often it starts out without a clear understanding of how groups, roles and accounts are designed to be used. Most security is implemented in Cognos BI by simply bringing/dragging in group(s) from an existing external source. These groups contain the users who are assigned by the security team which may or may not be part of the BI team. This will cause problems due to the complexity resulting from the separation of groups to users and the direct assignment of groups to content and/or roles. Bottom line, there is no direct link available from the secure content to an actual user, as represented by the dotted line in the adjacent diagram.

Groups get connected with Cognos content and roles (shown in blue) which then compounds the difficulty of being able to easily understand which users have access to specific content and why, or even what, privileges they have for any given content. This is a critical point in the process. If you don’t get it correct here it only gets worse over time. And without an effective tool to make security totally transparent, there is no way to for Cognos administrators to validate security. This is truly a black hole and the source of endless frustration for administrators.

Even the best IBM Cognos security model is vulnerable to the two things that inevitably occur overtime; growth and change. Growth occurs naturally as new users are added to existing groups but it can also occur when new units (departments, divisions, etc.) are added to the mix. New users will likely come with their own profile definition. If there ever was a clear plan or model for security initially, it’s now gone after a few unplanned additions over time. It will become increasingly difficult to understand, manage or accommodate security with future growth.

Major changes in your Cognos security will also come as your organization changes to meet evolving business needs. This further complicates managing security in a large Cognos environment. This will get to the point where there are large amounts of orphan content, users in the wrong groups, and groups with no users in them, etc. When this happens often the only alternative is to restructure security into a new model that is flexible enough to accommodate both current and future security needs.

Security Makeover

Designing a new security model may not be too difficult. Implementing it can be another story. Here the biggest challenge is to make sure it’s still ‘whole’ when you are done. It’s a bit like taking your car apart to fix something only to discover that after you’ve put it back together you still have parts left over. Not good.

A good way to handle a security model makeover is to begin with a complete matrix of your existing security structure. That is, assuming you can put one together. The next step is to create a new security model that reflects your current needs but can accommodate future requirements as well.

The obvious question will be: How can I plan for future needs if I don’t know what changes will be required? True enough, but with a clear understanding of how security works in Cognos BI you can go a long way to creating a security structure that will handle change over time and can avoid creating a messy security model. Some of our previous blogs on Cognos security cover this in a clear, straight forward manner. You can find these at http://www.envisn.com/envisn-cognos-blog/?Tag=Cognos+Security

Once you’ve created the new security model the next step is to do a walkthrough of what goes where. You will likely find some things that need to be addressed. Following this, your next step should be to use your test environment forthe testing and validation of the new security model. This is not something you want to take any shortcuts with. Once the testing is successfully competed you can complete the final step of implementation.

In summary, the main steps of a security makeover are:

Document the current security model.
Create new security model. Keep it as simple as possible.
Map current model to the new model and do a walkthrough of what goes where. Add, eliminate or change as necessary.
Implement the new security model in your test environment and validate it.
Implement in your product environment.

One final point here is important. The people that administer your Cognos security really need to know your security model completely and to make sure it’s followed when adding users, groups or content. With some luck you can keep you Cognos environment from becoming messy.

Download the Ebook:
Mastering IBM Cognos Security

Cognos Scheduler Options: Cognos Scheduling, Part II

Fri, 15 Oct 2010 05:22:00 GMT

By Elwood Philbrick - Envisn, Inc.
In our previous blog on the subject of Cognos Scheduling, we reviewed the basics of scheduling in a Cognos environment. Over time, many environments will get to the point where their needs have evolved beyond basic scheduling. The major drivers behind expanded requirements for Cognos scheduling are:

Reducing complexity – Using home grown scripts or other utilities you’ve created can only take you so far before they become too unwieldy to use for creating more jobs.
More throughput – Your present scheduling capability just isn’t scalable for adding more jobs.
Frequency – Increasing the frequency of your production streams may not be possible with what you’re currently using. Going from monthly to weekly or weekly to daily, for example, will create its own set of new requirements.
Performance – Here the drivers are usually improved quality (reduced failures) and better on time delivery of scheduled output.

Buy or Build?

As you begin to ponder how to address your scheduling needs you essentially have two options; Build a more robust scheduler for your Cognos environment or look at what scheduling options are available in the market. Those who have taken the route of building their own scheduler usually do so with the goal of getting something that will meet their unique needs. While this can often have some success initially, it can be difficult over time to maintain an in-house application because of changing requirements and changes in personnel. Looking externally for a Cognos scheduler raises the issue of what criteria to use for evaluating it. Some of the obvious things you should look for include:

Simplicity – Creating individual or multiple job streams should be simple and straight forward. This should be a key requirement for eliminating complex, multi-page scripts that are often only understood by their original creator. Plus, the more complex it is the more points of failure it has.
Use of triggers or events – This is the ability to use an event, or multiple events (cascading triggers) to initiate the scheduling of a report or a job.
Robust calendar – It should have the capability to set up your own custom calendar that is specific to your needs. Even an environment with basic Cognos scheduling requirements has a need for a flexible scheduler. You will almost certainly encounter a need for scheduling something that is out of the norm for a standard scheduler.
Flexibility – This includes the ability to suspend jobs or job streams easily and ideally be able to do it with a suspend start date and a resume date.
Independent jobs – A good Cognos scheduler is one that enables you to structure your production streams as a collection of independent jobs so that if one fails it does not impact other jobs. How this is done can also be important since there are techniques that can be used to minimize the possibility of a job failures, and thus, a higher success ratio over time.
Error detection and logging – this can be an important consideration for nearly every Cognos environment that has a need for an automated scheduler. Not only will this help isolate the impact of errors, but logging makes fixing them much easier.
Machine throughput - Whether you’re using a single server or multiple servers, being able to maximize throughput is essential. In a multi-server environment having a Cognos scheduler with automated load balancing will help keep your production window as small as possible while optimizing machine resources. You may even want to have the capability to run certain large jobs on specific machines that have more processing power and RAM. Smaller jobs can be aggregated onto smaller machines.
Parameters – This is nothing more than using an alias for things like file names, locations, passwords, etc. that are subject to change over time. Using parameters for scheduling eliminates the tedious and error prone process of having to manually update jobs when they change.
Job history tracking – Keeping track of the success/failure rate of jobs will help reduce failures over time. And tracking how long jobs take to complete will help you identify potential problem if you begin to see job times lengthen over time.
Scalability – You may have a small number of jobs now but being able to add new job streams quickly and easily when needed should not be a big deal.
Web access – Being able to access your scheduler via the internet can be an important factor. Some environments have a need to schedule or monitor production streams remotely, often on weekends or holidays.

Having a Cognos scheduler that will meet your current and future needs is critical to meeting your customer’s requirements. The number one BI customer issue typically is lack of on time delivery. With the right one, things automatically happen on time. Without it, you’re always behind the curve having to deal with unhappy and frustrated users.

Cognos Scheduling – Part I

Tue, 12 Oct 2010 14:12:00 GMT

By Elwood Philbrick - Envisn, Inc.
In this article we will cover the basics of scheduling in a Cognos 8 BI environment. The basic challenge is getting the report or cube you want, where and when you want it. In a typical Cognos 8 environment scheduling a report, query of PowerPlay cube usually starts with something that looks like this:

Process Overview

An assumption that is often made in scheduling a recurring report is that the data are refreshed by the time the report is run. But generally the reports you want to schedule will come after your data source(s) has been updated via the ETL (extract, transform & load) process. See the diagram. Once this has been completed successfully you can begin the report creation process. In many environments there will be two parts to this: reports, queries, jobs, etc. and PowerPlay cubes. When this process completes successfully the results are available for the customer.

With the ETL process you have to be sure that it completed successfully. Because many environments may have multiple data sources verifying this is an important step before the Cognos report or cube build process begins, otherwise you can be creating incomplete and/or inaccurate reports and cubes. When this occurs the rollback process can often be painful and time consuming. What is often done here is to create flags or files whose presence can be used as a signal that ETL completed successfully. These are often used as an event or trigger to kick off a report or query build.

Scheduling

Scheduling reports with Cognos scheduler in C8 gives you the option of running a report based upon a fixed date and time; by day, week, month, etc. You also have the option of scheduling it based upon an event or trigger. For many users this may be more than adequate for their needs. Some environments may require more options to meet broader needs. This may include:

More flexible scheduling options including what you would get with a calendar that allowed you to make custom schedules. Once you get beyond standard day, week and month scheduling you often see the need for highly specialized scheduling options to accommodate unique requirements (eg, fiscal calendars, etc.).
The ability to deal with multiple triggers. The use of a single trigger may not be sufficient to kick off a job that has a need for multiple conditions to be met. These are sometimes referred to as cascading triggers.
The reports scheduled this way are all independent events. Each one is going to get done base on its own scheduling parameters eliminating the possibility of building a job stream(s).

Scheduling Cognos PowerPlay cubes is a whole different matter. Here there really isn’t anything that comes with Cognos 8 that you can use right out of the box. What most people have done is to build their own routines for scheduling Cognos PowerPlay. This usually done with batch files or scripts that spell out all of the details of what needs to be executed to build the cube. These can become very detailed and involved (read long) since they may spell out unique file names, task sequences, etc. Where multiple cubes need to be created these scripts can often be somewhat overwhelming.

Scheduling batch files may be done with the Windows scheduler or something similar. There are many mid to large environments that are running today in this manner and getting along. But some of the issues they often run into include the following:

Managing change can be difficult. Since each script is unique it has to be changed whenever the parameters around that specific cube build change. This can become very tedious where there are a large number of batch files. An example here is going from one version of Cognos to another.
Personnel changes over time make the process of managing change difficult. When the person that originally wrote the batch file is long gone it can be hard for someone else to update it. Thus, this gets even more difficult over time.
There is little or no possibility for error detection with batch files. They either work or they don’t and the failure of one can be the failure of all.
No performance tracking (thru put, success-failure rate, etc.). Since the processing time for many cubes grows over time this can be an issue.
No possibility of load balancing and/or doing mixed builds over multiple servers where there is a large number of cubes.

We do not want to give the impression here that it’s a lost cause. There are alternatives to using the Cognos scheduler and rolling your own cube build process. In the next blog, Cognos Scheduler Options, we will discuss alternatives and what you need to consider as you take a long term look at your needs.

Cognos BI - The Case Against Complexity

Fri, 01 Oct 2010 19:44:00 GMT

By Rick Ryan - Envisn, Inc.
It’s almost as if there is some immutable law that dictates that as things become larger they become inherently more complex. There are certainly enough examples around in government, corporations, and universities to support this. Nobody starts out planning to make things complex, but like they say, stuff happens.

So what’s wrong with complexity? If it works and it’s complex what’s the big deal? Complexity in and of itself is not a problem. But as we know from a systems design perspective, the more complex it is the more points of potential failure it has. And in many cases, especially in the business intelligence world, complexity is associated with a number of negative attributes. Some of these are high support costs, unhappy users, the inability to effectively manage change and a failure to meet defined service levels.

In the decade plus that Envisn has been in business we have seen literally hundreds of different BI environments and most of those that are complex, and either totally or somewhat dysfunctional, share some similar characteristics. Some examples:

Company A – Has 250 users and over 30,000 objects in their Content Store. This is an example of unbridled Content Store growth that would be hard to match.

Company B – User base of 1,500 with only two or three Framework Manager models each having over 20,000 items in them. They simply carried over the large catalogs they had in Series 7 into the Cognos 8 world.

Company C – Has both a large internal user base and an extranet that its clients use. Managing security is a nightmare since when things started it was applied at the wrong level and evolved from there to become increasingly more complex.

Create a Plan

As seen above, the first major cause of complexity results from not having a plan. And here we are using the term plan in its broadest sense. We’re talking about a Cognos BI environment but this is no doubt true of any BI environment. This would comprehend a plan for creating and/or managing a BI environment that includes:

1. Organization and structure:

a. Defined user base
b. Content ownership
c. Folder organization
d. Security model
e. Training – standard and custom

2. Governance

a. Roles and responsibilities
b. Managing growth and change
c. User collaboration and input

3. Support:

a. Defined support tasks
b. Defined support roles for administrators
c. Defined support processes and metrics

4. Rules:

a. Defining and deploying standard reports
b. Change control and management processes
c. Saved user content
d. Other – (think of things you would change in your BI environment)

Here, most of the negative aspects of complexity result from the failure to create a plan and to then consistently manage to it over time. Things tend to wander off course and then it gets messy. But, as someone once said, if it was easy everyone would do it, and they don’t.

Use the Right Tool

The second major cause of complexity is not using BI for what it is intended for and here some examples include:

Using BI systems to do what is essentially ETL work. BI was not designed to be a data transformation utility. It does these things far less well and with less efficiency than applications designed for this purpose.
Overly complex reports. In one case we saw reports whose documentation specs were nearly 100 pages long. Basically they were using individual reports as mini applications. These were hard to design, hard to troubleshoot and hard to change.
Using BI to manage operational work flow. In this case the customer is using BI to manage work crews operating in the field over a multi-state area. It works reasonably well but has a high support cost relative to an application designed specifically for that purpose.

Here it’s the right tool being used for the wrong purpose but changing this can be very difficult. The way things are done, how things work, what users expect, etc. almost get set in stone and are very hard to change. In both the cases cited above, if it is possible to effect change, it comes in very small increments and then it’s nearly impossible to get out in front of actually reducing complexity without drastic and often painful steps.

Building a Cognos Audit Monitor

Fri, 24 Sep 2010 15:30:00 GMT

By Rick Ryan - Envisn, Inc.
In our recent posts to the Envisn blog one of my colleagues, Eugene Marcotte, shared some of his learnings on the Cognos audit logs and the data tables. Our work with them goes back a while since we use this data in some of our current products. Recently though we took on another challenge dealing with Cognos audit data. Our customers have been giving us feedback on their needs in terms of managing change in their Cognos BI environments. This includes capturing change data with a level of detail around change type, date/time, who, etc. Much of this is driven by audit or compliance requirements for SOX, HIPPA, etc. or simply to mitigate security risks.

A short disclaimer. We make a conscious effort not to use the Envisn blog to tout our Cognos BI admin solutions. Our feeling is that our blog should be a place to share knowledge about the challenges faced by Cognos BI administrators, authors and those whose primary role is to support the Cognos infrastructure. We will continue to do this but feel it’s worth sharing some of what we learned in the process of developing the Audit Vault capability within our NetVisn product.

Scoping the Project

Working with some of our customers we came up with goal statement around capturing changes within Cognos BI. The list includes the following:

Capture every action on every object in the Content Store
Identify when it was performed and by whom
Do this with 100% accuracy
Make this information easy to use and consume
Retain object change history for and beyond the active life of the object

Other things could be included in the list but these are the overarching goals for what they wanted to be able to do.

Reality Check

The Cognos audit log Action table has 18 columns that among other things contain the following:

Date/Time
Action type (add-delete-modify and others)
Display path
Session ID
Request information
Error status field
Dispatcher information

User name comes from another table in the audit log.

It may or may not be obvious to you but something important is missing from this list. The name of the object is not part of it. Arguably the single most important thing you need to know and it’s not on the list of what’s available. This presented a major challenge. There are three action types that are important from a metadata change perspective.

These are: add, delete and modify. It’s obvious that most of the action is in the modify area. There are literally hundreds of possible changes that can take place on objects since Cognos offers such a broad set of attributes and options. Plus, some actions that relate to an object are not captured by the Cognos audit log but yet need to be identified and captured for a complete object change history. This became the second major challenge.

We found ourselves in a situation where what we were trying to do was conceptually very simple, but difficult and challenging in terms of execution. This then led us to a long and deep process of discovery of what could be used to offset the gap between what is provided by the audit logs and what was required to meet the goals we set. Where a number of alternatives were possible we had to find the “best one” which in nearly every case was not the easiest one.

Outcome

The solution to closing this gap led us to focus on the following areas:

Fully maximize the data we do have available to work with, how it is currently being used and how it can be extended. We had to create processes that fill in the blanks in terms of completeness without compromising accuracy.
Focus development on building a platform that is rock solid in terms of change capture. Traceability had to be part of the process.
Keep overhead to a minimum in terms of any additional processing. Where additional steps were required they should serve multiple needs if possible.
Think both in terms of both current goals and likely future needs. This is always hard to do but knowing how it can be used in other ways is always helpful.

This helped us address both of the major challenges we faced; uniquely identifying every object and capturing all actions that occur. The first one had to be resolved successfully before we could proceed with the second one. But what was interesting was thinking we had completed the first one was less true than we initially thought since the learnings from capturing all change actions helped us come up with an even better process of uniquely identifying objects.

Were we successful? At this point we have essentially met all of the goals we set for the project. Alpha testing is currently in progress as this is being written and beta testing will commence in two to three weeks. The feedback so far from the customers we have shown this capability to has been very positive.

Utilizing Cognos Audit Table Data

Thu, 16 Sep 2010 14:15:00 GMT

By Eugene Marcotte - Envisn, Inc.
In my last article I discussed the Cognos audit tables – what they are, what they contain and I provided a link to the sample Cognos Package that can be used to start reporting on events within Cognos BI. This is very useful to have sitting in a Cognos environment because it lets you quickly build administrative portals, using the provided reports, to help monitor what is going on in your environment. Not only that, because you have a package, you can build new reports off of the data if you find yourself needing something that isn't in a pre-packaged report. There is a limit, of course to how much info you can derive from using the audit tables directly, but it is a start.

There are other uses for the audit data. It is a relational database and can be connected to from any sort of software you may have for dealing with databases. For instance, when I am doing some work to try and debug code in our NetVisn product I often find myself needing to see a log of the actions that occurred, with their specific values in the database. I can fire up Microsoft SQL Server Management studio, paste in one of my queries with some custom joins, and view event history filtered, sorted and joined however I like – without having to go through the steps of making sure the Framework Manager model had it all.

Additionally, being a programmer I can query it programmatically. The beauty of this is that I can build real time monitoring tools to watch the database. For instance, I recently built a hack app to watch my development database. Here's a little screenshot:

The program is simple, it just has a background thread that keeps checking to identify if there are any new events in the action table and adds them to the top of the list. I can use this to watch for any new or strange data that needs further investigation. This screenshot also highlights one of the unfortunate parts of working with the audit data “as is’ – it is very irregular. For instance the 2nd and 4th lines should have some sort of text after the “->” but the table simply doesn't have any data there. Additionally note how the first and last lines appear to be the Cognos SDK search path syntax, but the middle row is a display path. These are just some of the issues one has to deal with building tools like this using the Cognos audit data.

Another way you might use this data is by building tables that join to it. For instance, you may have some 3rd party database that you wish to associate records into the Cognos audit database. You can build a mapping table between the two to easily join them. Additionally, you could then build a Framework Manager model to begin reporting on the joined data.

This is somewhat similar to how the UniVisn product works by keeping track of additional information about objects that can be joined with the audit tables to produce broader reporting capabilities about your Cognos BI environment. If you think of the Cognos audit tables as a starting point there are a number of useful things that can be done with the data.

Understanding and Using IBM Cognos Audit Data

Fri, 03 Sep 2010 14:45:00 GMT

By Eugene Marcotte

Background

Large complex software systems often have logs for various information that can be useful for debugging, data mining and analysis. When an application or a system crashes often the error is found in such a log. When performance becomes an issue, the logs can often be useful to try and understand what is going on with the system so you can figure out how to react.

IBM Cognos is no different. There are many different types, targets, and levels of Cognos logging. It has the basic things like error reporting and timestamps which can help isolate performance issues, but it also contains a few other things. For instance, it can tell you when reports were run, when users logged on, when changes were made to objects and many other things. Using this data you could start collecting statistics about how your environment is used and keep track of what is happening without resorting to guessing.

The IBM Cognos Administration and Security Guide has some fairly detailed information about how to set up and use the Cognos logging facilities. This documentation is mostly aimed at administrators, but it is useful for planning how to lay out your environment as well, since you have to make more choices about where and how you store the log data.

By default there is only has one Cognos logging target for “File.” This set up has the various Cognos components logging to cogserver.log. This file log is useful for administrators since it can be used with some standard administration tools like “tail” to watch the log as events occur. It is not a very useful format for doing analysis and reporting, however.

The logging configuration in Cognos Configuration can be configured with multiple different targets of various types. In addition to the File type mentioned above, it can be configured to write to the system log, a named windows event log, or a SQL database. Using an SQL database will let you then consume the data using the Cognos tools you're already familiar with and using – Framework Manager, Datasources, and Report and Query Studio. Cognos even provides a sample package for doing reporting against this database. They provide a handful of reports which can be run to start understanding who, how, and when your Cognos environment is being used.

There is quite a wealth of information hidden in these tables. There is some Cognos documentation about what the tables and their data available for reference. Basically the types of events are split out into various tables.

Cognos Tables

Cognos User Logons Table

This table is fairly obvious: it captures the log on and log off event for people accessing Cognos. This includes Framework Manager, Cognos Connection, and third party SDK using applications. It also includes “timeout” information for when a session is not explicitly stopped and instead is terminated after a set period of time. From my research, it seems that shutting down Cognos will result in unbalanced logins. This means sessions could have a logon, without a time out or log off.

To enable this table your Content Manager service needs to be set to at least basic logging.

Cognos Action Table

The action table is often ignored by people using the audit tables. It acts as a log for operations performed on Cognos content store objects. This includes making querying for or making changes to objects in the various studios, Cognos Connection, or third party applications. It can tell you which session – which can be tied to a user using a join – performed which type of action (update, add, move, etc) on which objects.

The objects, unfortunately, are listed as a sort of display name. This makes the audit data difficult to use when tracking the history of an object, but easy to use for building simple reports. Another limitation to this table is that operations that affect multiple objects only show one row. For instance, if you select multiple objects' check boxes in Cognos Connection and click delete, you will only get an entry for the first.

Here again, to enable this table your Content Manager service needs to be set to at least basic logging.

Run Report & Review Report Tables

Using these tables you can figure out who, when, and which reports are used. This is useful if you want to figure out which reports are taking the most time to run, which reports are most frequently used, or other information such as if your saved output is being used or if runs are being done each time. These pieces of information can be critical in determining how to deal with performance issues in a Cognos environment.

To enable this table your report service needs to be set to at least basic logging.

In a future article we will share with you how some of this data from audit tables can be used in creative ways.

Mastering IBM Cognos Security Part 5

Wed, 01 Sep 2010 14:29:00 GMT

Best Practices for Implementing IBM Cognos BI Security

By Gary Larsen - Envisn, Inc.
(A series of blogs on understanding and managing security in the IBM Cognos environment)
If you have read the previous blogs in our Cognos Security series, or are already managing an IBM Cognos environment, you know how complex controlling user access can be. But it can all be summarized by these two goals:

Secure sensitive data from unwarranted access, but allow the necessary data to be available to all business intelligence consumers
Control access to Cognos BI capabilities, both globally and package based, so that content is created and distributed by approved authors, and that Cognos license limits are respected.

The best practices described here may not be the best in all environments but will hopefully help those new to Cognos BI or for those about to refactor how Cognos security is set up.

There are no set rules for the weighty task of implementing IBM Cognos BI security, so any feedback or alternative suggestions anyone can provide here is very much welcome!

Use Existing Groups

If your external security is also used in a corporate environment the chances are that the accounts are maintained in an organization of groups. Study this organization to see if it can be used to control access in Cognos, probably to content.

Instead, you may be using an external security specifically for Cognos, such as Cognos Series 7. Because an account must belong to a group in Series 7 in order to be recognized by Cognos Series 7 BI, you have a couple of choices:

Create groups in Cognos security to organize accounts that will be used to control access in Cognos, either for capability or content, though probably the latter.
Add all accounts to just a single group and manage all access using the Cognos namespace groups and roles.

Groups or Roles

Group and role objects in the Cognos namespace behave almost identically. The difference is that groups can contain only accounts and other groups, while roles can contain accounts, groups and other roles.

Organizing multiple groups in a role could get complicated very quickly, but it may make sense if you use the role for broad access control and the groups for limited access.

A simpler rule to follow would be to use roles to control access to capabilities, and groups to manage access to content.

Managing Content Access

The design of security access to Cognos BI content first requires an analysis of the types of business data available. Generally data will be organized at a high level by business unit or functionality, such as order processing or finance. Data may then be classified by employee position. For example, managers would have access to payroll detail reports but clerks may only view high level reports.

One solution would be to create a group for the business unit (Payroll Unit) and groups for more limited access (Payroll Managers). Managers would belong to both groups. The reports which all payroll unit employees can view would use Payroll Unit for security and limited access reports would use Payroll Managers.

You will also need to manage read and write permissions to the BI reports. One method would be to create separate groups; for example, Payroll Unit Consumers and Payroll Unit Authors. In this case, both groups will be used on report security but the access permissions would be set according to how read and write permissions are aligned.

Managing Capabilities

Capabilities are used in Cognos BI to control access to features and functions such as the reporting studios and administration tools. There are a number of default Cognos namespace groups that are created during the Cognos installation that have certain capabilities defined. For example, Authors and Query Users have access to Query Studio, but Authors also have access to Report Studio.

I would recommend that new roles be created to manage user capabilities that match the distribution of your Cognos licenses. For example, a role could be created for power users to access all studios and another role for users which only need a PowerPlay license.

The advantage of organizing capabilities this way is that it makes it easier to manage your Cognos BI licensing compliance.

Download the Ebook:
Mastering IBM Cognos Security

IBM Cognos BI Administrator Best Practices

Tue, 24 Aug 2010 14:55:00 GMT

By Elwood Philbrick - Envisn, Inc.
This blog focuses on some of the best practices used by Cognos BI administrators. Most of these have come from some of the key members of our support team and our development team in their interactions with customers over the past couple of years. This list reflects those things that have a relatively high frequency in terms of comments and feedback.

Simplify Security – You should make every effort to keep your security as simple as possible but still consistent with your business needs. While having the forethought to be able to establish a security model that meets both your current and future needs for some time may seem like wishful thinking, you can go a long way to meeting many of your requirements with some planning. It’s probably worth your time to do some modeling of how to best implement security based on your current needs. What growth do you see over the next year or two? Will there be more groups coming into your Cognos environment that have different security requirements? How is it likely to change? What you want to try to avoid is implementing a security model that may be overly complex and that will constrain you in the future from being able to meet changing business needs without major rework.
Monitor Content Store Growth – Is your Content Store growing fast? There are two things that are the primary drivers of your Content Store size. The first is the number of objects that are in it. These are things like report specs, models, etc. and can be both public and personal. These typically grow at a predictable rate in most environments. The second is saved output or the results of reports that have been run and saved. This can also be both public and personal. Saved output is typically what accounts for most of the size of a Content Store, and in many cases it is often out of control. Users may have saved the output from many reports over a long period of time and it can quickly become the major user of storage resources.
Set Retention Rules – Directly related to item 2 above, you should have some rules in place on the amount of saved output that can be retained by users. This has to be a balance between business needs and what makes sense. Many admins have found that it makes sense to set these to a reasonable limit and then expand it when necessary on an exception basis.
Make Access Easy – Make it easy for users to find what they are looking for in Cognos Connection. Give some thought to how folders are labeled and structured. They should clearly be labeled in a way that reflects that content in them. Encourage authors to use labels or titles for reports that convey what the content of the report is. “Daily Order Details by Region” gives you a pretty good idea of what’s in the report.
Monitor Content Usage – Keeping track of what’s being used and not used in your environment is important. One of your goals should be to give users the information they need to meet their business goals. Having the right reports that are being used for the purpose they were created is a big step in that direction. It’s also important to know what content is not being used so it can be reviewed against its original needs and eliminated if not needed. After starting to track usage one of our customers found that the division that asked for the most new reports had the least usage of them. Another important reason to do this is that if you roll out a new set of reports or add a new business unit you can monitor its usage rate immediately and if it is not being adopted as expected you can take steps to address the reasons.
Listen to Users – Effective Cognos BI administrators usually have a good idea of how the users feel about their BI environment. Actively seek out members of your user base and find out what at the things they like, dislike or frustrate them and what would they like to see changed. Administrators are often surprised to learn that some people have just given up trying to get what they need because it’s hard to find things, it doesn’t have what they need, it takes too long, etc, etc. Nothing can improve the utilization rate like asking for real feedback and then doing something with the results.

We will continue to post more Cognos BI best practices on an occasional basis.

Planning A Successful Cognos Migration

Fri, 20 Aug 2010 14:49:00 GMT

By Kathie Davis - Envisn, Inc.
This BLOG will focus on planning and executing a Cognos BI migration between versions. Most of these recommendations are broad enough to be considered for all types of migrations. In approaching a Cognos migration there are three 3 different techniques that are usually considered.

The first method is what I refer to as “Lift and Shift” aka throw it over the wall and hope it works. The second method is starting over, this method has a bit of a “I know what is it best for you” undertone. This typically comes about when the implementers are not part of the day to day operations and have little to no experience in the legacy application. The last method the more rational approach is aptly named the hybrid approach. This method falls right in the middle of lift and shift and starting over. The hybrid method will result in an efficient, well designed and executed migration.

Let’s take a closer look at the three methods:

First method “Lift and Shift”.
- Lack of information to understand the current implementation.
- No tools to be able to help you understand the legacy environment.
- You might be a little afraid of what might happen if you did make changes or eliminate content.

This approach assumes that your BI Consumers need all the reporting replicated from the legacy environment into the new environment. This will not take into consideration whether or not content has any future value or has become obsolete over time. This lacks good judgment. This is analogous to buying a new house, planning the big move, and then moving everything from one location to the other. I mean everything! This means you don’t clean out the garage, everything in the attic gets packed, and of course and why not move the garbage too. You never know what you might find in there of use!

The real question is, why would you ever want to do this?

This approach can work, my concern is that you are implementing an old design on a new platform. At best you will be able to get original implementation to run. However it will be force fit and more than likely not a very good fit.

Second method starting over.
- Requires unnecessary time and resources to re-invent the wheel.
- The discovery phase still needs to happen and you really do need to know what is going on in the legacy environment. This cannot be avoided.
- Time + Money + Effort = 0 ROI

Starting over is not a cost effective decision either. This choice is also based on the lack of information being available to make a well thought out Cognos migration. I also see this kind of migration play out in environments where the original administration support staff is not part of the new implementation team. The essence of what needs to be implemented is within the current environment. By choosing to recreate the world can impact the time line for the implementation and risk user acceptance. It is a lot harder to get your consumers to buy into something that is totally foreign to them.

Third method “hybrid” – a mindful approach
- Scoping phase first this includes usage metrics and metadata review for object moving forward.
- Establishment of dedicated resources (The optimum team should have experience in the existing solution combined with resources which are well trained in the target platform).
- Prepare for a POC by selecting a representative group of reports. (Work out the kinks before you finalize the plan with a small set of reports).
- Decide on the PLAN. DO not have false starts this will not only extend your project but it will also send a signal about the perceived importance of the project.
- Agreed on a timeline have a firm begin and end date.
- Dedicated resources, assigned responsibilities, and success criteria
- This process reflects the minimal handling of all objects that will be migrated.
- Learning from the POC phase will result in a consistency during the migration.
- Having a well rounded team will result in continuity of resources.
- Overall this approach will reduce TIME, cost less MONEY and require less effort.

Why carry the old baggage and why throw away years of work. The plan is to migrate only the content that is truly used and leave the garbage behind. In this approach you will need to document the content metadata for analysis purposes. You will also need to gather usage statistics for content objects going back at least 3-6 months. Use these two essential pieces of information to scope out the migration.

Why this is a good idea.

This process reflects the minimal handling of all objects that will be migrated.
Learning from the POC phase will result in a consistency during the migration.
Having a well rounded team will result in continuity of resources.
Overall this approach will reduce TIME, cost less MONEY and require less effort.

Committed resources and a well thought out approach will result in success. You will be done before you know it!

Envisn's IBM Cognos Blog

Is Cognos 10 a Big Deal?

So since the introduction of Cognos 10 some 15 months ago now, one has to ask the question, is Cognos 10 a big deal?

Summary

IOD 2011 - What's New in Cognos 10

Summary

IBM IOD 2011: IBM Cognos Framework Manager Unleashed

An Innovative Approach to Modeling Complex BI Projects

***************************************************************

UPDATE

Larry has graciously made the slides from his presentation available and you can find them here:

http://www.slideshare.net/Envisn/iod-2011-1724-bob

***************************************************************

A couple of other sessions you might also want to consider attending at the IOD include:

BBI-1672Implementing the System Management Methodology (SMM) for IBM Cognos Administration

BBI – 2723Streamlining the Lifecycle of your Business Intelligence Solution

Managing Multiple IBM Cognos Content Stores

Production Content Store

Test or Pre-Production Content Store

Development Content Store

Summary

Cognos Content Store - Top 10 Key Metrics

Summary:

Cognos License Auditing & Capabilities

Why track licenses in Cognos?

Get it your way

Summary

Consolidating or Merging Cognos BI Environments

Scoping out the merger

Creating the plan

Summary

Migrating Cognos BI from LDAP to Active Directory

Why Active Directory?

The Challenge for Cognos BI

Create a Plan

Summary

IBM Cognos 8 Content Manager Browser Tool

What it covers

How it’s best used

Limitations

Summary

You can find the download here: Cognos 8 Content Manager Browser Tool

The Out of Control Content Store

or The Monster that Keeps Growing

Why the Dramatic Growth?

Is Big Always Bad?

Bending the Growth Curve

Summary

Managing IBM Cognos BI Security Using Inheritance

Security Inheritance

Clearing Object Overrides

Permission Basics

Group and Role Naming

Summary

Download the Ebook: Mastering IBM Cognos Security

Cognos Metadata That Matters

IBM Cognos: Metadata is What it’s all About

The Only Constant is Change

Good Information

Processes That Work

Knowing How it Works

Scaling Up Cognos BI

Issues faced in scaling up Cognos

Be prepared

Counting IBM Cognos Licenses

Licensing IBM Cognos BI - Types and Capabilities

Understanding Capability Permissions

Granting Permissions with Groups and Roles

Counting Capability Access by Account

Using the SDK to find Members

Cognos Technical Partner Solution

What’s New in IBM Cognos 10 - IOD 2010

IBM Cognos 10: The Big Picture

Broader Scope of BI

New Things in Cognos 10

Is IBM Cognos 10 Worth the Wait?

Cognos 10 - To sum it all up:

Cognos Security – How It Gets Messy

“If you think about, it gets all messed up.” – Yogi Berra

Security Ambiguity

Larry has graciously made the slides from his presentation available
and you can find them here:

BBI-1672
Implementing the System Management Methodology (SMM) for IBM Cognos Administration

BBI – 2723
Streamlining the Lifecycle of your Business Intelligence Solution

Download the Ebook:
Mastering IBM Cognos Security

Download the Ebook:
Mastering IBM Cognos Security

Download the Ebook:
Mastering IBM Cognos Security