Reporting for Duty - Transcript
Transcript of interview with the VP of Product Management at Actuate, Paul Clenahan
MIKE VIZARD: Hello, and welcome to a premium edition of ACM Queuecast, sponsored by Actuate, a leader in business intelligence and enterprise reporting solutions that has made a significant contribution to the Eclipse community in the form of a Business Intelligence and Reporting Tools project, otherwise known as BIRT. I'm your host, Mike Vizard, and joining me today is Paul Clenahan, Vice President of Product Management at Actuate, and a member of the BIRT Project Management Committee, who's here to discuss future trends in reporting tools. Welcome to the show. How are you?
PAUL CLENAHAN: Good, thank you, very good.
MV: I guess one of the areas that developers tend to overlook or tend to think of almost as an after thought after they build their application is the whole reporting tool structure. Why do you think that is? And why do you think developers need to kind of rethink the importance of reporting tools?
PC: That's an interesting question and something that we've certainly seen many times over the years, that developers, when they're building an application, a lot of the focus initially is around perhaps the process of the application design to improve and make more efficient the data gathering, the mechanics, if you like, of the business problem they're trying to address. And then what readily becomes apparent, once you start to pool all the data into the application and you're managing the process and so forth, is that there's a lot of data in there that users start to say, "Well, I need to get some reports that show me how this customer's doing, or how my orders are tracking," and so on. So it's something that maybe doesn't necessarily come up as a requirement initially, but then very rapidly the user base, and then ultimately the developers realize, "Wow! There's a lot of great information in here. How do we publish it?" And then of course the second wave of problems in a lot of traditional application development comes along, which is the process for getting the information out. Developers have historically quite often used GSP code, built some simple Web pages to do that and so on, which doesn't really give the users what they want in terms of powerful reporting. So what we saw as an area that really could be improved in terms of helping the development of tools in this area is that idea of pulling data out and being able to publish it.
I think, back to your question of how do developers need to change the way they think about that, well, certainly thinking about, you know, "I get this good information, and how do I publish it?" early in the application design process is important, but they're going to hear that naturally, and I think do hear that naturally from their users, as well, as they start to use the application.
MV: Has there been any kind of downstream effect from all the focus on compliance where developers now are more conscious of their reporting tools because there's just more of a requirement from auditors and the like as to what's going on around the actual application?
PC: Yeah, I think so. I think that, as you have already hinted at, one of the major aspects of compliance is reporting. It's knowing what's going on in the organization and what sort of information is out there. So I think what happens effectively is the users bring that requirement to the table more explicitly, and that then necessarily draws attention to it from a development standpoint, as well.
MV: There's a tendency, especially I guess among Java developers, where they can readily get a handle on some Java class tools for doing their own reports, so why should they be looking for something a little more robust, and if you can draw the connection between that line of thought and maybe some of the work that's going on in the Eclipse community, that would be great.
PC: Mm-hm. So certainly the traditional way that developers have approached this is to look at it, you know, using class libraries of various types, various types of technologies to solve the reporting style problem. And I think that's just a natural tendency from the developer to work with something that they're comfortable with. We looked at this general need, which ultimately led to us saying, "Look, we need to provide technology that enables Java developers to include more effective reporting capabilities into their applications." And realizing that we need to do that, it made sense to do it as part of the Eclipse foundation because a lot of Java developers, of course, use Eclipse as a development environment, a very powerful development environment with all the capabilities it provides made it sort of a natural fit. How can we provide or address that problem in that space?
And that's what led to us saying, "Right. Fine, let's take the idea of class libraries components developers are going to want to use, and extend that into the reporting space," and this is a part of the project that we're doing�a set of class libraries that allow you to embed reporting into your application.
So to a certain extent, the approach we're taking is not completely alien to the Java developer. What we've done with the project, though, is to lift up a level and also say, "Fine, we provide the Java componentry and library to help run the reports, but let's also provide a rich visual design environment and a model that allows developers to very productively design the reports and actually lay out what the reports are about."
So when we talk about the BIRT project, the Business Intelligence and Reporting Tools project, our goals are within the Eclipse foundation to provide two major components -- a design time capability for designing reports, and you're doing that design time activity in the Eclipse environment, as well as a set of run time libraries for running the report. And those are a series of Java class files that can be deployed into any application, any Java application, most likely one that you're building with Eclipse, but not necessarily restricted to one you're building with Eclipse.
MV: Who's in charge of BIRT, exactly? Is this just something that you run, or is it in collaboration with other vendors and that's what gives it some extra weight?
PC: It's definitely a collaborative project. Like many open source projects, I think the success of the project, one of the criteria that is used to judge a product, if you like, is the participation in a broader community. And when we look to the BIRT project, and certainly Actuate is extremely active in the project, we were the founding member, kind of got the project going, but right from the get-go, we had participation from other companies, including Innovent Solutions, which is a vendor who specializes in consulting in the reporting space. IBM is also a member of the project. They are using BIRT technology in a number of their technologies and products. And in fact, most recently we've had a company called InetSoft join the project, who is another vendor in the reporting space, who are bringing their Java reporting expertise to the project and adding new capabilities in that area.
So definitely a project, if you just look at active participants, that�s multi-vendor, and not just across the general industry, but even within the reporting segment. And then of course the broader community participation is very important. We've got a very active news group. We're actually seeing some of the bugs that get posted in Bugzilla. We're seeing patches getting posted with that to essentially address those issues. In fact, we're even seeing some Bugzilla entries with enhancements: new chart types, for example. And so all the sort of criteria around open source with participation from other projects or other mix of participants, I guess, would be the way to say it, is something you're seeing with the BIRT project.
MV: So given all of that and given what's available from an open source standpoint, what's the value added you guys provide around or on top of BIRT?
PC: Yeah, so from an Actuate perspective, what we wanted to do was to be very active and to lead this project in providing core reporting capabilities that Java developers can incorporate into their applications, and doing that as part of an open source initiative, the BIRT project. On top of that, we also recognize that there is a broader spectrum of things that developers and users typically want to see in their applications around the reporting space, and so our focus as a vendor is to essentially layer value on top of that core open source, very powerful I might add, but that core open source, that BIRT capability.
Some examples in that area include things like scheduling of reports, e-mail distribution of reports, management of report documents, including archival security and so on around that, as well as even adding value around things like when you're viewing a report, providing capabilities to be able to interact with that view, so instead of looking at a report as a static Web page, if you like, but to be able to interact with that by clicking on column headings to re-sort the report, perhaps add additional calculated columns and so on. So these are examples of value-added technology that we're providing on top of the core BIRT capabilities to basically address a broader class of problems that we typically see in the general reporting market space.
MV: As you look down the road at reporting technology and where BIRT is headed and where you guys are headed, what are some of the highlights that you think people should be looking forward to in the coming years?
PC: Well, I certainly think that this idea of interactivity with reports -- and one thing that we are talking about a lot and I think is a technology or an approach to technology that's working very well is the idea of collaboration, as well. Very traditional models of reporting in the business intelligence space overall tend to think of things as silos. You have operational reporting, which is a certain style of reports. You have ad hoc query and reporting, which is maybe business users creating reports and more interactivity in the reports, and then there's analytics, which tends to be more slice and dice exploration of data, looking at trends and so on.
Historically, these have been viewed as distinct silos or different approaches to business intelligence. And what we've done using the BIRT technology at its core in our Actuate 9 release is to blur the lines between operational style reporting, where you're maybe doing something as simple as a commission statement, and that idea of ad hoc query and reporting, which is maybe business users creating reports, certainly a lot of interactivity around reports, being able to not just look at a static Web page as I mentioned earlier, but to be able to re-sort that and so on.
And what we've done in the Actuate 9 release is blur the boundaries between those. No longer do you have to use one technology for operational reporting and a different technology for the ad hoc query and reporting space. That is getting a lot of traction in the market. We're finding users really like that idea because, let's face it, users don't think that way. They don't think in vertical silos of technology. They think of a reporting problem they're trying to solve and they just want technology to do that. So from a user's perspective, those lines are blurred, and that's what we've done with the Actuate 9 technology.
Looking forward into the future, I think it�s interesting to ask, "Well, can you start blurring those lines further into different types of reporting capabilities, as well?" So that's certainly one dimension that is interesting.
I think the other dimension, as well, is how we can further integrate reporting into the application experience. One of the things we're looking at from a BIRT project standpoint is what capabilities can we provide to make it much easier for the application developer to embed reporting into the applications they're building. Today we provide a very rich set of libraries. We provide that design tool that I talked about. But how can we make it easier to actually embed the reports into the application?
And I think what we'll see over time, as well, is that that idea of embedding reporting into applications is starting to happen more and more -- and it's one thing you'll see in the industry a fair amount today -- this idea of more in-context reporting becomes increasingly important. By in-context reporting, I mean the ability to access a report, not from a separate stand-alone tool, but from within the application you're using.
That idea of blurring those lines in the development side of things also starts to get interesting when you extend into the Web 2.0 environment, and what does it mean for BI and reporting in a Web 2.0 style application. So these are all areas that we're looking at from a project standpoint.
MV: So given that, it almost sounds like the report becomes an integral part of the business process. It's pointing at multiple data sources, whether it's a supply chain or a CRM application, and the report in itself not only generates a physical report, but could start kicking off related events.
PC: Yes. It's certainly possible. And certainly I absolutely agree with the first part of your statement in terms of reporting being really a core part of the application. Reporting shouldn't be viewed as a separate application, a separate process. We believe very much that reporting is simply an aspect of the application, and the BIRT-based technology and the technology that Actuate provides in a commercial site allows you to achieve that integration.
And as you said, I think that naturally leads to the reports themselves, actually then driving other activities in the overall process. And that's something you can certainly do with the BIRT technology, as well. You can actually, from the rich scripting language that BIRT provides, start kicking off other events within that. The extent to which you want to do that is really up to the application developer. Our perspective is we provide a rich reporting framework that allows you to embed deeply and also do things like calling out from the reports to other applications, and then it's kind of up to the imagination of the developer who's integrating the technology how they want to actually apply that.
MV: Where do you see the crossover between what we today refer to as reports and what we also generally refer to as business intelligence?
PC: Yeah, always an interesting question, that one. You know, it depends who you ask, what their particular definition of business intelligence is. When I generally talk about the market, I'll be general and talk about business intelligence and reporting as one general market. And I think that's increasingly the case. Historically perhaps you could say that business intelligence was more about reporting against the data warehouse type information. Typical users were perhaps more the business users, power users rather than professional developers.
But I think those lines are blurring and certainly with Actuate technology, both in BIRT and again in the commercial side, we see our technology used a lot, and we see BIRT used a lot, reporting against not just data warehouses, but operational data stores, or even non-traditional data stores such as Xmail data sources, flat files, Web services, and so on. And so really I think that what's happening is BI was traditionally more data warehouse-centric reporting. Reporting in its sort of pure sense historically was about operational reporting. And I think those are blending now.
A classic example might be, fine, you've got a lot of great data in your data warehouse. You're writing reports against your data warehouse -- whether it's a business user or an IT person that's doing that reporting � and you might be able to report on that summary or aggregate information, but at some point you may be interested in pulling in some information that doesn't live in the data warehouse. And depending on your data warehouse architecture, that may be detailed call records if you're a telephone company. Well, this sort of technology allows you to, yes, do some reporting against your data warehouse, and then, as needed, pull in additional information from your operational stores, or perhaps another report that operates solely against the operational stores.
MV: Are we getting to the point where maybe we don't need the data warehouse because we're going to be able to look directly against the operational data, or are just the roles kind of shifting?
PC: I think it's more of a role-shifting, or perhaps another way to say that is sort of more flexibility. Depending on the sort of data stores and the data architecture you have, I think there'll always be a role for the data warehouse. A simple example would be in the area of tracking data over time. Operational data stores quite often reflect data as of today, but may not do an adequate job of reflecting how data trends or data changes over time. The sort of historical aspect, if you like, is something that is absolutely captured in almost every, or probably every data warehouse architecture.
So I think it's just more flexibility. I don't think you'll see one disappearing over the other. I think it's about more choice. I certainly would feel that there is less demand that you have to create a data warehouse to do reporting. We've seen this over time historically ourselves, and I think that the trend is continuing to push in the direction that it makes sense in many cases to report against operational data.
MV: So in summary, it sounds like there's two take-aways here. One is, as a developer, you don't necessarily want to spend your time reinventing the wheel to create the reports in the first place. And the second concept here, though, is the reports themselves are becoming more integral and more crucial to the business process, and therefore the integration challenge is higher, so there's another reason why you might want to reach out to a vendor.
PC: Yeah, I think so. I mean, clearly, to address both of those problems, you could build it from the ground up, but from a time-to-market standpoint, obviously a cost aspect that's related to that, I think it makes sense to look around at the market both in terms of open source -- you know, what capabilities are there -- as well as looking to vendors like Actuate to say, okay, you said they were reinventing the wheel. Do I have to reinvent the wheel, or is it going to give me a faster time-to-market, where I can use technology from a vendor that really allows me to solve critical business problems much quicker.
I think an aspect of that, as well, just to reflect on some history or experience we've seen there, is that often the role of your own solutions, they can do an adequate job, but when you actually look at user satisfaction level with the application, they're relatively low because again the user wants to get the data out of the application in a usable way. And if you're restricted to a relatively slow development process for the reports, then it's very difficult for the user to get the high value out of the data. So I think user requirements or user expectations, as well, is a factor that's going to kick in there.
MV: Great. Paul, last question. Best advice to developers who are struggling with these issues, what would it be?
PC: Well, I'd certainly say the best advice for sure is don't try and reinvent the wheel, don't try and build reporting from the ground up with GSP code or Java code. There's a good number of open source reporting technologies out there. BIRT is an excellent technology. Of course that's a biased opinion, and certainly I'd encourage any developer to check that out. Easy way to do that is eclipse.org/BIRT. And you can also get the technology from Actuate, www.actuate.com/BIRT. And I would say check out that technology, see how much it can really improve your productivity in getting the reports that your users want built into your application.
MV: Paul, I want to thank you for sharing your time with us today and best of luck in your future endeavors.
PC: Great. Thanks very much.
MV: If you're interested in trying BIRT, you can download it from Actuate at www.actuate.com/BIRT, that's B-I-R-T. One of the advantages of downloading from Actuate is that you can get an integrated install that makes it easier to get up and running with the reporting technology. In fact, the Actuate download includes a number of additional data drivers that are quite useful. In general, for the other capabilities that were talked about, you can go to www.actuate.com or call 1-866-217-1838.
Originally published in Queue vol. 5, no. 1—
see this item in the ACM Digital Library