Envisn's IBM Cognos Blog

Cognos BI - The Case Against Complexity

Written by The Envisn Team | October 1, 2010

  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:

  1. 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.
  2. 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.
  3. 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.