InetSoft Webinar: The BI Layer: Visualization

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 focus on integration, and we and what we’re building it along the way in this value chain methodology. We’re creating those story cards which then are the tasks that get handed out to the development team to go build, and we build story cards around the database objects, the ETL, data integration, and the data quality. Then we have stories around the BI layer, around visualization in the form of dashboards or reports and that kind of stuff.

So that’s really as we begin to decompose and really think through the business wants and needs and deconstruct it and we end up with the ability and the delivery sprint thing to go actually create the work, to do the work.

When we move from the business value chain to the technical value chain, we believe a best practice is once the glossary, the list of terms, has been laid out, that the business begins to get involved in a data stewardship process.

This is where the terms get validated, and then once they’re validated, they become the core building blocks of everything we do at the BI layer, at the data phase layer, and ETL layer. The Balanced Insight tool brings with it a data stewardship process engine. We’re not going to spend a lot of time today, but when we couple the data stewardship process engine with the business modeling components, we get reusability.

We get automation, and we allow the repository to act almost as the design repository and certainly the requirements repository without having to embed all of this in Microsoft Word or Excel, and so as things begin to change and evolve, then the repository kind of manages itself.

Just from a philosophical point of view I think that the two apply directly to delivering BI solutions in an agile method. The idea is that we start with what the business wants and needs and articulate those wants and needs in the forms of questions or goal statements or measures. We work our way backwards. It is key to first understand and then to be understood.

And we seek to understand through modeling the business in the consensus tool playing back the business model and then generating the very rapidly built prototype. The prototype then is what allows for the business articulation to take actual form, and that’s the beauty of the methodology. By building these models and doing this rapid prototyping instead of trying to describe what the business wants in Word in words, we’re doing it in the actual product stack itself.

View the gallery of examples of dashboards and visualizations.

So if we go back to the three different views we have the justification phase which is where we create that release backlog. We do the initial estimating. We create that release plan, and then we go into the initial phase which I call sprint zero. And then once we’re through with sprint zero, we move into sprints 1 through N which are the actual delivery sprints.

Now we’ve been doing Sprint 0 for a couple of years now, and every time we do it, we are just more and more convinced that this is the right way to approach requirements definitions, and then again if we think about the timing of this, this is three, four, four-five weeks worth of effort, but the idea is to get clarity and definition of the solution before we spend the hard dollars building out the ETL and knowing the formal data model and all the formal reporting layouts.

Read what InetSoft customers and partners have said about their selection of Style Report as their production reporting tool.

But the idea is that what we go through the business modeling, and we get the business to define what the terms are needed for the global glossary. We build that prototype. We do the profiling, and we integrate through that multiple times within Sprint 0. At the end of the sprint, what we adopt with is a set of story cards that then create what's historically called in the agile vernacular the product backlog.

And this is where we then begin to allocate the story cards to sprints and if we remember that these story cards have already been allocated to releases. So we’re just decomposing further, creating each individual sprint’s backlog. The idea is if we do build a prototype in the business model and play this back to the business, we’re talking about a team of two, maybe three people.