When Does On-Demand Business Intelligence Make Sense?
David M. Raab
Information Management
June 2009
Back in February, this column asked “Does On-Demand Business Intelligence Make Sense?” and answered a tentative “Yes”. The gist of the argument was that the major obstacle to BI success is the skilled labor needed to build the systems, and on-demand vendors can reduce this through strategies including automation, end-user-driven interfaces, advanced database engines, and pre-built solutions to specialized problems.
True as this may be, it is coming at the issue backwards. On-demand BI should not be a solution in search of a problem. The real goal is to identify situations where on-demand BI is a better choice than conventional solutions. In other words, the right question is not whether on-demand BI makes sense, but when.
The general answer is that on-demand BI is the right choice when it meets two conditions. First, it must solve problems that conventional solutions cannot. Second, it must not face insurmountable new problems created by the on-demand model itself.
Regarding the first condition, we’ve already identified the required amount of skilled labor as the major problem faced by conventional BI solutions. But labor isn’t the only potential roadblock. A project might cost more than it’s worth, take longer than the time available, or require more hardware than the company can immediately deploy. On-demand solutions generally offer advantages in these areas, so projects that face these issues are good candidates for an on-demand approach.
The second condition addresses on-demand weaknesses. Common objections to on-demand systems include: the perceived security risk of moving data off-premise; difficulties if close integration is required with other company systems; the cost of outages if the on-demand system goes down or you can’t connect to it; the risk of becoming dependent on a system you don’t control; and the impossibility of enhancing or customizing the application if it doesn’t meet your present or future needs.
This is where picking the right application and the right on-demand vendor become more important. Let’s start with security. Most on-demand vendors meet high security standards because their customers demand it. Still, particular applications or data sets may require even tighter security than a particular vendor can provide. This might limit your choice of on-demand vendors to those who can prove they meet that standard, force you to load only less-sensitive data, or prevent you from using any on-demand system at all.
Similar considerations apply to the other issues. Tight integration between an on-demand system and other systems is much easier than it used to be, because some on-demand vendors have provided APIs or otherwise engineered their systems to permit it. But the details vary from vendor to vendor. On-demand BI systems in particular are generally not built with real-time external integration in mind. Nor, for that matter, do most BI applications require it. You have to look carefully at what you need and what the systems you’re considering can do.
The cost of outages also relates primarily to applications that are closely coupled to other company systems. For example, a BI system that made real-time credit decisions about new orders could cause major problems if it were unavailable even for a few minutes. But most BI systems are used for statistical analysis rather than operational transactions. Although you might be able to find an on-demand BI vendor who could guarantee to meet stringent availability standards, an application that required extreme reliability would probably be a poor choice for on-demand.
Vendor dependency is an issue with any externally-owned system, not just on-demand. For that matter, reliance on internally-built systems also raises dependence issues. But on-demand does compound the usual risks of vendor lock-in (unreasonable price increases, unresponsive service, deterioration in quality) with concerns that the system could become unavailable if the company went out of business or its system crashed. Again, most BI applications are not mission-critical in the short term, so the worst-case scenario – permanent loss of access – is usually an acceptable risk. Where continued access is truly essential, you may be able to negotiate appropriate back-up arrangements as part of the on-demand agreement.
The final issue is inability to enhance or customize the system. Unlike the previous concerns, this applies to BI applications in particular. While requirements for operational applications are usually well known and fairly stable, BI requirements are often poorly understood until users can load and analyze their data. In addition, the requirements change frequently as new projects and questions arise. This means that a BI system selected with a particular task in mind may not meet future needs. The solution lies primarily in the vendor choice, and in particular in matching the vendor’s approach (automation, simple interface, flexible database, predefined solutions) to your situation. For example, if you expect to work with many large files, a BI solution built around a flexible, scalable database is most likely to accommodate future needs even if you can’t define them precisely. But if your major constraint is a lack of skilled staff, a highly automated system may be your best bet.
In the end, on-demand systems cannot solve every BI problem. Some BI projects are best built in-house with conventional technology, and others should be outsourced completely. You must assess the requirements for each project and match it against the alternatives to select the most suitable approach for every case.
* * *
David M. Raab is a Principal at Raab Associates Inc., a consultancy specializing in marketing technology and analytics. He can be reached at draab@raabassociates.com.