Back-ends and Front-ends

Posted by David Carter PM | on Fri, 28/05/2010 - 20:04 351 1 comment | report

Many IT professionals simply refuse to take Excel seriously as a tool for management reporting. Why this gut rejection of Excel?

To understand their attitude, you need to distinguish between front-ends and back-ends. In IT terminology the front-end of a software package is the interface - how it presents itself to the user. The back-end of a package is the way the data within it is stored and managed, the database management system (DBMS).

A good front-end makes a piece of software attractive, flexible and easy to use. A good back-end makes it work, and the data within it accurate.

Excel has a very good front-end, but its back-end is non-existent. The total flexibility that makes Excel so attractive to users makes it a disaster as a data store – no discipline, no reconciliation, no version control, no accuracy. Typically the user either types in the data, or cuts and pastes it in from somewhere else, then applies lots of formulas which no-one else can follow. You’ve no idea whether it is accurate or not – the whole thing is a dog’s breakfast.

When IT professionals instinctively reject Excel, they are assuming you want to use it as a back-end data store

To get them on your side, you have to patiently explain that you intend to use Excel simply as a front-end to analyse company data. That data will remain snug and safe in a the company's SQL database (or Oracle, or whatever).

This should calm them down. Then, to prove to them that Excel is THE tool for serious data analysis, show them this video of Project Gemini processing over 100 million records.

http://www.youtube.com/watch?v=Zp0AADaW3QY

Comments

lacking standards and discipled approach

Anonymous | Sun, 30/05/2010 - 12:31 | Permalink

Came across a situation once in one of the big 4 where a senior manager was very keen on spread sheets - however

he was on £70K pa (10 years ago) - i.e. good value for money writing spreadsheets
he spent the majority of his time fiddling with them
he subsequently distributed them over the entire department & wanted them placed on servers etc ....
they went wrong
each user subsequently tried to adapt them for their own specific purposes
the IT department was expected to pick up the pieces and field unstructured, un-commented, business specific spreadsheets

It is not that Excel is not taken seriously, but rather it is taken too seriously and the IT areas understand the impact of their actions whereas users sometimes do not

The real questions have to be

when was the last time most users of Excel were trained on the subject. This becomes even more important where eveyone suddenly becomes a VBA expert overnight
when was the last time a user actually specified something before just jumping in an producing a spreadsheet
when was a spreadsheet last documented - or at all
is their resulting offering ever validated or sense checked or had a code review
when have you ever know a spreadsheet be properly tested

If you can confirm that all the above points have been adhered to then no problem - otherwise ...............

So it is not really about a love/hate relationship with Excel but adopting a practical disciplined approach to producing spreadsheets that provides a comprehensive audit trail if the author leaves. In other words an Excel 'risk assessment' which seems to be an alien concept with a lot of Excel spreadsheets

Add comment