A different approach to spreadsheets

EASA Software is a spin-off from the UK’s Atomic Energy Authority that was founded in 2000. Its original remit (and it still does this) was to build a front-end to complex engineering applications that made those applications easier to use. One of its customers, Proctor and Gamble, then started to use EASA’s software as a front-end to its financial systems (which were built using spreadsheets) as well as to its engineering and design applications. P&G reported this back to EASA, which has now productised this functionality.

EASA’s spreadsheet management software is a spreadsheet automation tool. That is, it enables the creation of spreadsheet applications whereby the original spreadsheet is held in a database (either SQL Server or Oracle) on a central server and the information for the end-user is served to them in a dynamic fashion within a web browser. This means that you can assure that users always have the correct version and that security is maintained. Users only see what you allow them to see and they can only change what their role allows them to change. The segregation of duties (owner, developer, auditor, user) is supported.

In addition, there are two other important points. The first is that users do not have to see the information presented to them in spreadsheet format: they can where that is appropriate or the data can be presented in, say, graphical format (trend graphs, for example) for reporting purposes. Secondly, the EASAP (EASA program) Builder that you use to build your front-end applications enables the inclusion of information from other data sources within your application and it also allows you to include such things as data validation rules, parameters and so forth.

All of this is good but is not significantly different from other spreadsheet automation tools. However, where EASA has a significant advantage over its direct competitors is that when you are using EASA you use spreadsheets to build your application in the normal way and then you use the EASAP Builder to define the end-user interface. In other words, you use spreadsheets for logic and EASA for deployment. Other spreadsheet automation tools take the opposite approach: you use a template-based development method, a similar server-centric basis for providing the data, and then present data to users in what looks like a spreadsheet (again, via a web browser).

It is important to understand the difference between these approaches. Put simply, EASA applications can be defined on top of existing spreadsheets, while other spreadsheet automation tools cannot do this: they are targeted specifically at new spreadsheet applications. EASA can, of course, be used for new applications too.

Another advantage of this approach from EASA is that, because it can be used with existing spreadsheets, it is complementary to the providers of control and compliance tools such as those offered by Compassoft, Prodiance and the like. This is because EASA can take direct advantage of the discovery capabilities offered by such tools.

EASA’s spreadsheet solution has only recently been released and the company has only just started to take it to market. As one might expect from such a new offering the product is not yet complete. For example, I would like to see more workflow capabilities and version control down to the cell level. However, these features will no doubt come. More importantly, EASA is the first company (as far as I know) to enable the creation of spreadsheet applications both for new applications and based on existing spreadsheets. Thus it has a significant advantage within the marketplace.