A common complaint about data warehousing/BI has been time to market. The investment in real months required to stand up analytics is just too large. Descriptions of the actual time required vary (depending on who you ask, and what their interests are) from a year to 24 months. The numbers are open to debate, but let’s go ahead and stick with the conventional wisdom that Data Warehousing typically 
requires a significant timeline to see results. This assumption then begs two questions:
- Does it have to take that long?
- If it has to, will it be worthwhile?
Looking at the second question first, there’s a very simple answer: YES. Successful DW/BI projects can utterly revolutionize an organization’s processes and even their outlook. They can shine light on problems, point the way to new opportunities, and improve the daily work lives of employees at almost any level. I consider it a foregone conclusion that there is tremendous value in well-built DW/BI systems.
Of course, the caveat there is the whole “well-built” part. That’s where the delays creep in, and where the real timeline resides. In addition to the experience and expertise brought to the design and construction these systems, the degree of involvement of the business also plays a very large role in how successful the solution will be. Too many gaps or failures on either side can result in less-than-satisfactory outcomes being reached after spending a lot of time and effort.
So that leads us back to the first question above: does it have to take that long? I mean, upwards of 2 years to build a decent Business Intelligence solution? This answer is not nearly as easy because the factors that contribute to extending timelines in DW/BI projects are numerous and varied. For instance:
- Are the builders of the system planning development closely with the consuming org? If not, extend the timeline.
- Is the business committed to providing solid requirements on an ongoing basis? If not, extend the timeline.
- Is the development team sufficiently experienced and under solid technical leadership? If not, extend the timeline.
You get the point. The development work in and of itself is not necessarily what takes a long time. What takes a long time is when business needs are misunderstood or disregarded, when expectations aren’t managed, when the chosen technology platform is not well-aligned to business requirements — basically, when either side doesn’t fully understand what they are getting into, and there is misalignment in that area.
In the next few posts, I’ll go over various tools and techniques currently in the market that offer some kind of acceleration of the data warehousing process, and see what paths are available to speed up time-to-analytics. I will include the tool class sometimes variously referred to as either “frameworks” or “accelerators”. I’ll talk about iterative development and the potential risks and benefits of using Agile methodologies. And I’ll discuss possible ways that planning in itself can help deliver results sooner rather than later.
Next time: Accelerators and Frameworks. Hope to see you then!
