Even if your design was perfect, development team flawlessly executed every task, what functions perfectly today might be obsolete tomorrow.

Owning an IT system can get expensive. From a business perspective, dealing with external forces tearing your IT system down is one of the most annoying tasks. Without getting ANY business value, you are required to invest just to keep your systems up and running.

Your applications rust

Like the iron rusts, so does your systems. You need to constantly patch security vulnerabilities found every day. Upgrade programming language versions to keep your applications supported. Once a year your database reminds you to update just to keep receiving support - or to pay extra for extended support. The technology you use degrades by itself, and you have to keep moving to prevent it from breaking apart. There is no sign of relief - the world keeps getting crazier every day. Our applications and technology platforms keep getting more complex, requiring more attention.

Types of rust

In general, we are talking about technical debt. I’m intentionally leaving out the debt that is your own fault (quick and dirty solutions that needs to be fixed etc.), leaving only the ones that I’d classify as rust – external forces you have no power over, corroding your system. The rust comes in few flavors:

• Dependency on third-party tools and libraries: When external libraries, frameworks, or tools that the application relies on become outdated, unsupported, contain bugs or security vulnerabilities, it can lead to significant technical debt as the team has to work around these limitations or plan for migration to newer versions or different tools.
• Platform or technology trend shifts: When the underlying platforms or technology trends shift, previously optimal solutions might become obsolete, inefficient or otherwise technology-non-grata, forcing updates and redesigns.
• Regulatory changes: Legal or regulatory requirements can lead to existing solutions becoming non-compliant, necessitating unexpected revisions or redesigns that hadn't been planned for.
• Changes in Customer Requirements: As user expectations evolve or market demands shift, existing functionalities might need to be drastically altered or new features developed, impacting the existing architecture and leading to potential debt.

Sometimes the changes are minor, like casually updating the outdated library. Sometimes the change requires serious investment in both money and time from actual development. Typical example in the very expensive category would be a change in application trends. What if one day we decided that we don’t want browser applications anymore? Now everything has to be Virtual Reality? An example of the previous was a decade++ ago when the world decided that Java Applets and other browser plugins are evil, and everything had to be changed to something else. That was fun.

So – are we doomed to invest more and more every day to polish the rust from our system? Not the future I would like to see. Everything should be getting simpler, not more difficult every single day?

Rust protection treatment for your apps

So how does LeBLANC prevent systems from rusting? By keeping them sinked in oil in a safe dry place and out of sunlight of course! Ok, kidding. Really – how do we do it?

The key idea is to make the rust our problem, not yours.

• Less moving parts, less places that can attract rust. We are proud of the simplistic architecture we have created for your applications. It’s as simple as possible, but no simpler than that.
• We have chosen battle proven technologies and architecture that have existed, matured and tested in real life production systems. So you can expect less surprise changes over time. Like “oh, these microservices weren’t such a good idea after all”.
• If and when the trends change, we change our approach. As an exercise, we created (just for fun) a version of the Fusion generator that produces native Windows applications. We have also done the same s**t but using other programming languages. Having succeeded in these exercises, I believe we are up to the challenge, whatever the future brings us. When maxxed out, you can even deal with the legacy system dilemma.
• If legal requirements change, we alter our software production line, so that after the change, it will output flawless and compliant implementation across all our customers systems with single change.
• Dependency on third party libraries and tools We do this all the time. We keep track on security vulnerabilities, update the packages, handle language version changes. Like what happened a few weeks ago: Just like that, your application is updated from .NET7 to .NET8.

In most cases all you need to do is to regenerate the application and put the new version to production. We call these modifications in our software production line future proofing your applications. By us changing the product line configuration, you get the latest secure, trendy, fashionable application.

Yours,
Janne Hansen
LeBLANC Finland Oy

Related

• Software production lines V2
• Legacy system owner's dilemma