On Agility in Business Intelligence

Along the lines that many people confuse Business Intelligence with infrastructure, tools, processes...

Business Intelligence is the result, the actionable insight, not the support chain of getting there.

Delays in results delivery, solution turn-around times that often miss the meanwhile moved target, are to be attributed to convoluted processes, the involved technology, and the mindset of the providers enamored with the tools and not the results.

Of course once you've invested millions into "solves world peace" B.I. architecture, then every problem becomes a nail, because you just bought a very expensive hammer. The imperative of needing ROI on the shiny new silver-bullet will convert the business challenges to match the existing solution (round peg meet square hole), when it ought to be going the other way around. Your business loses flexibility due to the constraint of your tool set. Oh so common.

Agility is not just a software development or project management concept. It's a way of life. Innovative business already have been practicing it, the kind of "turning around on a dime" agility of Generation Y. The trouble is that the belief still holds that the more years of experience an implementer/provider has, the more relevant their approach is, when it couldn't be more yester-year. And that contributes to the impedance mismatch between heavy top-down architectures, versus the "just right, now" needs of the modern progress business.

So if we do want to borrow from the play book of software developers and apply it to B.I.:

• Decouple, avoid monolithic designs (modern version of divide & conquer).
• Design for change (why version control is relevant)
• Address ambiguity upfront (this is where meta-data comes in handy)
• Push data modeling down-stream (just in time, instead of waterfall style upfront, when not all requirements are clear yet, acknowledge the cone of uncertainty and the trajectory of change)
• Focus on semantics (storage and processing is cheap these days, don't waste your resources on resolving ambiguity at storage/modeling time)

Inmon's current philosophy as expressed with DW 2.0 is on to something with his distinction between semantically temporal and static data. Yes, yes, this echoes the MDM movement. But my point is that we should apply this philosophy to everything across the B.I. stack. Recognize that which is moving and treat it accordingly. Don't invest too much into moving targets. Just enough.

How much is enough? We shall explore in another article.

B.I. well!