What is it that business users can do in the spreadsheet that they potentially cannot do in your desktop BI tool or cloud BI tool that you provide? Find out, and then you need to make some hard decisions. You don’t really want to limit them. What is it that a BI tool needs to have to basically close all the gaps in functionality, between their features and what Excel.
Empower your business users with their own sandboxes. Then empower them with capabilities to share their content with their colleagues with as little involvement from IT as possible, and then empower yourself. Empower your BI support organization with the ability to monitor what these people do, and selectively, proactively and reactively promote that content to production.
I would say you notice a user who has created at web-based BI application that loads billions of rows from ten different data sources, creates a giant in memory data mart, and distributes it via email to hundreds of his colleagues. That’s a big success, right. All this needs to be productionalized or operationalized.
The good news is that the business user already has done all the hard work. You don’t really need to inundate him or her with business requirements gathering. He or she already identified all the data sources. He already identified the data transformation logic. He already built a data model. He already built the front end so all you really need to do is harden and productionalize that content, and that’s one of the key features that you should look for in BI tools.
|#1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index
Can you empower business users to basically do whatever it is they need to do to get their job done, but then can you take what they created and with minimal effort promote it to production? And you need to do all the testing and UAT and quality assurance and set up backups and redundancies, everything that you need to have in the real large enterprise production environment.
And last but not the least everything that we just talked about is going to be academic discussion unless you augment your BI environment, your BI infrastructure with agile BI technologies. As we said early SQL is definitely very mature, and you can do a lot with it, but it’s not agile. Supplement your SQL with no SQL technologies.
Look to the cloud for elasticity. Look at new types of databases like columnar databases for scale. If SQL is something that you need to live with for the foreseeable future, hybrid in memory and disk based caching is key. So is mobile delivery so that people can make decisions on the spot, not waiting to get back to their office when it’s already too late.
There are lots of different agile BI technologies that you need to consider implementing for you to have an agile BI environment. So with that in mind the recommendation is to think in terms of this pyramid. I think that one of the reasons you really need to embrace and start implementing and deploying agile BI is that agile BI forms about the one-third of the foundation for business agility, and business agility is key in the age of a customer, not just to succeed but actually research has proved is a key capability for survival.
So hopefully you can deploy some of the agile BI best practices that we talked about in the last half an hour. You can actually have the cake and eat it, too. You can indeed today with the modern technology and the best practices. You can have a scalable and robust environment to support your mission critical apps that are also at the same time agile and flexible and can support business agility.