Panacea or Placebo

Is web based reporting the solution to all reporting woes?

One of the most interesting articles I came across during the course of last year related to the development of what was ARPANET, the forerunner of the modern Internet. 

For the newer and younger generation ARPANET was originally created to allow “educational institutions” to collaborate and share information on strategic military research.

"In 1969 the Pentagon commissioned ARPANET for research into networking. The following year, Vinton Cerf and others published their first proposals for protocols that would allow computers to 'talk' to each other. ARPANET began operating Network Control Protocol (NCP), the first host-to-host protocol.” Connected Earth.

The principal aim of ARPANET was to share information.  What struck me in the article, was both research into, and the call for the reintroduction of a closed community ARPANET environment.

The reasons given are simple:

• The Internet is choked and becoming increasingly slow,

• Commercialisation of The Internet has lead to a plethora of “pay-as-you-go” websites,

• The basic Internet environment has become insecure, leading to confidential and critical information and research being withheld and not publish by the research institutions,

• A closed community of researchers, running a private ARPANET would allow for information and research to again be made freely available within the closed academic community.

The article, author and source in which I found this escapes me, but it has been playing on my mind, ever since I came across it.

My personal quote on The Internet is simple: “The Information Super Highway is dead, all you see now are billboards and toll gates!”. Any puritan involved in communication and / or networking cringes every time they type in a website address, which is in completely the wrong domain. Companies in seeking to market and sell on The Internet, smother us in misplaced domain names. Even the search engines have gone commercial, requiring the payment of significant fees, for the placement of your web address “near-the-top” of the list.  The result, when searching, I often scan the first page (yes the marketing spend does work) and then skip to pages 5 onwards.

So is web-based reporting the answer to all the ills, ever-present in compiled, fixed code applications? From my opening, one could be led to believe the safe answer to this question would be “no”.  However, it is never that simple. There are a huge number of variables and perceptions that need to be considered, not to mention the vast amounts of money being spent by product, server and network vendors in marketing Web-based Solutions as the answer, for everything from convenience to the common cold.

I have watched, with interest bordering on amusement with not just a hint of frustration as, over the last five to six years, most vendors of financial reporting systems touted their web-based systems to all and sundry.  I have even been told that a solution was selected based on the fact that the “financial reporting” system, allowed you to connect to both a news feed and the weather report from selected sources. Profound and inspired decision making if I ever saw it! A secondary comment which came from a CFO (Chief Financial Officer) of a large multinational over the decision to go with a system packed with “cutesies” was simple: “never mind, they obviously don’t understand the problem”. As true as this statement is, I am left wondering if they even understood the question, or if there was in fact a question?

So, ultimately with the choice of answers being:

• Traditional Fixed Application Reporting,

• Custom Report Writing,

• Web-Based Reporting,

• Spreadsheet Based Reporting, or

• Data Warehousing and Cube Reporting

What is the correct answer? Or closer to the truth, is there in fact a one correct answer? Is life a multiple choice questionnaire? In limiting the list to the five above, there will be an inordinate number of complaints, saying that I have left “their“system, concept, method or process out of the list.

The reality is far more simple, and so far more complex than following the bell curve offered by most salesman, or following the selection of customers that they offer.  More often than not, the question and purpose is overlooked. What is the aim of the solution? What do you hope to achieve? And finally, what skills does your organisation have, and how do they work currently?

So now, the world according to Nicholas, the pros and cons of each methodology:

The result of this table, which is neither definitive nor extensive, is not surprising. 

The choice organisations face is:

1. An incredibly simple and easy to use environment, where the report generator (person) can easily manipulate layouts and styles, but also create unauditable and untraceable changes to data, and which requires manual re-capture of data,
   
   or
    

2. A complex environment, where changes to any report or reporting structure require careful consideration, before implementation, highly skilled and well trained staff, in the report generation environment, which is not their core function, that is auditable and traceable, but inflexible and costly.

Scenario (1) has a highly educated and normally very well paid data capture clerk “manipulating” decision relevant information, in which the consequences of mis-capture are astronomical.

Scenario (2) has the same person, either semi-programming reports, and developing software and/or building database skills which are not relevant to employment, or if this is passed back to the IT environment, distanced from and out-of-touch with the source data, from which the information has to be generated.

The final element, which has made web based solutions, initially seem to be the panacea to information sharing’s woes, is portability. All database based solutions, unstrangely enough, require access to the database. All spreadsheet based solutions require access to (a) the source data to generate and update the report, and (b) access to the spreadsheet to view the report.

A reasonably simple task, when on the corporate local network, more complex when located in a distant back-water portion of the corporate backbone, and almost impossible when not connected to the corporate backbone.

With infrastructure and connectivity hindering the rollout of these solutions, developers turned to Web-based technologies for resolution. Simply put, the web platform provides an environment in which a browser is the only software required on the PC. The entire system is housed within the corporate server and delivered over TCP/IP.

The advantages are obvious, a single point of contact, a single security environment and a single common place application interface, the browser. This, coupled with lowered user training requirement, a highly graphical interface and data source independence seemed to resolve the core issues underlying “other” approaches.

Unfortunately, like all “miracle cures” there are constraints and side effects. Top amongst these are:

• Speed – The Internet was designed to share documents, not active data environments, the result is a series of hybrid technologies.

• Maintenance – Web browsers and intermediate servers are designed to cache (store) web page content. Version conflicts are easy to create.

• Bandwidth – The Internet was designed to carry documents, that is, text. Anything that isn’t pure text has to be converted at the server and recompiled into images on the local machine.

• Bandwidth – To compensate for the Version conflicts, web based applications DO NOT allow local or intermediate caching. The result, every page has to be reloaded from scratch.

• Bandwidth – Due to the graphical nature, which users have come to expect with Web based systems, a huge amount of potentially unnecessary graphics and pictures are generally included in web pages.

• Connectionless and Sessionless Environment – This means that Internet technology does not, by its very nature hold a state between the browser and the server.

• Flexibility – by its nature active data is active, and is required to be programmed in html, asp or java; to name a few languages.  So once again the report creator is in a jam. Having to learn how to code and implement to get their report the way they need it.

In saying this, a large number of report writer vendors have gone to great lengths to allow the user varying degrees of control over their reports.

Marketing 101 – The market will decide, as vendors we can influence the market, but at the end of the day, the solutions / products that will gain acceptance and grow are the ones that cost effectively meet the needs of the consumer or client.

So which platform or solution group has dominated … The spreadsheet. For all the inherent flaws included in creating spreadsheets, the spreadsheet is king! Why? There are two core reasons, firstly you do not have to be a developer to create a spreadsheet. Knowing a few simple maths functions is sufficient, coupled with how "office applications” have proliferated and spreadsheet skills being taught from junior school upwards, almost everyone has some degree of knowledge or experience. Secondly, flexibility, reports can be DESIGNED from the ground up by the consumer of the information, Not preformatted.

In no other technological arena, have we seen so much innovation (except perhaps motor vehicles) where the base core concept has not altered. The only two or three possible additions to the spreadsheet world since Visicalc first shipped more than 30 years ago, how people use and interact with spreadsheets have altered little. The majority of people using spreadsheets have only added or embraced wysiwyg (what-you-see-is-what-you-get) formatting, graphing and data connectors, since the beginning. The rest of the applications usage has altered little.

The web, and primarily email, have altered our lives, and for the better, anyone who remembers, however fondly the old BBS (Bulletin Board Systems) for data, information and application transfers can confirm this.

Web based reporting is neither a panacea (cure for everything) nor a placebo. It is an immature technology when it comes to reporting, and has a lot to learn. Fewer and fewer organisations are being wowed and woed by “cutesies”, and are demanding solutions that meet their needs. They have been through the cycle of going oh-my-gosh if you can interweave newsfeeds into a report writer, imagine what the report writer must be able to do!

Until the distinction between the people who are data-providers versus data consumers is fully understood, and the providers are given the flexibility and simplicity of the spreadsheet as a tool to provide the data in, Web based reporting will be viewed as an alternative delivery platform akin to traditional report writers and application based reporting services.

Nicholas Campleman
June 2006

Nicholas Campleman is Group CEO of the Dream Catcher Group of Companies

© Nicholas Campleman 2006