Evolving Architecture
Part 4 of the Agile Architecture Series
When do we know that it is time to update or move on from an architecture or system that has served us well for many years?
Here are the signs to watch out for -
- Your best engineering capacity is used for maintenance and break-fix rather than new product features.
- The Software you are using is not supported or is many versions behind the current release.
- Non-functional requirements are no longer good enough. Information is not available when needed, and overnight batch updates are no longer good enough.
- Something like AI Large Language Models comes by, smacks you in the back of the head, and creates an arms race between you and your competitors.
Predicting the Future can be Too Hard
In the previous article in this series, Agile Enterprise Architecture, I suggested that Enterprise Architecture could be used to predict the future.
Even if we find it too hard to predict the future and implement the perfect architecture, Architecture should be ready to change and adapt, even if we don’t know how it needs to change (yet).
You must be prepared to —
- Keep the Architecture Clean.
- Keep the Architecture Current
Cleaning Our Architecture
One of the ways that we get ready for change is to keep our Architecture contemporary and “clean”, many of you may have read Clean Code by Robert C.Martin. In “Uncle” Bob’s book, there are a couple of themes that we can learn from and apply to architecture as a whole.
- First, write dirty code and then clean it. The architecture we produce will initially have Technical Debt; we can’t always afford (or even know) the perfect solution when we are building it. Be prepared to come back and clean it up.
- Successive Refinement. Just like a program module that started well but did not scale, an Architecture can become irrelevant or not meet our customers’ needs.
Change is Normal — Refactoring is Good
If you were to look at your architecture now, what are the key problems consuming your precious engineering capacity, and how can architecture refactoring help. Here are some examples:
- Tight coupling between two of your systems means there needs to be more resilience when one system is unavailable. Can we re-architect the interfaces so there are fewer dependencies?
- A system is strongly dependent on an outdated, expensive vendor solution. Can we implement an adaptor pattern that allows us to easily unplug and plug in a new provider?
- Supporting an old system is complex and challenging. Can we uplift the monitoring and logging of the system to make it easier to detect and prevent issues?
- The business is no longer happy to wait overnight for reports and key metrics from the core systems. Let’s introduce event streaming and replace some of the legacy batch processing.
- There are many other examples; what’s your problem, and what can you do to solve it?
Of course, this work must also compete with other essential features that the business has planned. So put on your best suit (or T-Shirt) and sell. Everyone loves a great story! Especially one that has a happy ending.
Keep the Architecture Current
The best way to keep Architecture current is to keep it updated. I want to propose a simple architectural principle that encapsulates this concept: the N-1 Rule.
The N-1 Rule
The N-1 Rule (Principle) goes something like this -
Principle: All software used should not fall behind more than one version from the Vendor’s major release cycle.
Why is this important? It is quite easy to let vendor software, database versions, and frameworks get outdated. Continuous system updates are crucial for maintaining a robust and secure technology landscape. The rationale for doing this includes:
- Keep up to date with Security Enhancements and Software vulnerabilities.
- Bug Fixing and improvement to system stability and performance.
- Compatibility and Interoperability with other connected systems
- Feature Enhancements in new releases can be leveraged.
Using this principle is one of the easiest to follow. All (major) software vendors provide a timetable for their software release cycles — they don’t just announce it the week before. There is plenty of time to plan the cost of upgrades that can be included in your company’s budget cycles.
When your software is contemporary, you will have more choices and you can take advantage of investments that your vendors and SaaS providers are making.
Consequences of doing nothing
We’ve all seen the system that just keeps running. Perhaps the software is old, the source code is lost, frameworks and database versions are no longer supported.
Step 1. The software just keeps running … until it doesn’t, there is a security breach, or the key person who maintains it leaves or some other calamity. Customer and business trust is broken!
Step 2. In a panic management order a review of the system and find out that it has outdated software and needs updates and rewrites.
Usually, a one-off figure of a squillion dollars is needed to keep the system going. Starting an Evergreen program now could be a much better proposal (perhaps using the N-1 Rule as a guide).
Summary
Change is normal; don’t expect your architecture to live forever.
- Watch out for signs that your architecture is outdated. Usually, that means that your engineering capacity is being consumed mostly by keeping the lights on.
- Look for Opportunities to refactor your architecture. And align these initiatives with the challenges that the business is having with this software system.
- Keep your Software and Vendor versions up to date. This is not only good hygiene, but it also allows you to quickly take advantage of new capabilities like AI LLM that vendors are starting to offer in their latest software releases.
Thanks, and I hope you enjoyed this series on Agile Architecture. Other blogs in the series include:
Architecturally Significant Decisions | by Stephen Crockett | Technology @ Prospa | Medium
Emerging vs Intentional Architecture | by Stephen Crockett | Technology @ Prospa | Medium
