Expert Perspective: What We Need to Get to Operational BIExpert Perspective: What We Need to Get to Operational BI

Vendors in the business intelligence and enterprise applications market have been talking a lot about operational BI, making BI pervasive and active/dynamic data warehousing. They’re responding to the need businesses have for up-to-date information at the point of use so decisions can be made more quickly or tasks can be done more effectively.

Operational BI is a compelling vision, but the problem is that the BI tools of today aren’t really suitable for the task. The capabilities developers need to unlock are tied up in SQL query and stand-alone UIs, and the platforms themselves aren't as flexible and develop-friendly as they need to be. What's needed is a split into query generation and data services on one side and end-user access on the other. This article presents a roadmap — or at least a rough compass course — toward pervasive BI embedded in the applications and Web interfaces in which most business users make decisions.

What Developers Want

Making operational BI a reality will require two things: front-end tools that address the specific interface needs at the point of usage, and a metadata-driven query layer that isn’t tied to a specific UI. Some BI vendors offer a half-way solution in that they offer access to the query engine via APIs. For example, Business Objects talks about “query as a service.” This is exactly what’s needed from an application programmatic perspective, but it’s not the full solution.

The developer embedding BI into an application shouldn’t need to know SQL just as BI end-users shouldn't need to know SQL. Developers don’t need all the fancy BI tool features either. They need a simple interface that lets them specify attributes, metrics and selection criteria, and that gives them the data in a usable form. This is not possible today. BI tools don’t offer a stripped-down report definition interfaces, catalogs of available reports or queries, or the ability to make these available in on-demand fashion in different formats via different APIs.

For example, web developers will want a web API, a SOAP API, a Java API binding and a Ruby binding so they can reuse that back-end data as a service from several different applications. They'll also want the option of receiving a result set in CSV or fixed-text formats, as an XML file, as an Atom feed, and as JSON (Java Script Object Notation). No BI tool can do this today, and it's doubtful whether there are any vendors thinking this far ahead.

How Vendors Must Change

BI vendors need to split their tools into two separate components, in much the same way the OLAP tool market split the front-end from the back-end server. A monolithic BI tool (as we have today with all the BI vendors) is not well-suited to adding BI services to an application. A tool divided into query generation and data services, on one side, and end-user access, on the other side, is the only way to address conflicting end-user and developer requirements.

One problem BI vendors face in addressing operational approaches is that they are largely driven by the economics of per-seat pricing, plus the big server engine charge. Apart from the technical challenge of rearchitecting tools again (vendors just converted their tools from client-server to Web 1.0), this will require a big shift in mindset, both within the development organization and within sales.

Assuming you have a data service layer for the data warehouse that enables multiple API calls and multiple return formats, you then need to deal with the user interface and embedding requirements.

Most BI tools are very poor as embedded tools within an application framework. When Web-deployed they generally require a login and want to own the entire browser session. While this might work in a portlet encapsulation, it’s not likely to work anywhere else.

Now that packaged application vendors like SAP and Oracle have their own BI tools, we can expect this situation to improve. However, it will take time and will probably not be a general solution. They are more likely to create tight integration in their own platform and not work well embedded in other vendors’ packages or with your custom applications.

Program-Level Integration Challenges

Apart from the simple challenge of making a report or graph an integral part of an application interface, there are the complexities of program-level integration. Enterprise applications are most often built with Java. Web applications may be deployed with Java, .Net or with tools and languages like PHP and Ruby that are more common in the Web world. Then there are the Web widgets, whether from vendors, language toolkits or rich Internet application products like Adobe AIR.

Most BI vendors have stand-alone UIs that don't operate well in these environments, so it will be difficult for them to embed conventional reports or graphs. You can’t easily take a report from most tools and incorporate it seamlessly into an enterprise or web application. This is due to the differing authentication, security and interaction models as well as user interface requirements.

Expect Web 2.0 technology to drive changes in BI user interfaces, particularly for embedding. Web 2.0 might also accelerate the split between the UI and query engine layers. Native Web UI tools expect simple, callable interfaces for data access. Products like JackBe might point the way toward a new model for BI tools.

Open source BI tools also show promise in the operational BI space. Apart from the obvious advantage in cost of deployment, they have more exposure in the Web and Java application developer markets. As a result, they're generally easier to embed or integrate with applications.

With the acquisitions of Hyperion, Business Objects and Cognos, and Microsoft’s entry into the BI market, there are plenty of opportunities for companies to explore new architectures for operational business intelligence. Expect slow progress from these big vendors as they go through the acquisition process and figure out how to operate as part of a larger application or infrastructure vendor. That could open the door for fleet-footed rivals that can offer alternatives sooner rather than later.

The ongoing addition of data and application services in IT means you can gain experience with some of these new technologies today and put yourself ahead of the curve. When BI vendors finally begin to address these needs, you’ll be ready.