In the late 1980s the programming language I had developed for farming was superseded because PCs became more powerful, and MSDOS had become the basis for all PC programs, so I started looking for other opportunities.  Out of the blue, I received a telephone call from Rupert Armitage.

 I came to know Rupert very well in the next twenty years, during which time we were the partners and owners of a small business that, at various times employed up to 10 people, but mostly was the two of us with one or two helpers, so I’ll give you a bit of background on Rupert. 

He was also educated at Eton.  That’s not always a plus point for me, but he had disliked Eton so much that he had left as soon as he had taken his ‘O Levels’ – aged 16.  After school he had travelled around Europe with his brother, including into Eastern Europe, which was adventurous in those days, then ended up in Saudi Arabia, where he somehow managed a telecoms company as part of the Bin Laden empire, and was a personal friend of Salem Bin Laden, the head of the business.  He had a fund of stories of travelling with Salem in his jet (Salem was a qualified pilot), threatening to be sick over the plane if Salem continued any aerobatics.

Rupert went on to work in San Francisco as a management consultant, then returned to the UK, still as a management consultant, with a company that had an ambitious project to produce an ‘expert system’ in marketing.

This was the period when the first effort at AI was being grossly over-hyped.  The idea was that if the computer asked the right questions, it could behave like an expert, and give good advice.  This was, as we know now, ridiculously ambitious (and made me very sceptical that the current AI vogue would be any more successful – but that’s where I started, and is for many other posts!), but many consultants saw an opportunity here.

Rupert had a different slant.  He saw that the business for whom he was working was flailing around and spending large sums of money with little result, so he decided to try for himself.  He persuaded a colleague who who had an MBA to leave the consultancy to form a small business on their own.

At supper with friends he told someone of his idea, and asked whether that person knew of a suitable techie who could help.  That’s how he came to ring me.

I did look at the products touted as ‘Expert Systems’, and even bought one, but the process was very laborious and restrictive.   As an exercise I tried to create a ‘wine chooser’.  It was based on the user being able to select qualities he or she was seeking, and the importance of those qualities.  This turned out to be an app quickly created using my existing programming methods, but was not picked up by Majestic Wines when we showed them.

The rest of the time, I tried to think about marketing in general.  Our MBA partner seemed curiously inexplicit, so he did not help, but a few ideas crystallised.

• Marketing is done in spreadsheets
• The data required for marketing is constantly changing. Marketers may not know at the outset what data they need
• Spreadsheets do not interface easily with databases

It seemed to me that nothing could be done unless we first had a database that did interface with spreadsheets.  Not only that, but the database must be able to accept any data at any time without reference to the IT department, and it must behave, as far as possible, in a way that users expect.

The key recognition was to understand how people ‘read’ data in a spreadsheet.  In any particular cell they understand the value to be represented by the row and column headings in the sheet (which may be multiple) and often also by the ‘context’ – usually shown elsewhere in the sheet that applies to all the cells in a grid.

For those unfamiliar with IT, this may seem to be obvious – how else could we understand a grid of numbers?   But that’s not how IT people saw it, and, indeed, still see it.   To them all ‘data’ sits in ‘tables’ with ‘records’ (or ‘rows’) and ‘fields’ in the row.

Of course we often look at lists and we understand them by looking at the headings at the top, and there are occasions when we look at spreadsheet in that way.  And it is true that, mainly due to the excellent ideas of Edgar Codd, a ‘universal’ way of storing data was created together with a universal ‘language’ for communicating with it called SQL (Standard Query Language).   This was a very convenient way of storing data in the relatively limited storage space available to computers at that time, both in immediate memory (RAM -Random Access Memory) and on long term storage – floppy, then ‘Winchester’ disk.

But this is not how humans think of data.  If I ask you the temperature outside today, your mind does not hold a list of temperatures from which you chose the relevant one.  We think – temperature – Ludlow (for me) – May 2^nd – a value we happen to know which has the correct tags attached.  If we are asked how many apples we sold last week, we try to remember the apples sold each day and add them up.  In short our minds see ‘data’ as concept hierarchies with individual ‘values’ sitting within the concept hierarchies.

In an independent report slightly later (1995), the authors had to make up a name for this structure and described the structure as an ‘atomic multicube’, and ‘mathematically, perhaps the most elegant of them all’.  I don’t like the multicube idea – it implies data has dimensions (which the first version of Azquo did have).  Nowadays we understand only hierarchies.

This is the key recognition that makes Azquo unique.  It also meant that Azquo did not fit comfortably within the data handling methods, or the machine capabilities in the early eighties.  For an Azquo database to work, the machine has to assume that there is potential interconnectivity between any two ‘names’, so appear to act as if the whole database is immediately present all the time.

At the time this presented some interesting programming challenges, as did the question of recognising that, if the database really could accept any type of data at any time, how to police it?

More next week…