Software Lifecycle Management: Even Zeros and Ones Get Old

Custom Project Begins

You probably all know how the story starts: There's a project ahead, and you need software that can't simply be bought off the shelf — it has to be custom-built. A beautiful new website, for example, for which you can’t just use a ready-made template.
Concepts and designs are created, prototyping gives a first impression, and maybe a data set is even built up during this phase... and then the software is written, over the course of weeks or months. Depending on complexity, multiple technologies are involved: database, web server, application server; the business logic may be implemented with Java or PHP, the frontend with HTML (or the whole thing using a JavaScript technology)... and it quickly becomes clear that we're not talking about “one piece of software,” but rather a whole catalog of components, each subject to different influences and lifespans. And it's a bit like us humans: the parts age at different rates. But more on that in a moment.

Different Approaches: Change or Expansion

Once the software is in operation, there are different approaches: Perhaps the feature set is so complete and the purpose so narrowly defined that no expansion is needed for a long time. Or perhaps — especially in agile projects — there are multiple deliverables scheduled after the initial go-live that extend the MVP (Minimum Viable Product). At Kittelberger, we work with website systems that are continuously enhanced week after week, with both small and large new features and increments, rolled out globally — in such cases, "the website" isn't really a project that ends, but more like a product that's continuously developed. That’s arguably the best-case scenario, because new features often require newer components as well.

So: once software is live, there are countless scenarios for how often it will be changed or extended. And in either case, it's easy to forget what was already hinted at above: not all parts of software age equally well.

• Source systems: The database from which your products are drawn (or your job postings, or other external data sources) may not even be accessible from outside — which already removes one security risk. In the best-case scenario, the export for the website is based on a standard format that you can still generate consistently and validate after updating the database.
• Infrastructure: The currency and configuration of your web server or application server are critical for security. Not infrequently, the version of the application server also dictates which version of your software can run on it (e.g., a 10-year-old Java app simply won’t run on a current Tomcat server). Other examples include updates to TLS versions and other seemingly minor changes that can suddenly lead to expensive and risky dependencies.
• Frontend/Backend: Most libraries and components used here need more frequent updates. Some version jumps are major and require significant changes to maintain compatibility.

Additional Factors and Risks

There are also additional factors to consider: As a service provider or software vendor, do you want to switch to a new technology? Is the existing software still functional and used in critical environments, but poorly documented — and would replacing it be expensive? And is there perhaps hardly anyone left who actually knows how to work with it? While this may sound exotic, it's exactly what German industry has been dealing with for decades when it comes to the 1960s programming language COBOL.

And whether it's a website system or an internal backend application: the risks are fundamentally the same across the board — operations, security, and flexibility.
And all of these risks have one thing in common: If ignored for too long, they can become very expensive.

"But it still works!"

In addition to a certain level of technical complexity, there’s one key reason why the topic of “end of life” is so often unpopular. It can best be summed up in one short sentence: “But it still works!”

So why spend money on something that’s still functioning? Maintaining and updating software is often time-consuming — and from the outside, that effort is usually invisible (which, ironically, is often the goal!).

Let’s be clear: We at Kittelberger are Swabians and completely understand anyone who prefers to save money and effort when they feel it's not needed. And it’s true that maintaining and updating software without changing any functionality is often seen as a cost with no obvious benefit — at least not one that’s immediately visible to users. But who would deny that a stable and secure application is valuable?