I’m not sure who came up with the quote, but it is certainly a favourite of Ralph Kimball:
What’s the difference between a methodologist and a terrorist? You can negotiate with a terrorist.
I think that is very true of the Business Intelligence industry. What works best is a pragmatic, customer-centric and iterative approach, focussed on delivering real value.
Don’t get me wrong: processes and frameworks are Good Things- they help guide you to the right destination, making sure you don’t forget necessary steps and helping ensure a predictable result.
However, too rigid adherence to processses and methodologies tends to work against success, particularly in BI projects, where design trade-offs are made constantly, requirements vary wildly from one project to the next (and even within projects), and the ability to modify your approach ‘in flight’ is the most important tool in your toolbelt.
Is it more important to follow a defined process or procedure to the letter, to religiously adhere to a methodology, or is it better to tailor your approach to the customer’s requirements, establishing what will work best in a particular situation?
It is a huge mistake to think that by following a procedure or process, or even a methodology, that you are somehow building quality into a system. In BI, strict procedures tend to encourage a lack of thought about what is really important to the customer. In fact, although it is not true that the customer is always right, for a BI system it pays you to always focus on what a customer truly needs to make better decisions. Anything that distracts from that focus is a Bad Thing.
I’m a huge advocate of the Kimball approach to DW/BI. By bringing together some powerful techniques and guiding principles, a framework and an approach that works well for most DW/BI situations, this gives a starting point and general scaffolding that most projects can be structured around. But the Kimball Group are keen to stress this is not a methodology. They have guiding principles, that the DW should be performant and easy to understand from a business perspective. The techniques they offer are simply those that they feel succeed in meeting those principles, but they’re not the only games in town.
BI isn’t so different from traditional software development. Frameworks, checklists, and processes can be helpful to new BI practitioners and experienced hands alike. It really does matter that you know how to test ETL, or verify that a report has met a customer’s needs. But in order to achieve real quality, the kind that makes a BI system truly useful to a customer, you must always retain the imperative to be flexible, pragmatic and customer focussed. A procedure or methodology is only useful when it helps along that road.