Cyril on Business Intelligence

Two recent articles on the place of the maverick in conventional IT, by Joe McKendrick and Ramon Padilla stimulated me to consider the role of the Rogue in BI systems creation, modification and use. It’s more benign in BI than in IT mainstream, that’s for sure.

To mix my metaphors: Blessed are the BI Rogues, for they shall know what they want much sooner than IT will get around to filling their request.

I define rogue BI as the user self-creation of unofficial, unapproved corporate performance reporting, competitive analysis and customer behavior assessment.

The pressure for instant gratification in BI is intense, perhaps more so than the teenager’s need for the new Playstation game. Or maybe it’s just the grown-up version of the same.

The data is there, the report building is now easier, or the same, as building a spreadsheet, and no one is directly affected by poor execution, except that the Rogue gets rubbish instead of the goodies. Of course, the business meeting where the rubbish is put forward will be interesting; much like used to happen in the old old Visicalc days when ingénue spreadsheet creators battled it out with garbage versus rubbish.

It’s the “no one knows” that’s the issue for IT administration. If no one knows that a report exists, no account will be taken of it when the data cubes are redesigned, deleted, re-dimensioned, or whatever.

Reuse is also impossible, obviously, but then again it’s likely undesirable except for the brilliantly capable Rogue. SOA followers don’t want to go here!

Some form of monitoring and control is required of the BI environment, but the jury will be out for some time yet. In the meantime, it is important for us to realize Rogues are part of the shift to the BI brown-field.

In January I blogged that BI issues in 2007 would be focused on metadata because of the brown-field effect. In the brown-field new BI applications would be re-workings and extensions, not new systems for executives without current BI, the green-field. BI Rogues proliferate in the brown-field.

This leads us irrevocably to the metadata management issue. As I see it, it is imperative that IT administration control the Rogues through regular, maybe daily, snapshots of the BI metadata, not just the SQL but also the (using Microsoft examples) the Analysis Services, Integration and Reporting Services content. Lineage that links report content to cube content and maybe data sources is also useful.

Dear Reader, if you’re a regular, you will know that I’ve been working on a metadata documentation and snapshot tool - BI Documenter, which does most or all of what is needed in the BI metadata area, if you’re a Microsoft user. You may care to check the website www.bidocumenter.com.

Metadata snapshots tell the story, the Rogues leave an auditable trail, and all modifications are likewise exposed. Assuming they don’t do something completely stupid, the Rogues can be allowed to create their “thousand flowers” to bloom.

If you cannot, or don’t want to, monitor BI metadata snapshots then I believe your only option is to use governance to manage the inevitable BI Rogues. Good luck, they’re smart!

Next time I’ll look at a code of good practice for BI Rogues.