When we first started getting in to SaaS back in 2004, there were a lot of companies still looking for shortcuts in to the space. Virtualization and terminal services were seen as a way to take your current app and "voila", turn it in to a SaaS offering. Three years later, I cannot think of one company that has been successful in the market using these types of services instead of trying to create true multi-tenant native web applications, yet we see many companies looking to repeat those mistakes with Web Services.
(That said, I have seen some companies successfully navigate a transition strategy. By artfully employing multi-instance versions of their code with Web Front ends, a number of companies bought themselves some time to make the move in to a true SaaS offering.)
Today the big rush is to offering your App as a Web Service. A couple of our customers such as Visual Mining and Fliqz were built from the ground up to be integrated into other apps as their primary vehicle. Many other people want to add that capability.
This is more than just using Web Services to integrate with apps behind the firewall (such as Boomi helps companies do.) It's actually designing your app to be a part of other apps. Amazon is doing it, so is Facebook with F8, now everyone wants on board.
And they are looking for quicks ways to get there. Mention Web Services to a SaaS company and they immediately want to know how they can use that to make their app available for Mash-Ups. So much so, many companies (including OpSource) are rushing to develop and deploy those tools.
Will those tools be valuable assets in offering applications as Web Services, or will they be the second coming of Terminal Server, a non-functional solution designed to hold analysts, customers and press at bay? My guess is that it will depend. If it's just a quick and dirty way to get in to Yahoo Pipes, then we've read that book. But if the tools add value above and beyond the app (such as providing pre-built marketplaces or new functionality) we might see them become an integral part of tomorrow's applications.
Subscribe to:
Post Comments (Atom)
2 comments:
Very good point. A company has to decide if they are primarily just building an app (for direct consumption) or a service (or set of services) to be leveraged by others. The architecture, functional requirements, testing cycle, go-to market strategy will all have to be aligned with the Worldview you pick.
This does not mean that you cannot build an app on top of your service offerings (e.g., Amazon can build a catalog using S3 storage) but the two are distinctly thought out products.
Interesting, yes I think it will be much easier to put an app on your service than make your app in to a service. That argues for going the service route first, but that is a much slower route to revenue.
Have to keep thinking on this one.
Post a Comment