I read a really good article in Information Management this week on BI entitled “The Other BI.” The idea in the article is that “business involvement” is the “other BI” that is critical to ensuring success of your business intelligence deployment based on a data warehouse.
The recommendations in the article include:
- IT needs to listen and learn from the business to understand not only what business the enterprise is in, but also to capture requirements the business has for its BI and data warehouse.
- Analyze and understand the business and use that as a foundation for building a logical data model that can be used as a blueprint to develop the data warehouse, to account for future plans that would affect future information needs.
- Engage and advise, which refers to creating and maintaining the relationships between IT and the business community, including subject-matter experts, data architects and the EDW team.
- Engagement of the business community in the EDW design and development process.
Here at Kalido, this is music to our ears since we have been espousing this for years. Yet there are still topics left untouched in the article, specifically related to HOW to accomplish this business involvement and any discussion about the time required to deliver.
As far as the “how” part, readers of my blog have seen previous posts about business information modeling and how to use it to facilitate this discussion between the business community and IT, so check these out for information on a way to capture the requirements and gain understanding that everyone involved can easily comprehend.
Another key reason to consider a model-driven environment is to deal with future requirements. I like how this article advises we plan for the future, but unfortunately we can’t predict everything, and there are always going to be things that come up – re-orgs, competitive moves, market shifts, regulatory requirements, consumer behavior changes, etc. – that are going to need to find their way quickly into your analytical environment.
Another key aspect is how you’ll compete against time as you undertake this new business involvement activity. If you are using the same old tools to build logical data models and then data warehouses and all the other parts of the solution, then you are still faced with a lengthy development, test and release-to-production process. Of course it helps to have a great understanding of the requirements ahead of time that have been agreed to by your business community, but if you still need to write hundreds or even thousands of ETL jobs, you’re still looking at many months of effort. Once your business community knows you understand what they need, they’ll be expecting a much faster response to getting the warehouse and BI up and running – you can no longer buy time by claiming they didn’t explain what they really wanted soon enough! This calls for more automation and a reduction in manually performing repetitive tasks in the data warehouse development cycle.
The article further recommends logical data models to drive the content of the warehouse. We’ve seen companies with fairly extensive LDMs yet they struggle with actually getting them implemented, which means it can take a year – or in some cases much longer – to deploy as a finished warehouse. This is especially true if you are pursuing an EDW and have scoped a very large implementation. Agility is key yet an LDM with no engine to generate the warehouse further impedes the battle against time.
However, there are LDMs out there that are useful. Many of them are feeding data marts. You may want to consolidate these into a DW or an EDW. In this case, having a way to read in existing models to build a new warehouse would be another great way to reduce the time spent and leverage existing assets to get that analytic platform. This will be a topic for a future blog post, so stay tuned!
