Products that reach the market today are rarely purely mechanical. Cars, industrial machinery, medical devices — they all have software inside. That is a good thing at first. Software can be updated, bugs can be fixed, and features can be added later, without the customer having to bring the device back.
But does that promise hold up in practice? Anyone who has held an older device that no longer receives updates knows the answer: not on its own.
Long-term software updates are not a law of nature. They are the result of deliberate decisions — in product architecture, in the business model, and in the processes used to manage requirements and tests across the entire lifecycle.
That is exactly what my talk “Leveraging Long Term Software Update Strategies” at SIEMENS Realize LIVE 2024 in Las Vegas was about (you can find the conference report here). The event’s focus was sustainability — and the argument behind it is actually simple: a product is truly sustainable if it lives a long time. And it lives a long time if it can be supplied with software updates over the long term.
Three building blocks have to fit together for that.
1. The business model must enable updates
That sounds obvious — but it isn’t. Many companies have historically made their money with hardware. Support was an add-on that should cost as little as possible. In that logic, free lifetime software updates are a cost block with no return.
So the question is: who is going to pay for it? If the answer is “nobody”, then nobody will make sure the updates are good — or that they come at all.
It could be a service contract, a subscription model, or a tiered support level. The model itself plays a minor role. What matters is that delivering good software updates has to pay off economically. Otherwise sustainability remains rhetoric.
2. The product architecture must allow it
The second problem is technical: many products have grown in such a way that a software update for a particular product generation would mean a complete redevelopment. If you tied mechanics, electronics and software closely together — because things had to move fast back then — you have a problem when a software component needs to be updated five years later.
Modularisation and standardization are the keywords here. If software components have clearly defined interfaces and as many product generations as possible share the same software base, an update becomes plannable and economically sensible.
That is easier said than done. But it is a decision you can make deliberately — and the earlier you make it, the cheaper it gets.
3. ALM creates the necessary transparency
Suppose the business model is right and the architecture is modular. Then the third challenge comes up: how do I keep track of which requirements went into which software component? Which tests exist for them? Which dependencies between components could block an update?
This is exactly where ALM tools come in. Application Lifecycle Management — with tools like Polarion, Codebeamer or Jira — creates a continuous connection between requirements, development, testing and delivery. Ideally, the system knows:
- Which requirement triggered which feature?
- Which tests verify this feature?
- Which other components depend on it?
This transparency is the prerequisite for a high degree of automation. If the change impact of a planned update is visible at the push of a button, development cycles can be shortened significantly — and the risk of breaking something goes down.
- The business model must treat software updates as a source of revenue — without an economic basis, updates will not be delivered sustainably
- The product architecture needs modularisation and clear interfaces, so that as many product generations as possible can be served with the same updates
- ALM tools, used properly, create transparency across requirements, tests and dependencies — the basis for automation and safe updates
Watch the talk
If you would like to see the whole thing as a talk: the video is available on YouTube.
A note on sustainability and flying to Las Vegas: the question is a fair one. I don’t mean to absolve myself with this — but I offset the CO2 emissions of my flight out of my own pocket through a certified provider.