Have a look at the simple example of what happens in that kind of interaction as an analyst. You can't really see what's not there. So, a report, a query, a dashboard, even a cube, if you're building an OLAP cube for analysis services, or OLAP, or something like that have strict sets of data.
And what happened is you have personally restricted the data that is visible to a person which means you've lost some contextual information. Is this 10% of the data or 90% of the data in the database? You wouldn't know. You wouldn't be able to look at the distribution of data in that data set and know what's going on unless you knew the constraints that were applied.
Now, imagine the person working in Excel, or Access, or something else. You run six reports, you put them into six tabs in Excel, you have now lost the ability to unhide your initial constraints. The constraints keeps you from doing a full analysis because a lot of times the answer lies not in the 'x', the constraint that you've applied. The answer lies in the not "x", the part of the data that you did not retrieve. So, you have to write a second report to get that information and compare it to the first one. Or you have to retrieve the whole set and somehow sort those things out. All of these options, if you've worked with BI tools before, you understand have problems.
|#1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index
BI Professionals Supporting Others
So, you have to be able to surface constraints and show them to people. Now, the report shows the data well, but it typically does not show the constraints that we're applying to retrieve that data. This often leads in the BI world to problem solving for us as the BI professionals supporting others. These aren't the constraints you're looking for. You have the report using these constraints, but you left out some data. That's why your numbers don't match.
Well, you input those things, and it immediately pops back out and changes the set of information. That has to happen very quickly, which is hard if you have to go through this design/execute/view model. So, we have these things where we can't really reduce the analysis challenges using a hierarchical, master detailed, paper based model of looking at things. You need a true interactive model.
Now, all data mining technologies tried to address some of this and were partly successful except that those technologies still had to repeat data, and impose constraints, and they still use a user interface very tightly related to a paper based model. And so, when we look at that, you see we're still in a publishing world. And the problem is that you're in that publishing world where you have to build the cubes with the users. And that's a very bad model because over time things change, and you have to constantly adapt those cubes, and the users can't do it for themselves.
Future Proof Your BI
And so, when we look at the business intelligence tool market and what's going on if you're trying to future proof your BI and enable this better analysis to a broader set of people you have to do things somewhat differently. You have to start thinking about it not as publishing models, but as interactive models that have a give and take, that are task driven. And the data management technologies that we've got today are enabling different ways of architecting the actual warehouse not so much from a data management layer, but from a data access and delivery layer.
Read what InetSoft customers and partners have said about their selection of Style Scope
for their solution for dashboard reporting.
And the traditional BI vendors, Cognos and Business Objects, and Oracle, and Microsoft, still have a fundamental understanding of it as a publishing model where 90% of the work has to be done by an IT person. Whereas a lot of the newer vendors like InetSoft are coming out with tools that are designed differently and architected differently not to take advantage of the capabilities, but to change the architecture.