TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

BIRTh of a Notion

Can the open-source BI Reporting Tool (BIRT, for short) displace more powerful—and costly – third-party offerings?

• By Stephen Swoyer
• March 15, 2006

Since its debut more than two years ago, SQL Server Reporting Services (SSRS) has become immensely popular, such that it’s now poised to challenge third-party reporting solutions for market share.

Don’t look now, but the open-source Eclipse Foundation might have a similar Wunderkind on its hands. The Eclipse BI Reporting Tool (BIRT) project will turn two in August. The lovechild of enterprise reporting specialist Actuate Corp. (which donated code and full-time technologists to the effort) and the open-source Eclipse software community, BIRT is a J2EE-based reporting solution that plugs right into the ubiquitous Eclipse integrated development environment (IDE). Eclipse is as popular among Java programmers as Microsoft’s (similarly omnipresent) Visual Studio IDE is among .NET codejockeys.

The similarities don’t end there, either. Like Microsoft’s SSRS offering, BIRT combines an embeddable reporting engine, report lifecycle management capabilities, and a client authoring tool. And, like SSRS, BIRT has an ace up its sleeve: enterprise developers. Just as Microsoft could count on a huge built-in audience—among Visual Studio programmers and SQL Server codejockeys alike—for SSRS, so BIRT expects to be the de facto (if not the default) choice for J2EE developers. The first BIRT release (version 1.0) went gold last June, and—in January—Eclipse and a number of partners (including IBM Corp. and open source BI upstart Pentaho) trumpeted the availability of BIRT 2.0.

So does BIRT’s adoption curve match that of SSRS? In other words, is BIRT first being taken up by enterprise codejockeys and—as it becomes an ever-more important player in an organization’s internal app dev ecosystem – subsequently displacing third-party reporting tools? Not yet, many BIRT users say. If anything, they indicate, BIRT is mostly displacing competitive J2EE reporting solutions (such as JReports, Jasper Reports, and JFreeReports), along with ad hoc tools. As BIRT and J2EE become more integral components in the enterprise application future-scape, however, this could change.

“We didn't look at commercial reporting tools because BIRT looked good from the start and it's free,” says Vladimir Perlov, a J2EE developer with a Brooklyn-based healthcare organization. “We don't have very high requirements for performance and functionality of the reports that we are developing. I know only one important feature that [is] missing from BIRT—support [for] crosstab reports.”

Perlov, like a lot of his colleagues, did consider at least one pay-for-use J2EE reporting solution, however: Jasper Reports. “We have looked closely only at Jasper Reports. I choose BIRT because this framework has [a] rich XML-based model, use plug-ins and supporting server-side JavaScript.”

For now, Perlov and his employer are tapping BIRT mostly for use with their J2EE app dev efforts. In the future, however, Perlov says he expects that his company will try to build out an open-source BI stack, based not just on BIRT, but also Mondrian, Pentaho, or other open-source BI tools. “Probably in two years we will try to integrate this kind of software, but not now,” he concludes.

Mark Lorenz, an application architect with a major healthcare company based in the Southeast, is bullish about BIRT and its long-term prospects. Lorenz says he’s already tapped BIRT to replace two third-party solutions, and expects that the Eclipse-friendly reporting tool will have a much bigger role to play in his company’s application future-scape. “In the past, we have used FOP [http://xmlgraphics.apache.org/fop/], which is a low-level PDF framework. [FOP] was very difficult, brittle, and time-consuming to use. That was [the] driving force to look for a better way. We also looked at iText [http://www.lowagie.com/iText/], which was meant to make PDF generation easier. However, we had technical problems with that as well,” Lorenz says. For a while, too, Lorenz says his employer thought about going the third-party route. While BIRT didn’t displace an existing third-party solution at Lorenz’s company, it did effectively knock such a tool out of the running, although there were other considerations. “At one point, we planned to use Crystal Reports, with technical staff creating reports and then distributing them along with our product. This was a problem with buying the product, learning how to use the product, administering the product installation and configuration and upgrades, and then having a relatively large amount of time spent on report creation and editing separate from our development processes,” he explains. Lorenz says he considered at least one third-party J2EE reporting tool (Jasper Reports), but ultimately decided on BIRT. “I came across BIRT and it fulfills our needs: it is fully integrated with Eclipse—which is our development environment—it uses standard technologies … [such as] JavaScript for its scripting language … it is extremely powerful yet easy to use, and it has a strong and active support community [See http://marklorenz.blogspot.com for more details].”

Right now, Lorenz concludes, BIRT is mostly a fixture in his company’s J2EE app dev efforts. But that could change. “To date, BIRT has only been used for J2EE application development, but since it also can be used from other technologies and also embedded in an application when report creation is a requirement, we will certainly plan to use it in those situations in the future.”

Of course, not everyone who puts BIRT through its paces ends up a convert. This isn’t necessarily an indication of insufficiency on BIRT’s part, however. Instead, it’s more a reflection of the realities of enterprise software development, which often rejects third-party tools or plug-ins in favor of ad hoc approaches. “We decided not to use a third-party reporting tool at all, since our internal SQL modeling is sufficiently rich to give our customers [90 percent of what they need],” says Paul Womack, a J2EE programmer with a UK-based app dev consultancy. “To cover the remaining 10 percent of our customers’ requirements, we generate [comma separated values] CSV from a ‘closest approximation’ SQL query, and recommend that our customers use pivot tables in Excel.”