I caught an interesting article by Larry Dignan over at ZDnet that talks about what we’ll likely see as upcoming FUD around SaaS vendors and viability in a down economy, expanding on an earlier post from Vinnie Mirchandani about methods that SaaS providers should use to calm customer’s possible fears of a company collapse.
As I’ve written before, the downturn in the economy is a prime time for companies who are looking to invest in new ERP, CRM and productivity systems to consider SaaS instead of a on-site hosted solution. The pay-as-you-go and pay-as-you-grow model of SaaS means that companies would have an easier time forecasting exactly how much they’ll need to spend on software, although it ultimately shifts the burden of capital expenditures (CapEx) to the SaaS provider. It’s true, though, that companies will likely become skittish about making any large investments in SaaS in a rocky economy.
As Dignan points out:
… the SaaS sector is likely to look like the rest of the software industry–the big companies will benefit in a downturn. Simply put, you’ll buy from a company you know can take a punch. In SaaS, that means Salesforce.com can take more share. Smaller fish may have to show their bank accounts to skittish CIOs.
Meanwhile, Matt Asay over at CNET News suggests that the best way to calm customer’s fears is to open source the original code, rather than offering to put it in escrow at all, the same way that SugarCRM does.
I’m not so sure about the latter approach of offering the source code up as open source, especially because as Matt points out, it diminishes the value of the assets the vendor. It could also inadvertently give leverage to competitors that figure out how to provide hosting services and infrastructure at costs underneath the vendor’s. Not to mention, as Dignan points out in his post: who really asks for code that was in escrow, anyways?
Ultimately I think the right approach is the one that Vinnie Mirchandani suggested: data portability first and foremost. But I think data portability matters for a few other reasons, too:
1.) It prevents companies who invest in SaaS from feeling like they are locked into one particular suite or service provider.
2.) It creates value-add opportunities for other SaaS players to re-mix company data. Imagine, for example, being able to explore my company’s financial data hosted in one provider with a business intelligence tool provided by another, without having to do any complex wiring or custom coding between the two. Or being able to wire specific triggers inside of business applications to external workflow services.
3.) Companies should be able to own sensitive data internally if they decide they want to, and this could make many folks who are sensitive about where data lives today less anxious in general.
4.) One of the big problems today with existing business software is already the silos it tends to create by not offering enough entry points to business data. If anything, SaaS providers’ motto when it comes to data is: the more ways to slice and dice it, the better. Isn’t that what SOA (service oriented architecture) was all about?