An InetSoft Webinar: Touching The Business Intelligence Solution

This is the continuation of the transcript of a Webinar hosted by InetSoft on the topic of "How To Deliver A Good BI Application." The speaker is Abhishek Gupta, Product Manager at InetSoft.

We’re not talking in terms of thousands here, so running a sprint 0 doesn’t cost a lot of money, and it does not take a lot of time again three to five weeks. And in doing this what we’re doing is get absolute clarity that the solution is going to answer the business questions or solve the business need, because they’re actually touching the business intelligence solution before its built if you can think of it that way.

And once we get that clarity and the business says yes you deliver me that for real, with real life production data, you’ve hit the home run. Now we go do the hard work, the expensive work. What we have done, to go back to the very beginning, we have absolutely minimized the data integration task because the only stories we’re going to work on are ones that address data needs to answer those business questions.

Again everything springs from the business value chain. This allows us to gain clarity, buy-in, and consensus and deliver the best solution with the least of amount of effort. If we think about what I’ve been talking about, we end up with the customer metrics, and we said we may have a release around profitability and a release around retention. Within the first release we’re going to go do the sprint 0 for release 1.

View more Dashboards in the InetSoft gallery

We end up with a bunch of story cards that then get allocated to the two weeks of sprint cycles. Just so we understand from a project nature point of view we can track the story card at the micro and the macro level, and we can track the release. We can track the program. We can track stories on an individual basis and really practice daily management as well as long term management.

At the end of the sprints, we take the story cards, and then the sprints get combined together and assembled into a release package which is simply the collective set of objects needed to solve the business problem. It takes the form of databases. It takes the form of ETL programs. It takes the form of semantic layers and reports and dashboards.

And so when you’re thinking about creating stories, we’ve created an acronym. The story should be independent, negotiable in terms of what they contain and how long it will take. They should be valuable. In other words the story should drive additional business value, and we tie it to something in the business value chain. If not, then you question whether or not it should be done.

It should be estimate-able because let’s get real. Really at some point we do have real work to get done. We do have to manage projects. We are going to spend real dollars and real hours. The story should be small enough to be done within an individual sprint. If they cross across sprints, our belief is that story should be decomposed further. Any story should be able to be done within a single sprint, and they should be testable which is another core concept of the agile methodology that we preach. Before we do any design or development we pair our developers with our testers, and we create our test cases as a necessary first step before we do anything else. And so this test led development, test driven development really leads us to a higher quality product, and we will show you some of the results we see.

So now that we talked about more about the theory, let's talk about a little bit about it in practice. What I’ve been talking about is how we begin. If we think about this chart, and this is a very common chart, I am sure you’ve seen many times. We have the sources on the left and business users on the right. We move the data from left to right. But what we’re trying to do is really break the problem into an information deliveryproblem and the data problem.

Read what InetSoft customers and partners have said about their selection of Style Scope for their solution for dashboard reporting.

The idea is that we drive our requirements from the right begin with the end in mind. We articulate them in the form of objectives and goals and questions and let that drive what we do with the data layer. Once we understand that we begin to build the data obviously from the source outwards, but everything starts in the right with the requirements. The information delivers the business value. In other words it drives the data. If we bring into play the best practice of data stewardship and start to begin to apply some of the data quality analysis and remediation, the goal is to get consistent data. That means throughout not just the BI layer but through the database layer and ETL layer as well. We’re going to show you how that could be made possible through automation.