I’ve been following the rise of “Web 2.0” apps for the enterprise, like Yammer, Podio, etc. and I find all of it really compelling. It seems like these platforms are very powerful tools for facilitating internal communication. I can’t help wonder, however, about the long run and particularly about data portability… you fill these workspaces with all sorts of important enterprise data–comments, files, tasks, projects, contacts, etc.–and then what if you want to migrate to a different platform?

Of course this is an intentional problem to maximize customer stickiness, and assuming the system continues to work for your firm, you don’t really care too much. But in the long run, there will be a problem. Maybe they go bankrupt. Maybe they get bought by another company, which discontinues the service (see DabbleDB, who gave just 60 days’ notice of closure). Maybe they stop investing in developing the platform. For better or for worse, few complex services exist in the same form they did 10 years ago. So what are you going to do 10 years from now?

All of this has always been a concern for hosted enterprise services, but this newer generation of apps is even more problematic because of the data schema complexity. Migrating email platforms is enough of a pain in the neck, but at least there are standards, so porting the data is straightforward, if time-consuming. But these new services are quite heterogeneous in terms of the kinds of data stored; an open standard might cover, for example, contact records, but what about how contacts relate to all the other data in the schema?

Assuming the service provides you with good export tools, which is by no means guaranteed, most alternative services don’t provide import tools, at least not ones that can absorb entire complex schemas. And surely some data would get lost in translation due to functional differences between platforms. There’s no simple/cheap solution to all of this.

This is a valid concern with any cloud or SaaS provider, including, admittedly, Sevanta Dealflow. The main difference is that we’re really a boutique consultancy, not a large-scale software shop, so we offer a lot more stability and a lot more assistance in the event that you need it. Sure, it costs a little bit more than some freemium system, but after all, you do get what you pay for. Our assumption is that there is a middle ground: freemium is too cheap for business, but it is possible to get good service well short of a multi-million dollar IBM contract.

Sevanta addresses this concern in a couple of technical ways also: each of our clients runs on their own copy of the server (ie- it’s not “multi-tenant”). This somewhat limits our ability to easily scale to serve thousands of clients, but it insulates our clients from instability: your system only changes when you want it to change–not due to architecture changes compelled by our internal development agenda; not due to changes required by some other client. If you want to receive updates, you can; if you don’t, then your code base will never change. You’re in control.

We’ve also intentionally kept our data schema very simple. Thus, we don’t embrace shiny new features as frequently as some other providers might, but the dataset you can export is relatively simple in case you want to recycle it elsewhere. I’d like to think we offer the best of both worlds.

What do you think?

Leave a Reply