X
Business

No Software! But more programming languages ...

Proprietary tools create much of the lock-in, brittleness and stultification of on-premises applications. Surely the on-demand crew were determined to leave all that behind, not embrace it?
Written by Phil Wainewright, Contributor

In a private email the other week on Salesforce.com's APEX announcement, I made the comment, "It's a bit rich for a company whose slogan is 'no software' to introduce a new programming language!" Now NetSuite, another SaaS purist, has gone and done almost exactly the same thing. What on earth is going on?

People with long experience of the enterprise software market have a distinct sense of déjà vu. Every vendor since the long-forgotten days of McCormack & Dodge, Cullinet and MSA has offered their own proprietary programming tools. These make a major contribution to all the lock-in, brittleness and stultification of a classic on-premises implementation. Surely the on-demand crew were determined to leave all that behind, not embrace it for themselves?

Fortunately, there is a difference in the way Salesforce.com and Netsuite have architected their programming tools that should avoid repeating the pitfalls of earlier platforms. The custom programming layer of the stack is insulated from the layers above and below in a way that preserves the advantages of the on-demand model:

  • Custom programming is insulated from the multitenanted functionality below in a way that allows customers to continue to upgrade from one version to another without breaking their customizations. This sidesteps the maintenance and upgrade headaches associated with customizing conventional applications.
  • Self-service user configuration of tabs, fields, dashboards, reports, workflow and so on is built into the user interface and application infrastructure. It thus remains available to users even after the application has been custom-coded. So users don't end up having to wait in line for developer resources just to make simple tweaks to the the application to make it better fit the way they work.

The win here is that the on-demand vendors have answered lack of customization as an objection but without giving up their competitive advantages in terms of low cost of acquisition and maintenance, along with empowerment of business users to gain control of how their business processes get automated.

Interestingly, there's nothing from a technology point of view to stop conventional on-premises vendors from architecting their software in exactly the same way. But it's more complex and costly to do so unless you have a compelling reason. The on-demand vendors have no choice but to build their customization capabilities on top of a multi-tenant, user-configurable application architecture. On-premises vendors are doing their best to move towards a services-based architecture that will have many of the same characteristics, but they are having to do so in the face of extensive customer inertia, and with no compelling reason to get there faster.

But whatever model you choose, it's still vendor lock-in. For all the talk of monthly contracts and ease of unplugging, the on-demand vendors are just as keenas their on-premises rivals to tie customers into their own platforms. What happens every so often in computing is that the constant tension between vendor interests and customer interests swings too far towards the vendors, and the status quo snaps apart to allow it to reset at a different boundary. Packaged enterprise application software has now reached one of those inflection points and the boundaries are going to get reset somewhere in the region defined by SaaS, SOA and Enterprise 2.0. The interesting question is, where exactly will the boundaries get redrawn? We don't know yet but I have some speculation I'd like to share with you in another posting.

Editorial standards