jump to navigation

BI Prototyping: Developers laughing? SOX auditors weeping? Users experimenting? Documentation lacking? March 21, 2006

Posted by Cyril Brookes in BI Requirements Definition, General, Issues in building BI reporting systems.

Whatever happened to determining system requirements specifications before you build? 

Rigor in requirements determination for BI systems is unfashionable it seems.  The new wisdom says:

  • Why bother to determine requirements for a BI system when you can change it in minutes to fix an error or add new columns? 
  • Anyway, executives don’t know what  information they want till they don’t get it, or they see someone else with it.
  • Interviewing executives and documenting the results is hard work, and too embarrassing if we don’t understand their business well. 
  • We can serve up almost anything based on the old reports and pre-defined KPI metrics, and let them tell us what they don’t want. 
  • Prototyping is god.

The BI development fraternity seems to have psyched itself into thinking it is running a jazz musicians jam session.  Play what you like, and we’ll all join in making it up as we go along.
Jam sessions work because music is constrained by the rules of physics, and the customers can walk away if they don’t like what they hear. 
BI prototyping is different.  It’s more like a graffiti writer’s convention. Graffiti is all over the place, unstructured and in your face.
There are no rules in logical state space.  Anything can be built, given time and money [and data].   So the permutations are infinite, and the potential for confusion – immense.  Plus, executives can’t walk away, they need the information.
  We’re creating an auditing nightmare.  Users are learning to experiment, and are being trained to avoid the hard task of conceptualizing what is really required at the outset.  Change upon change upon change – to formulae, data transforms, aggregations, cube content, dimension hierarchies, and so on.  The tools for prototyping have outstripped our ability to control, monitor and manage the systems life cycle.  It’s bottom up style of management, when top down is what is required if an objective is to be met.
SOX compliance will find it hard to survive in such a context.  Any control that’s mutating faster than an influenza virus will be unreliable.

What can we, should we, be doing?  End to end control from requirements to implementation and associated documentation is the only answer.  But do we have it?  I fear not.Is this a concern for other BI designers?



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: