Traditional Approaches to Business Intelligence Can't Keep Up

This is the continuation of the transcript of a Webinar hosted by InetSoft on the topic of "The Changing Requirements of Business Intelligence." The speaker is Mark Flaherty, CMO at InetSoft.

Agility is very critical here because of what we talked about earlier. The traditional approaches to business intelligence can't really keep up with the ever growing, ever increasing number of business intelligence requirements. The axiom, ‘build to and they will come,’ only applies to business intelligence in that when you roll something out, that’s when people start saying how this is what I want, that’s not what I meant before when I told you.

This means you can't really plan well in advance as you can with other applications. Agility in business intelligence is something very different than agile software development, a concept that has existed for a while. Agile BI rest on three legs. It’s a triad. It doesn’t start with that agile software development methodology. You can't really use that on its own.

You need to follow the best practices and use some of the agile BI technologies that I will recommend here. Each one of these three points is necessary, but they can't really stand on their own. So let's go through them.

Agile software development methodology calls for reacting to changes as opposed to planning interactions. Instead of well planned processes and building applications based on complete specifications, rely on face to face business participation. Don’t rely on working with intermediaries.

Face to Face Business Participation in BI Development

This principle has been understood for a long time in other software development area, and it does work very well most of the time, but it does not, by itself, work well in business intelligence for multiple reasons. Some of the reasons are that first and foremost, you do really need to follow BI best practices. Everything else pales in comparison with the importance of following these best practices.

They are organized into by two major categories. The first one is that your organization needs to be culturally aligned to be able to absorb agile BI. So you do need to emphasize business ownership. You do need to emphasize all sorts of cultural change management for BI. BI is not a grassroots process. It has to come top-down, and you do need to decouple in your organizational structure data preparation and data usage. IT handles the data preparation side, and let the business take more ownership on the data usage side.

Treating back office and front office folks with the same approaches and standards doesn’t also work because they have completely different tolerance levels for risk, for latency, and for accuracy. While organizational silos and data silos are normally bad, total centralization is also not very good because it creates bureaucracy. It does create red tape. And guess what happens when you have bureaucracy? People start going around it, and you are back to square one. You end up with homegrown BI apps. So we do recommend some kind of a win-win scenario in the middle of the road. You can call this a hub and spoke approach.

View a 2-minute demonstration of InetSoft's easy, agile, and robust BI software.

BI Process Best Practices

Once you are done with organizational alignment, then we will recommend following some of the BI process best practices such as using a combination of bottom-up and a top-down BI design and architecture. Bottom-up calls for serving all of the source systems, reconciling the data, and creating some kind of a normalized historical data warehouse. Sometimes that bottom-up approach suffers from the disconnect from the real business requirements. So some folks try the top-down approach where you go through the classical decomposition of performance management staffs. This mean, let’s take a look at our strategy and decompose it into goals and objectives, and let’s decompose those into specific metrics that we need to monitor every month to understand what our goals and objectives are, and then let’s see where we get the raw data for those metrics.

That works well for very specific business areas, but it doesn’t work very well across the enterprise because very often you start running into areas such as customers and products which expand these multiple top-down exercises back to the bottom-up or a horizontal exercise. So some kind of a combination is really called for here. We just mentioned the next point which is agile development methodology. I can talk for hours about self-service. Business user self-service is not just about a user friendly point and click drag and drop interface. It may be user friendly and intuitive to IT professionals, but some business users will say that the point and click is not user friendly because they don’t know what they need to point to in the first place.