People don’t often think of open source in terms of operational business intelligence (BI), yet this is a logical area to leverage open source.

One of the biggest problems is that the technology stacks for OLTP applications aren’t a good fit with querying data. You don’t want Java developers banging out random SQL, and they don’t want to. The same is true of most application developers, whether Java or a web developer using Ruby on Rails.

To make operational BI a possibility requires 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 user interface (UI).

The open source business intelligence vendors are working on metadata-driven query generation. They aren’t up to the task yet (compared to commercial BI tools). Some BI vendors offer a halfway solution for data access in that they allow access to the query engine via APIs. For example, Business Objects talks about “query as a service.” This is what’s needed from an application programmatic perspective, but it’s not the full solution.

Where open source comes out ahead is when it comes to integrating business intelligence into applications or web sites. Displaying data in the interface of an application requires making functions available at the server level or within the context of a browser (e.g., server-based page rendering or front-end widgets).

Most commercial BI tools are very poor as embedded tools within an application framework. They just finished re-architecting products to work in a Web 1.0 world. When web-deployed, they generally require their own login and want to own the browser session. While this might work in a portlet encapsulation, it’s not likely to work anywhere else.

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. It may be impossible to embed a traditional BI report or graph in these environments since the BI vendors don’t properly expose their APIs in most of these environments.

Open source tools are usually much friendlier to the developer. Look at the deployment models for integrating BIRT compared to Cognos or Business Objects. You have many more direct embedding options, and it’s typically easier to work with open source.

One place that will require a radical shift in the commercial BI market is the licensing and deployment model. If you have to pay per seat and want to embed some reports into a call center application with thousands of concurrent users, you may not be able to afford the conventional solution. Operational business intelligence drives a much larger scale of users, albeit with much simpler BI requirements.

If you are deploying on an externally facing website, you may not be able to accurately forecast the number of seats. That means you’ll want server-based unlimited usage licensing, which doesn’t normally come cheap. If demand is higher than you anticipated, the cost of scaling your environment can run quite a bit more as you add servers to meet the workload.

The cost of deploying open source in this context is much lower, both initially and for ongoing support and increased usage.

I once found myself facing exactly this scenario, with a need to deploy simple reporting capabilities outside the firewall. The external web reporting requirements at an average cost of $1,000 per seat, plus the additional server licensing and support, were going to cost me over half a million dollars.

Working with the web and application developers, we came up with some open source tools that would give us the features we needed, and we could integrate them directly into the server components that supported the website. Since we used various open source reporting and graphing components, the cost was zero.

We still had to absorb the costs of development and integration, which were nearly the same as the cost of developing and integrating the website with the commercial business intelligence tool we were using for internal reporting.

Since this was a code-integrated solution, we picked up an added maintenance cost. It wasn’t a full time job for the developers, so it wasn’t that high. More importantly, even if it were a full time job, it would not have cost us more than $100,000, which is what we would have paid annually for a standard BI support contract to cover the commercial BI solution.

Between the cost savings and easier integration into applications, using open source for operational BI makes sense. It all depends on the features you need to provide to users and what sort of application integration requirements you have.

Bron: B-Eye-Network