Publishing . . .
What Do I Need to Consider When Publishing Reports?
Most knowledge-workers can knock together a spreadsheet and automate it to spit out neat-looking reports. What turns a chart or table into a high-quality management report is the publication process. This has little to do with technology and a lot to do with effective management. What follows are some items to consider and discuss with key stakeholders, broken down by Technical Architecture, Publishing Environment and User Experience:
Technical Architecture
- Platform - It's important to be clear what platforms will be used to access the reporting application. What needs to be supported in terms of network bandwidth, response time, screen-size, colours, operating systems and other software, processing grunt, memory and so on? People will be most unhappy when they discover they can't get the whizz-bang new Flash-based reports on their Blackberry.
- Delivery Method - You've still got to deliver the file to a user's machine. Broadly speaking, you can employ "push" methods (where the reports are pushed out to users via eg email) or, more commonly, "pull" approaches (where users initiate the request). Various methods are employed including HTTP, FTP, RSS and SQL. Depending on your IT environment, reports can be accessed by sharing hard disks. And don't forget SneakerNet - copying the reports onto a CD, floppy disk or flash disk and physically carrying it around.
- File Format - In a similar vein, specify the acceptable file formats for reports. This will determine what applications can read the reports and what functionality can be incorporated. Common types include plain text (everything), csv (spreadsheets), HTML (web browsers), XML (specialised software), PDF (Adobe Acrobat) and XLS (Excel).
- Availability - In terms of internet publishing, it's natural to think about 24/7/365 ie reports are available all the time. However, talk to any engineer and they'll tell you that 99% (of that time) is definitely doable, but that "five nines" 99.999% is unachievable - and unwarranted - without a NASA-type effort. Since we're talking about management reports, it is reasonable to restrict the uptime to normal business hours (say, 8am to 6pm, Monday to Friday), and downtime (planned or unplanned) of even half a day or more should not be a calamity for your organisation. If delays or outages like that are not acceptable, it's a sign you're instead dealing with operational reporting.
- Dimensioning - Chances are your reports have to reside on a computer somewhere. This means you need to think about network connectivity and storage space. Before you rush out and buy something, think carefully about (a) How many reports are we talking about? (b) How many users can we expect? and (c) How much growth are we expecting? You'll need to get out an envelope and work out how much disk space to purchase (allow for storing various logs, datasets, reports, plus archives). Next, for network connectivity (bandwidth) you'll need to gauge the peak throughput - start by estimating the maximum number of simultaneous users and then multiply by the maximum individual download speed. I'd suggest that a particular management report shouldn't take more than 30 seconds to view (including query time, network latency and rendering delay). You can do more fancy things with queueing analysis, but this should suffice for most purposes.
- Business Continuity - While there's a range of backup and fail-over hosting solutions on offer, the tricky bit with business continuity planning is get a handle on how serious outages really are. For management reporting, it's unlikely that an hour or two of downtime will send the business broke. Rather than pumping cash into hosting your reports in converted ICBM missile silos on three continents, you're better off following sound backup practices (store them off-site and regularly test your backups!) and having a "Plan B" for production of critical reports (by hand, if required) and delivery (email or - if desperate - hard copy mail outs).
