February 23rd, 2009
Coghead's demise highlights PaaS lock-out risk
The problem with PaaS, as Coghead’s customers are now discovering to their dismay, isn’t so much lock-in as lock-out. They knew they were locked-in to Coghead’s platform, but that’s nothing unusual in the world of software development. In exchange for the convenience built into a specific platform, developers willingly give up the freedom to move elsewhere. With conventional software, they know they run the risk of ending up on a dead-end platform that’s no longer supported because the vendor lost interest or went out of business (or in the case of open source, the platform simply falls out of favcr). But although that’s a disappointment, it’s not a disaster.
What’s different with PaaS is that you don’t always have the option of staying on. Coghead’s new owner SAP will impose a lock-out from April 30, leaving all its current customers suddenly in the impossible position of having around eight weeks to completely rewrite all their applications on an entirely new platform. It’s small comfort to know that your data’s accessible if all the automation you’ve built up to process it is about to disappear. I would be crushed right now if I had built any kind of functionality using Coghead (and I’ll be honest, I had been considering it). The long list of rival PaaS providers offering a new home for my application would be small consolation.
What this highlights is the lack of any standard for transferring not just data but application logic between such platforms. As Coghead’s erstwhile CEO Paul McNamara ruefully admitted to InformationWeek last week, “Customers can take the XML out that describes their application, but the reality is that only runs on Coghead, so customers will need to rewrite their app with something different.”
There’s never been a compelling need for this type of capability on conventional software platforms because there’s less urgency to move functionality elsewhere. With PaaS, the lack of such mechanisms could become a huge barrier to adoption as customers become fearful of which platform might be next to switch off the lights. Speaking at the recent Powered by Cloud conference in London, Brian Reale, president of Colosa, the author of ProcessMaker, talked about this lack of standards for extracting and transferring business process logic. “If your SaaS provider fails, what are you going to do, especially if you don’t have a process exchange language?” he asked, adding that other risks that might force customers to move included excessive price ramping, performance degradation and changes in legal frameworks.
In the absence of such standards, there are at least some things businesses can do to help reduce their exposure to platform lock-out. The first step is to pay as much attention to the processes locked into your applications as you already pay to the data. A while back, I started using the term ‘business IP’ for this kind of process-based intellectual capital — “the sum of all the best practice experience, partner relationships and workplace culture that define the very essence of an enterprise.” This was my advice back then for keeping control of all this valuable process capital:
- “Build applications in a way that keeps business policy and profile information separate from software processes
- “Keep that policy and profile data in a format that allows you to easily transfer it to an alternative application platform
- “Always take maximum care to protect policy and profile data from unauthorized access and use.”
We still don’t have the standards to do this simply (although a lot of progress has been made since the turn of the century) but at least a well-documented application created according to these guidelines is far easier to recreate on a new platform than one that’s been built in a more haphazard way.
Phil Wainewright is a commentator and strategist on emerging software industry trends. See his full profile and disclosure of his industry affiliations.
Subscribe to Software as Services via Email alerts or RSS.
| 02/23/09
