Business Intelligence's Catch-22

Loraine Lawson
Slide Show

Harnessing the Wisdom of Business Intelligence

Valuable insight into BI usage and products currently in the market.

Everybody talks about the importance of putting the business need first on any IT project, whether it's building a new application or integrating data for a business intelligence (BI) project. In theory, this should create alignment between what IT is doing and what the business hopes to achieve.


But in practice, some have found it leads to bad architecture, spreads your IT resources too thin and ultimately disappoints more than it delivers.


Paige Roberts recently wrote a thought-provoking piece about the tension between an architecture-first approach to BI and a business-first approach to BI.


Roberts is a marketing manager for Pervasive Software's integration division, with 14 years of experience working in integration. So while the piece is nominally about business intelligence projects, the real challenge she's addressing is how you prioritize and develop the underlying integration that supports those projects.


As she points out, there are some legitimate reasons why business and BI implementers wind up on opposite sides when it comes to making decisions about which BI projects to pursue and how to go about building them.


For instance, implementers tend to be focused on the best way to build the technology architecture in a way that is sustainable for IT's limited resources while still supporting a variety of business initiatives. Business end users, on the other hand, are more focused on how their division or department will use that information.


I know what you're thinking: "Smart IT leaders should be able to balance those two demands." But it's not that simple. Even the smartest, most-veteran IT leaders struggle with this issue. In fact, Roberts wrote this piece after attending a conference at which IT veteran Claudia Imhoff, a Ph.D., confessed that if she could do all BI projects over again, she would focus on architecture first and only address one business area.


That's because Imhoff learned the hard way that trying to address two business problems led to multiple data silos and maintenance problems for her IT team. Neither departments were happy with the results. If she had put the architecture first, and only addressed one business problem, one client would be happy and the architecture would be better designed.


Win-win ... and lose. As Roberts points out, that leaves Imhoff's inventory manager out in the cold on what's actually a small request. Can't he be helped?


It turns out, it's hard to hit that sweet spot between just enough and not too much. Large solutions - like a data warehouse or MDM - would be overkill, she explains:

BI questions often focus on a single area of business. Doing frequent BI queries that only use a tiny subset of the data in a huge multi-domain data warehouse is extremely inefficient. The creation of small specialized data marts for particular business areas is the usual solution, but that is already getting out of control in many businesses. It creates multiple data silos which can result in data drift, multiple slightly different versions of the same data, and other data quality problems that erode the whole purpose of consolidating data in a data warehouse to begin with.

Is it a Catch-22? Roberts actually asked for feedback, and I noticed that thus far, no one's posted an answer for her on the ebizQ page.


Being just a simple tech journalist, I can't answer this particular quandary. But what I can and will do tomorrow is share what experts have suggested and what's worked for others facing a similar choice.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.