Coghead's demise highlights PaaS lock-out risk

Coghead's demise highlights PaaS lock-out risk

Summary: Coghead's new owner SAP will impose a lock-out from April 30, leaving all its current customers in the impossible position of having around eight weeks to completely rewrite all their applications on an entirely new platform.


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.

Topics: IT Employment, CXO, Cloud, Software

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Well yes and no

    @phil - I see this as a symptom of immaturity coupled to the fashionista blindness the Valley culture engenders. Who thought that anyone would be stranded? After all, software companies never die - they just get acquired. And that usually meant customers, who would get looked after. Seems that sacred cow has been blown up.

    More important, if you're going to pose as a 'platform' you'd sure as hell better make sure you've got an exit in place for customers who might be stranded. The first example of this was Teqlo. At the time almost no customers so no harm done. This time it is different. And I'm sure it will be repeated.
  • RE: Coghead

    I've just realized - where you say: "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." That's not true. SAP didn't acquire the customers, ergo it can't lock them out. SAP acquired some IP plus a fistful of engineers, that's a different matter altogether. That's what makes this acquisition different and an example of how risk changes in a sale situation where the acquiror isn't interested in the customers but in cherry picking assets.
  • Lessons

    Nothing like experience to drive home the point about lock-in (lock out) and proprietary solutions ...

    True, it's not as if it's a unique case but the chances of this being repeated - more tech companies running into financial trouble, does seem quite high - which will further slow down enterprise adoption esp of PaaS.

    And what about SAP? Smiling silently. Sure behaved like a cold assassin on this one.

    Alain Yap
    Morph Labs

  • SAP's role

    Dennis is right, the lock-out is Coghead's responsibility. But (as Alain hints) did SAP understand the effect on confidence in SaaS and PaaS when it declined to buy Coghead's customer base? Now there's another proof point that SaaS detractors (SAP among them) can point to when arguing against the on-demand model.

    Personally, I don't see a conspiracy here. The industry has to get its act together and allow for interoperabilty between cloud platforms so that no customer will be stranded. Lock-in sounds great as a business model at first sight, but not if the threat of lock-out prevents customers ever adopting your platform to start with.
    phil wainewright
  • RE: Coghead

    It might be good to start thinking about intermediate solutions where at least, the code of your applications are not hosted on proprietary technology.

    The aggregation and integration could be done via the browser and the PaaS functionality would be limited to certain features such as the pricing, ...
    Yves Hiernaux
  • Get a reality check

    This isn't about "proprietary technology". This is about any platform simply disappearing one morning (or in this case, a few weeks from now).

    Hypothetically, if a platfrom is open source, but there is only a single cloud provider using it, it being open source isn't going to be much comfort as you negotiate with an alternate provider to host the app, or start placing orders with Dell to start up your own servers.

    Any hosting scenario where the provider can simply vanish is BAD. There is no way to sugar coat it.

  • RE: Coghead's demise highlights PaaS lock-out risk

    "What this highlights is the lack of any standard for transferring not just data but application logic between such platforms."

    Standards for capturing application logic already exist: Java & .NET (and COBOL). Coghead "mistake" was to try to develop their own development platform from scratch, instead of leveraging what already existed and provide value on top of that.


    • Doesn't solve the problem

      But you still can't *transfer* logic from one development platform to another, say from COBOL to Java, or from Java to .NET, without completely rewriting it. What I'm advocating would be helpful to people developing on established platforms too. My point is that it's essential in a PaaS context.
      phil wainewright
      • These challenges can be addressed *today*

        I understand your point, but I still don't agree. While theoretically interesting, I think it is inpractical. I think these challenges can be addressed *today*, and do not require an uber-model or new standards, just a different strategy.

        I expanded my thoughts here:
  • The start of a situational application platform migration path

    Most of these platforms store the application
    definition in XML and use a runtime engine to
    interpret the XML in order to render the application.
    So theoretically, if there was a way to convert from
    one vendors XML to another you could get to no-lock-in
    nirvana (or better still, have an open standard for
    this). Needless to say, this is not going to happen
    any time soon, but at least one vendor is making an
    attempt to move in this direction. See story here
  • RE: Coghead's demise highlights PaaS lock-out risk

    Wolf frameworks have exposed a button in their designer toolbar to click and download application design XML which is now saved in my desktop. You get 4 files dowloaded, called menu - business rules - reports & tree XML. Very readable XMLs, anyone else on wolf? This could be a game changer, end of vendor lockin for Software Designs & IP
  • RE: Coghead's demise highlights PaaS lock-out risk

    With the recent closing of Coghead, many companies are thinking twice about signing up with SaaS offerings. As an employee of an online database company, I understand how important the decision is for companies. Our CEO and CTO recently recorded a podcast with tips companies should consider when evaluating a SaaS provider. Two of the tips follow:
    1. Look at the price that the service charges and see if it is a sustainable price.
    2. When you call the company, do you actually get to speak with a person?

    Check out the other tips in the following podcast:

    EDunigan - TrackVia