Intelligent Enterprise

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.