Fifteen months ago the founders of Azquo, Dave Williams, my son Edd, and I left Feefo and founded Azquo.
Azquo was a new company, but the product was not new. It was a development on a previous product of mine, originally called ‘Ark’ (a DOS product) then ‘Toto’ (a Windows product) which I and my partner Rupert Armitage had sold into a number of FTSE companies in the 80s and 90s.
Ark and Toto roughly fell into the category of ‘OLAP’ products. Online Analytic Processing was, and is, the jargon for the creation of reports that are useful to managers outside the remit of the standard transactional reports. The key feature of an OLAP database is flexibility of reporting rather than transactional integrity. Ark and Toto had three unusual key design priorities
- they were databases designed to accept all types of data
- reports were created in spreadsheets
- all data was tagged with ‘provenance’ (who put it in, when and where)
Of course, products of this type should be produced by large teams of developers, and sold for six-figure sums, but we were not very good commercially, and were trying to create a product that could become popular, so our pricing model was wrong for the time. We did manage, with partners, to create programs to analyse the exam results of half the children in the country through local authority education departments, but the growth impetus was too slow.
I then became distracted by running, in succession, a company that imported and sold garden trampolines (don’t ask me – another story entirely) then Feefo, the independent feedback company, which, I am glad to say, still flourishes.
So this enterprise was not new. But the circumstances are new. The internet did not exist when we started; PC memory was measured in low numbers of megabytes; much less data was flying around in companies; a number of standard packages for accounting, online shopping carts, etc have become ubiquitous on the basis of their suitability for their key task with little regard for reporting. All these factors lead me to believe that this was the right time to dust off Toto.
We started with a simple attempt to update Toto – this involved creating a ‘multi-dimensional’ database online and a series of Excel macros that could fling the data back and forth to the database. In retrospect this was an extraordinarily ‘clunky’ way of creating a product suitable for 2014, and it rapidly showed. But even at this stage we discovered that, while the original products had always completed tasks by fetching bite-sized chunks of data from disk, processing, then saving, this technique was simply impossible with today’s quantities of data – there was no alternative to an ‘in-memory’ database. Persistence to disk is only for disaster recovery and to clear memory in periods of disuse.
The product soon morphed into one with an on-line spreadsheet interface, and, once we had realised the potential performance we could achieve with an in-memory database, it then morphed into a system that could deal well with data at the transactional level, rather than the granular summary that we had been obliged to use before.
This is completely revolutionary as it means we can now import transactional data direct from all existing databases – we’ve made a start with our Magento plugin, but that will be followed by quick import techniques from other online shopping carts, Sage, Google Analytics, and all other generally used sources of data.
As with all new ideas, often the most difficult task is to explain to potential buyers what our system will do better than others, but we are in the fortunate position that we’ve rapidly discovered that there are severe limitations in Magento reporting, and that statutory reports also present a particularly annoying workload on many companies. Initial work with a few test companies is highly promising as we have rapidly shown that we can make light work of what is difficult or impossible with standard databases.
But this post is already too long…. more later.