After that synopsis of Agile BI’s definition and a discussion of what’s being said in the industry today, let’s mention some of the specific technologies involved with Agile BI. When it comes to BI visualization tools there is a variety of different providers of them.
The business intelligence market has being broken into three segments. There is the classic reporting and scorecarding. There is a whole new field that’s being called data discovery and analysis where those technologies, in memory, data visualization, and predictive modeling.
The cool thing is they’re being simplified down from requiring a statistics degree to something where an MBA or a reasonably savvy data management person can actually do modeling on fairly complex data today. It wasn’t possible a few years ago. And I think the extraction tools is another category.
So if you take this model of ours and what I’m hearing and seeing in the analysts’ reports, you have this foundation which is the data and the data extraction piece which can be ETL. Then on top of it you have got this data discovery analysis capability.
Besides that you’ve got the reporting and scorecard system. All are serving different purposes but are working together in the eco-system.There are a lot of questions coming in as we move into the discussion section of our webinar. The first question is, how can a large enterprise take advantage of Agile BI, and is there a preferred method or process that is recommended?
| #1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index |
|
Read More |
One thing is to make sure to empower end users especially for data discovery analysis. And think of it as a departmental first, rather than an enterprise one. I’m sure there are some of these problems that expand across enterprises, but most of them get focused. Like in marketing, it could be promotional analysis. Or in sales it’s pipeline performance, how proposals move and so forth.
Even in a sales group we’re going to have different kinds of problems, so that’s why I think you need these themes where the end users work together with the IT group. Often there are BI people in the functional unit. Like there’s a sales team and a BI person dedicated to them who works with central IT. Or there is marketing IT and BI people who understand the problems and those questions the end users actually trying to answer.
And they know how the answers need to be delivered in a way that those people can consume it reasonably. Enterprise discovery and analysis becomes a sum of a lot of departmental problem. The solutions you need in an organization actually have got a central infrastructure IT, but I think that’s again the total answer. The key point is that it’s not just the central IT solution. It’s going to be combined with this enabling BI centric departmental organizational model where all parts are working together, and then great things can happen.
Okay. We have another question that just came in, do BI implementations always require IT involvement? Isn’t there a lot of knowledge required about the various data bases and their respective structures?
Great question. No, they don’t always need IT involvement, with some caveats. Obviously if a department of end users was to buy a BI solution, there are probably three or four places IT would need to come in. One is they need access to the data, which is usually in some corporate database or IT owned database.
They need permissions to it, and they need ways to get at it which aren’t too hard. And they’re putting a server for web delivery of these visual discovery applications, obviously IT needs to get involved because the server needs security. It needs to adhere to all the corporate rules. You can’t just put a public departmental server up on a corporate network and let people at it.
But some of these systems can be run on client machines sort of like excel. So at one level, these new technologies could enable a department to buy 10 seats of clients software and pop them on PCs, just to meet the software standards of the organization. Those users then have network and permission access to the database, and they can pretty much get going on their own.
It’s not like a legacy BI reporting system where it’s a big development cycle. They can muck around that data, load the tables, build these things and share them with others without much IT involvement. The challenge is if you get IT involved to go back and actually modify the database tables, it’s a big project, versus you suck them in to a client app in memory as they are, and then you do the metrics calculations, the cross joining or whatever has to happen there. Now, ideally the key metrics are generally used across the team and other reporting tools.