Ben Kepes of CloudAve and I have talked previously about making Small Business data common, as a means of allowing it to move where it needs to. This post is somewhat of a response to his post earlier today and another earlier one about OAccounts.

There seems to be a misconception that data needs to be standardized to protect the small business customer.  If everything is standardized then the customer can move wherever they want with their data. The problem is that’s not how it works in reality. 

Lets talk some real-world data portability needs: 

1) Operations Data – Moving operations data is all about freeing a business’s data to flow (intra-company) to the apps they use. This enables the product or service to be delivered most efficiently. 

2) Data Migration – If I want to move from QuickBooks to PeachTree, or MailChimp to Vertical Response I want to take my data with me.

3) Transactional Data – This data is shared inter-, rather than intra- company like Payments, Purchase Orders and Invoices.

The advent of the XML/Restful API means the operations data is being freed up at a very rapid rate. Intuit’s IPP and the Small Business Web are focused on this area. (Disclosure: billFLO is both an Intuit Developer and a member of the Small Business Web). What’s great about this is that the data is not standardized, it’s just fully accessible and open. Take what you need and use it however you want.

The data migration issue is moving a little slower. Some of that boils down to motivation on the part of the incumbents (Do I want to spend time building a back door so my customer can leave?). However, when the data is simple like a feed list or a calendar, standards do work (opml and iCal as examples). But, if we’re talking about complex data, like the data stored in an accounting system – standards don’t work. They are too time-consuming for the vendor to implement and the benefit isn’t there (Updated: A point Dennis Howlett appears to agree with in this old post). The good news is, the API that’s being used to get the operations data exposes all the data you need to migrate to a new app.  

Transactional data is a mixed bag. Payments are obviously automated on proprietary networks. On the other hand, procurement transactions (invoices, purchase orders, etc) have long resisted automation despite many attempts (EDI, ebXML, UBL).  Again, the data is complex and integrating to EDI is a pain. The payback simply isn’t there for the SMB vendors even though the pain is there for the customers. Again the right solution is make the data open, via an API, and let 3^rd party vendors like ourselves do the leg-work of integrations.

It boils down to this. If the data is simple, a standard works. If it’s in any way complex (or is complex to get), open access to the data is the way to go. Either way, the customer gets data-portability.

Your thoughts?

billFLO Ian