There is No Upgrade

SaaSBluePillRedPillAdoption of Software as a Service (SaaS) solutions, present a challenging and often overlooked decision point for the modernization of enterprise applications, a last chance conundrum after which there is no turning back. The point of contention: software updates and upgrades. As discussed previously in They’ve Gone to Upgrade, the common SaaS philosophy of incremental and continuous updates, so popular in the consumer landscape, is presumptively thrust upon an unsuspecting enterprise. The traditional model of infrequent, monolithic updates is fittingly viewed as the work of dinosaurs, to be supplanted by the clear superiority of evolved just-in-time software delivery. The question of software upgradeability is too often a choice between absolutes. Choose the blue pill and the story ends, you wake up next to your old on-premise server instance and believe whatever you want to believe. Or you take the red pill, you stay in SaaS wonderland, and fall right into a rabbit hole of continuous updates. It’s probably time to stop all this enthusiastic pill-popping.

Never send a human to do a machine’s job. Microsoft, often lambasted for holding on to a decades-old software update model, just might have cooked up something a little different that shows respect for the divide between consumer and enterprise. Ars Technica speaks to Microsoft’s new software update strategy for Windows nin—er ten in Windows 10’s Very Different Way of Updating:

“With Windows 10, the update approach is set to change substantially. Microsoft is acknowledging the need, and even desirability, of making regular incremental improvements to its operating system. It’s also, however, acknowledging the different appetite for change between consumers and enterprise users.”

Despite the continued consumerization of IT, certain fundamental differences between consumer and enterprise cannot simply be hand waved away. Pro-tip: it’s all about the tolerance for failure. Consumers have been carefully trained to accept failure on a regular basis, but with a defined benefit. The upside is frequent and abundant new functionality, a model of continuous improvement. Say for example a few weeks back when cloud-based to-do list Wunderlist underwent a major update temporarily disconnecting the entire database of existing list entries rendering the app useless for several days. Annoying yes, but I’ve been trained not to expect perfection in exchange for continuously evolving refinement, and also because there’s little recourse to recover the sum total of zero dollars I have paid for it. In the consumer space, incremental updates are very much expected – but the consequences for them are overlooked. Gross inconveniences can be remedied by a coupon for half off your next latte or some such. That’s because there’s often little to no money at stake. Mostly it’s at the cost of a consumer’s time, which in of itself is highly ephemeral. Even with paid consumer apps, frequent perturbations are tolerated, merely because most applications and services aren’t related to a critical workflow and, more importantly, are generally isolated in their functionality. In other words, the utility of new features override the value proposition of bulletproof stability. And be sure that the road to new features is paved with apologies.

Enterprise, however, is an entirely different animal. The effect on critical systems is obvious – when it comes to financial transactions or power generation for example, the slightest disturbance to a real time system is catastrophic.   But the majority of current enterprise SaaS offerings are nothing of the sort. So then why all the consternation about continuous updates? Systems outside a truly critical context are more important than you might think. Say a CRM, ERP, PLM, or CAD system glitches because of an update, nothing falls out of the sky right then and there, but the associated cost of errors or lost work/time quickly compounds by the minute, if not by the second. As enterprises scale in size, the amount of customization or integration with other software tools expands – and each interface adds new potential failure modes. So the prevailing wisdom is to carefully vet and catalog any changes to software components, perform consistent and robust testing, deploy limited pilots to trial new builds, and simmer over a healthy dose of eternal vigilance. Up until now, most SaaS upstarts tend to dismiss such philosophy as an artifact of legacy systems. To that attitude I can only say: Welcome to the real world. SaaS approaches don’t in of themselves have to require continuous updates. In fact almost anything is possible. It’s time to free your mind.

Back to Microsoft and Windows 10. Their proposed update options serve a hybrid objective, balancing the moderated, conditional deployment essential in the enterprise with the unfettered continuous deployment championed by fast-pace SaaS consumer innovators. From the same Ars Technica article:

“There will also be an intermediate option—something that lets businesses keep up with new features but lets them control when those new features are rolled out, to ensure they won’t disrupt business processes or otherwise happen at inopportune moments. Windows 10 will support mixed deployments, too, with different systems at different speeds. This will give admins a good opportunity to, for example, have a few machines running at the consumer pace and act as canaries for the rest of their organization, which might use the intermediate option for most machines and the “security fixes only” setting for some critical systems.”

SaaS companies determined to stay relevant to the enterprise should take careful note. It’s time to move beyond absolutes and provide that update flexibility that will be required to further enterprise adoption. The answer is out there, Neo.

  • Ross Bernheim

    They say change is inevitable, except from vending machines. What I want is not continuous changes. I want changes other than bug fixes or security updates to come on a scheduled basis I also want to know far in advance what the changes are and what they will do to interfaces, particularly interfaces used to access the program to integrate it with other programs in my business.

    Change for its own sake or to promote new features before known bugs and problems are addressed just angers me and makes me feel that the software company is non-responsive to their users.

    • Great point, Ross. Perhaps features in the future can be more like a continuously refreshing buffet – you grab what you want, leave the rest. All the advantage of continuous updates, but none of the pain.

  • beyondplm

    Ed, to acknowledge the face systems need to be upgraded is the best thing vendors should do. And vendors must be responsible for that. However, to run upgrades is a tricky thing and requires investment in technology.

    Maybe you had a chance to read my earlier article about that

    PLM upgrades, release cycles and legacy software
    http://beyondplm.com/2014/08/19/plm-upgrades-release-cycles-and-legacy-software/

    Here is another article from yesterday to give you an idea of what kind of technologies can help to make life “with upgrades” (!) painless

    Why to ask cloud PLM vendor about Devops and Kubernetes
    http://beyondplm.com/2014/10/23/why-to-ask-cloud-plm-vendor-about-devops-and-kubernetes/

    Best, Oleg

    • Thanks for both links, Oleg – great stuff! Had read the older article just now caught up with the second one.

      Applying DevOps infrastructure concepts to regular software certainly is intriguing.

      One of the bigger challenges is that we’re not talking about just updating a single vendor’s application – even in current on-premise system upgrades with very little external connections and known endpoints tend to go pretty well. But as we move to more interconnected point solutions from a variety of vendors all running on their own schedules, the impact of handling multiple modes of change creates plenty of opportunity for unanticipated failure modes. Managing that going forward will be a challenge. DevOps concepts need to move towards multi-application testing and validation as well, don’t you think?

  • Pingback: Random PLM (future) thoughts | Jos Voskuil's Weblog()

  • Pingback: Cloudy with a Chance of Metering? | E(E)()