InetSoft Webinar: Interconnected Business Intelligence Projects

We all know that business intelligence consists of a series of interconnected projects. Basically it’s a program made of interconnected, interrelated projects, and that means that documentation is mandatory, you have to have that documentation carry forward from project to project to project. Also the good news is you are going to be generating lots of technical metadata, out of your ETL processing, your data quality processing, data modeling and so forth. And all of that information is very, very useful to the next project coming on board.

You will also need business metadata, and this is the type of documentation that sometimes gets a little bit short shrift in a BI project. What do I mean by business metadata, I am talking about the information about let’s say business aliases or business rules, maybe even security constraints and so forth. All of the information that is critical to the business users to understand what exactly are they getting themselves into.

Let’s talk about one last “do” for best practices of agile BI, and that is to create early wins and to iterate often. That is basically the bottom line to agile BI. It’s the benefit from the agile methodology, the biggest benefit. Do keep the business users interested, and we do that through these short, quick iterations, small production-ready deliverables.

Even if it’s only two weeks that we are going to produce some kind of a report or an analytic that they can use immediately that we are going to be producing these usable capabilities, usable deliverables in a short time frame through the agile methodology. And again like I said, a usable component, a usable delivery is delivered about every two to four weeks.

Let’s talk about another pitfall in business intelligence. One barrier to successful business intelligence is not knowing what you are trying to achieve with business intelligence. What we are trying to do with the agile methodology and agile BI is to make sure that we are producing something every two to four weeks that is usable, that is immediately grabbed on to by the business users. Now again we have to ensure that the architecture and the overarching strategies still are appropriate before we start the next iteration.

Now let me talk about some of the “dont’s,” and “dont’s” are as important as the “dos” we all know that. The first one is please don’t start a BI project on speculation or a guess of what is needed. Some people might say, here is what I think the business users want. That’s what so-and-so was talking about. You don’t really know what the business users want, so you just go and build something and throw it out there and hope that they do in fact want that. You have got to keep the BI users involved in every step of the implementation.

You need to understand their business needs. And sometimes we have to use the prototype to haul in those requirements to a sufficient level of accuracy. You build something, and you will have to look at it a little bit. Let the business users make comments about it, and then you go to another iteration and so forth.

Please though don’t expand the requirements unless there really is a documented or recognized need, and even then, if it really is mandatory, you may have to look at your timeframe and to keep to it, you may have to add the new requirement, but take something else out. In that case, you may have to defer or remove extraneous data, extra reports or maybe even the reports that you thought you are going to be delivering.

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

Another “don’t”, please don’t over-complicate the requirements or the BI environment. This means that your BI environment, first of all, it will grow enormously. It will grow rapidly. But it means that you have to have a BI environment that you can at least handle at the beginning and understand. So don’t get overly complicated at first. Grow with that complication. That means that you need to understand the technological functionality thoroughly.

Growth is inevitable. In fact, it's welcomed. It means that people are using the BI application, but you have to understand what your technology can handle as well. Can it scale seamlessly? Will the performance hold and be acceptable even over the long haul? And of course there it is again maintaining that adequate documentation to make sure that you do have a consistent and a reliable BI system. That documentation as I mentioned includes your ETL process and your data quality process and the BI requirements and the reasons for those requirements, the definitions of things, whom to contact and so forth.

The last ingredient to agile BI success, don’t create silos of BI capabilities. Set up cross-functional ties of BI experts. The more each department knows what other departments are doing the more easily the BI system will evolve over time. You don’t want to let things disintegrate into multiple data marts or disparate BI tools, when you set out at the beginning to build an efficient BI system.