Finding a Babel Fish for Data

I guess the Babel Fish won’t mean much to the new generation of readers of this blog. In the 1981 series The Hitchhiker’s Guide to the Galaxy, the Babel Fish was a creature that, when placed in ones ear, allows anyone to understand anything said, no matter the language being spoken – (see video at the end for some light relief).

Martin Kleppmann recently quoted CloudAve in his post conceptualising a standard data format for accounting applications that he’s called OAccounts. Not prepared to simply conceptualise, he’s begun an initiative to create an open standard.

I love the fact that, despite being a technologist, Martin gave a real world user-case for the need for standardisation. As he explained;

Starting OAccounts for me was primarily motivated by my move from one accounting software package to another. I had been using Sage in my small business for somewhere around 18 months, but I wanted to move away from it, and I wanted to take my data with me. I preferably wanted something web-based with all the Software-as-a-Service advantages.

To my great surprise, I had difficulty finding an online accounting provider who could import my Sage data. From Xero, for example, all I got was “wait until the end of your next accounting period, then enter the latest figures from Sage as opening balance”. No, that is not acceptable; I entered all that data carefully into Sage for a reason, namely that I could go back and investigate individual transactions or examine a detailed billing history in future. I wanted all my data to be portable.

What I would have ideally liked to do is to run several accounting systems in parallel for a while, and then choose which I liked best after using them each for real tasks, such as completing a tax period.

The aims of OAccounts are:

• To define a free and open standard for storing and transmitting accounting data, particularly suitable for small and medium-sized businesses.
• To enable interoperability and data synchronisation between different accounting software systems.
• To support multiple currencies, taxation in different jurisdictions, and other features which are important for an internationally growing business, independent of the country in which it is based.

A number of SaaS vendors commented on Martin’s post – all of them positive about the validity of Martin’s concept. They all expressed a desire to adopt standards should they be agreed upon. There was widespread frustration that no standard exists and that, despite wishing to provide a complete data migration service for customers, there just isn’t a standard within which to do it completely.

Of course there is always the elephant in the room, and in this case we have three. In their respective markets Sage, Intuit and MYOB have proved talented at avoiding any move that would make data portable from their services. Instead relying on lock-in and critical mass to stay alive. The reality is that we’ll never get agreement that includes the incumbent players. For the same reason that Microsoft has been difficult historically over document formats, so too will these legacy players continue to block industry moves around standardisation.

As I see it however there are two issues here. Firstly the ability of users to move their data between (primarily SaaS) applications – this can either be between accounting applications, or more broadly between accounting and other business applications. The second is the ability for users to extract data from one of the legacy applications. And we’re already seeing some vendor specific initiatives around this – despite often bemoaning the relative difficulty of data migration, a number of vendors offering their own migration (or more correctly importation) services among them e-conomic and KashFlow.

In a follow up post to Martin’s, AccMan somewhat simplistically states that an initiative such as OAccounts is likely to be a very long time coming, part of his rationale for this is the complexity of the work, while part is the relatively low number of users wishing to change accounting applications. However this viewpoint misses the very real fact that data interchange, not only between functionally similar applications, but also between discrete applications, is becoming more and more important. As Martin himself points out;

Many web-based accounting systems have APIs, either RESTful or SOAP, but they are all different, and some are woefully incomplete. If a third-party developer wants to integrate with several different accounting systems, to have the broadest possible customer base, they will have to implement each API separately.

This relationship is depicted in the following diagram from Martin’s post – rather than concentrating on integration between accounting applications, Martin sees OAccounts helping cross integration between accounting applications and the rest of the business software ecosystem. What applications are integrated with is limitless – we’ve already seen a nice piece of work between FreshBooks and Shoeboxed with the promise of yet more to come.

So despite the barriers in the way of OAccounts getting up and running, I see it as a fantastic idea and one that will really help to give SaaS in general, and business applications in particular, more traction. I’m aware of a few ecosystem plays currently in gestation – and will talk more about some of them soon.