Beware the software marketer’s latest snake oil: futureproof software.
Our software is so resilient, so adaptable, so clairvoyant that it doesn’t matter what kind of change you throw at it, nothing will make it break.
Sounds too good be true? Perhaps. But the futureproof moniker isn’t entirely devoid of meaning. Indeed, even a modicum of ‘futureproofness’ would be an advantage over old, brittle applications that fall over when you breathe on them.
Let’s pick apart this term and see what steak we might find under all the sizzle.
The Multiple Facets of Futureproof Software
When vendors describe their software as futureproof, they are generally referring so some combination of the following characteristics.
-
- Self-healing. The goal of software that can address any issues in the production environment without human intervention has been with us for years, but in practice, software has only been able to heal itself in limited circumstances. Furthermore, healing capabilities generally come from the operations management gear, not the software in question.
- Self-patching, or more broadly, self-updating. Our smartphones are able to recognize when they need a patch, and then upon the user’s approval, handle the update automatically. Why can’t enterprise software do the same thing? Note that self-patching is a special case. Self-updating would also include updates to any part of the infrastructure, including operating system, runtime environment, etc.
- Backward compatibility. You can open old spreadsheets with new versions of Excel because Excel is backward compatible. If your enterprise app has this capability, it would be able to work forever – except we’re really talking about the execution environment for the app, not the app itself. Your app would be futureproof if its execution environment were always backward compatible.
- Dynamic adaptation/ability to evolve over time. This capability is really a type of self-updating. Will your mobile app work on an as-yet uninvented device? Can it take into account new data or metadata that its developers hadn’t planned on?
- Intent-based. This term has busted out of the networking world, where intent-based networking means that the system is (a) able to translate the business intent into implementable policies and configurations, and (b) is able to validate over time that the system continues to conform to that business intent. It is part (b) that gives intent-based software a futureproofed aspect.
- Made up of reusable futureproof components. Take software components (like microservices) that conform to some combination of 1 – 5 above and assemble them into an application that inherits its futureproofness from them.
Some of the six characteristics above are straightforward, while others are downright nebulous. It’s fair to say that no software on the market today conforms to all six.
For the enterprise software buyer, the watchword here is caveat emptor. ‘Futureproof’ may not be entirely smoke and mirrors, but vendors use the term in different ways – and none of them is as futureproof as we would like.
The Common Thread: A Bulletproof Abstraction
Regardless of which of the above six characteristics a supposedly futureproof piece of software exhibits, there is always one thing they all have in common: an abstraction layer that separates the underlying plumbing that has to deal with change from the business-focused application elements that are supposed to be futureproof.
What this abstraction consists of, however, continues to shift. Here is a brief chronology.
The futureproof story begins in the 1950s with compilers. Instead of hand-coding platform-specific machine code, compilers allowed developers to write in English-like sentences, and the compilers would convert these programs to the underlying machine code.
As a result, as the underlying technology changed, the compilers changed with it, enabling the programs to continue to run, often unchanged. Did you ever wonder why there’s still so much decades-old COBOL still running? It’s about as futureproof as you can get.
The next innovations in futureproofing were Java Virtual Machines (JVM) and the Common Language Runtime (CLR). Java came along in the mid-1990s with its ‘write once, run anywhere’ mantra, adding a layer of abstraction onto the one that compilers brought to the table.
Soon, Microsoft stepped up to the plate with its CLR at the heart of .NET, serving much the same purpose. As a result, Java and CLR-based languages like C# were both portable and futureproofed against updates to hardware and operating systems (at least in theory).
Everything changed once again with the rise of the cloud, in particular, platform-as-a-service (PaaS) and serverless computing, aka functions-as-a-service.
Cloud-based virtual machines (aka infrastructure-as-a-service) provide an abstraction that hides the hardware, networking, and management infrastructure, offering some measure of futureproofing to apps that run in them.
The real futureproofing story of the cloud, however, is PaaS. PaaS (and now serverless) abstract the applications’ operating systems and execution environments as well, thus cementing the futureproof appellation for cloud-based software than runs in such contexts.
Our chronology reaches the 2020s with the increasing adoption of two parallel trends. The first of these exercises in futureproofing is Kubernetes, and cloud-native computing in general.
Kubernetes follows an extensible, configuration-based architecture that (ideally) allows for updates to the infrastructure without adversely impacting the software running on it. As Kubernetes matures, these essential architectural characteristics promise to bring a new level of futureproofing to software.
The second modern trend to bring futureproofing to the enterprise (indeed, to organizations of any size): Low-code/no-code platforms (no-code in particular).
A quick Google search will reveal that most vendors touting the ability to create futureproof software are low-code/no-code vendors, and it’s no wonder. Core to these platforms is a configuration-based abstraction that insulates applications from the underlying infrastructure that supports them.
As a result, vendors can make updates and apply patches with impunity – a characteristic they believe futureproofs the applications on their platforms.
The futureproofing power of low-code/no-code, in fact, goes beyond its ability to support the creation of applications without the need for hand-coding. The real story is how easy it is to make updates and changes without writing a line of code, often by line-of-business users or ‘citizen developers.’
In the final analysis, futureproof software doesn’t actually have to update itself in response to new requirements on a fully automated basis. It is sufficient if people can make such updates within an environment that automates everything else.
The Intellyx Take: The Big Picture of Technical Debt
Given that the term ‘futureproof’ has so many shades of meaning, what do we really want when we say we want futureproof software?
Perhaps we want software that automatically does what we want it to all the time, regardless of any changes to the technology or business environment. Unfortunately, this ‘Star Trek computer’ view of futureproofing is well out of reach for the time being.
What we’re more likely to desire is software that is permanently technical debt-free.
Technical debt represents the shortcuts or other expedient choices we make to produce software that inevitably lead to problems over time – problems that someone will eventually have to fix, perhaps at great cost.
The software may have met the business need at the time it launched, but no longer – and thus it clearly doesn’t qualify as futureproof.
If we had a way to create software with no such technical debt – and in addition, software that wouldn’t accrue such technical debt in the future – then we’d have software that would be as good as it could be at any point in time.
True, a new business requirement would require changing the software, a limitation that only the Star Trek computer would be able to overcome automatically. But without technical debt, applications would be able to support such updates in as straightforward and simple a manner as possible.
It’s no wonder, therefore, that low-code/no-code platforms and Kubernetes are maturing in parallel. Each technology supports part of this technical debt-free vision: low-code/no-code for the applications themselves, and Kubernetes for the infrastructure that supports them.
Much work remains, however. There is as yet no seamless connection between these two technology trends – and until there is, the goal of technical debt-free software will largely be unattainable. It seems that even futureproofness itself isn’t futureproof.
© Intellyx LLC. Intellyx publishes the weekly Cortex and Brain Candy newsletters and advises business leaders and technology vendors on their digital transformation strategies. Intellyx retains editorial control over the content of this document. At the time of writing, Microsoft is a former Intellyx customer. No other parties mentioned in this story are Intellyx customers. Image credit: Steve Johnson.
Comments
Comments are closed.