Reporting 2.0 will bring end-users and developers together

I`ve learned in 10 years as an IT professional that most developers hate to write reports. Most developers feel report writing is beneath them and not something they were hired to do. But then you also get very good report developers who enjoy giving end-users all the information they need, in whatever format they desire it.

The reality is that report development is a necessary evil for most developers, and even seasoned report developers would love to enable end-users to help themselves when it comes to report creation.

Allowing end-users access to back-end databases comes with its own set of challenges. Software vendors have struggled since the dawn of reporting to create a tool that enables end-users to create their own reports, effectively.

Traditionally, the biggest concern is the potential creation of queries that can crash operational systems, such as an end-user unknowingly creating a complete row-by-row transactional report off a 100 million-plus sales transaction table. In order to prevent such queries, most ad hoc reporting tools have ways and means to contain or limit the number of rows returned for each query.

Until all PC users learn how to program database queries (which will be never), some form of data set size control still has to reside with the report developer.

The problem is that end-users want more reports, to do more with their current reports and not wait for IT to deliver them, and this is more true than ever before. Reporting tools should allow end-users to add charts and sub reports, and offer seamless export functionality to familiar products such as Microsoft Excel and Outlook. If you have a good look at what reporting tools are available in the market, many of them are great for developers, but none makes the grade as pure end-user-focused tools.

I`ve also learned that most organisations believe they have too many reports. But what is too many? It`s difficult to find the information delivery sweet spot, so to speak. Most reporting audits find many duplicate reports, or many near similar reports, where columns, filtering and layout have been slightly altered, but the underlying data is still the same for all these reports. Copy and paste functionality has its place, but in report development its excessive use leads to a reporting administration nightmare.

It`s time to be clever when it comes to reporting. We must start to repurpose report objects, rather than to copy and paste them. We need to make it easier for end-users to use report objects, while still controlling the amount of data returned. We need to cut down the time it takes to develop reports, drastically. We need to be able to report of any data source of our choice.

Every other market sector has had its 2.0, so what does the next wave of reporting tools have to offer to deliver on the promise and solve many of the current issues?

Here is a checklist of functionality that you should be looking for when assessing where to go with your reporting platform:

* Quick build: End-users should be able to drag, drop and format reports themselves in a user-friendly and easy-to-use interface.
* Quick deploy: Once built, the report should be able to be published and used quickly in other areas of the organisation.
* Social community: Users should be able to use objects, database queries, formatting and charting created by other users anywhere else in the organisation.
* IT control: Like it or not, the IT department will not endorse or support the reporting tool if they cannot exercise control of the back-end.
* Flexible publishing: The end-user should be able to publish in pretty much any format - Web, Office, PDF, CSV or to a portal.
* Single point of maintenance: Should a data query, business rule, source system, company logo or any common objects change, an end-user should be able to change it in one place and have the change cascaded through all reports and queries using that object.
* Open code base: No reporting tool can deliver on all the needs of all of the users all of the time. There will always be some element of coding to customise. The code set used must be commonly understood and used. Locking customisation in a proprietary or difficult to use coding or scripting language is a step back. The more lines of code you have, the harder it is to find stuff and the more code you get.
* Multiplatform access: The tool should be able to access and report on data from a number of different sources and cater for data in a number of different formats.

Reporting 2.0 is all about social programming, where users and developers alike can have the independence they seek, leverage what others have already built and deliver in a format they choose. And all of this in a fraction of the time they are doing it now.