How do you update software architecture to keep up with new technologies?

Understanding the system's existing architecture and codebase is crucial. So, that we don't become too eager to start implementing a new architectural solution right away that is not compatible with the current one. Adopting a new architecture is a step-by-step gradual process where we have to plan and set incremental achievements.

An architecture is only good if it can be maintained without constant modification. Having said that, a well-designed software architecture should be organized and structured in a modular fashion to accommodate even the smallest alterations. Adopting a new architecture requires planning and setting small goals that must be accomplished gradually.

The major goal of updating the software architecture should be to see how it will benefit the end customer. Instead of just adopting to new technology, the aim should be to implement new features and improve the performance of the software. For eg in banking…End to end payment tracking,decreasing the payment processing time will benefit operations ,support and account holders.

In my view, the architecture change needs to be supported with some context to understand: WHY: Why do we need the change? - To enable a new business capability or - To increase value proposition of the business or - To reduce or remove business risks, etc Which usually be provided as architecture objectives/goals with metrics, scope, guiding principles, reference architecture. Then, I will assess the current state to find out the risks and opportunities based on the context and scope. This step will tell me WHAT needs to be changed - the target state: - Which component (that is carrying the risks that) needs to be enhanced, or replaced, or removed?

Before choosing the technology, the software architect should diagnose that the problem is in the old technology, and not the poor architecture

When we select any new technology one major factor is to make sure it can be easily migrated from private to public cloud. Also from one cloud provider to another.

I would wish to suggest to change the Step 2 title to "Choose the right approach". Then, it make more sense for the same process, as the change may or may not involve a new technology.

While it may seem like testing and validation is a later step, IT Professionals will tell you that it is required during, or even before the rewriting step. It is best not to restructure or change code too dramatically without it being "safe" to do so. Automated Unit Tests with good coverage, and using both IDEs with built in refactoring tools and refactoring processes to guarentee no breaking changes are a must. If no tests are available, don't make changes, but safely refactor and create tests first, to offer shift left test, quicker feedback, and a robust, pleasent, and most importantly safe inner loop for developers. Research TDD (Test-Driven Development) for more information.

Retiring Software more frequently! We need to learn to retire software Ona frequent basis .. we cannot have the timelines of the past… the point where it is more expensive to refactor and restructure is much sooner these days than earlier - Talent is a huge point and issues prolonging adoption of newer tech is an issue .. but understand a constant state of change while maintaining production quality is an art.. that is what the architecture needs to strive for.

Documenting the "why" is essential. I normally find I am documenting several things: 1.) First, a narrative on why the architecture needs to change. This short document focuses on the limitations of the current architecture, business needs, and any high-level constraints. 2.) The big picture view containing the context diagram with explanations of domain responsibilities, decisions, rationale, and top level solution patterns. 3.) Design-level views for key areas expressed by use cases, sequence diagrams, API contracts, data models, etc. Use whatever view is necessary for the audience at hand. 4.) Execution plan - how to get from the current architecture to the revised one. Invest time in documentation!

In today's landscape, many architectures prioritize lightweight design, facilitating easy validation, verification, and updates. While the core remains solid for its intended purpose, occasional upgrades become essential to address security vulnerabilities and maintain a robust system. Integrating tools like SonarQube and alternatives to monitor metrics after each code change is invaluable for continuous improvement and heightened security.

I don’t agree that the architecture needs to be constantly updated. Architecture is something that needs to hold for a long time, like real life structure architecture (pyramid). If you constantly changing the architecture, it’s very poor one. What can constantly change is a design of a module in the architecture, like stated by continues design method (after enough patches)

I do not agree either. Architecture changes are expensive and very risky for an organization on multiple levels. Adaptation of architectures are more appropriate. The microservices trend has emerged as a way to generally layer new functionality on existing architectures with minimal friction. Businesses would go out of business if they are throwing lots of money at constantly updating architecture rather than adapting it.

It's the job of software architecture to provide an application platform that isolates changes, and allow individual applications, and application components to be updated with minimal impact. Architecture is an approach, not a technology.

I agree fully. Roads(architecture) dont change because cars (modules) change. Maybe the fueling (interface), speeds (rules), navigation(routing) will change but the roads and buildings(locations) not. However we may add some special roads (air, tunnels) for special transport(modules).

Exactly, they can change some modules to have fewer, for example, change Apache Impala for Spark Delta Lake in an ETL environment where we extract, add and make available a distributed and atomic DBMS to be consumed by a dashboard. It is removing one element and upgrading another that we already had like Spark, ergo one less cluster, and time that we gain because Impala is no longer there.

If the software architecture is built right from the start, the changes will only be correctional. Most successful products keep the same architecture for years before they scale and need a different approach to handle the workload.

There are many good perspectives on this topic which are clearly from deep experiences. One of the points they all highlight is architecture and design are different. Poor design choices does not imply a bad architecture. A robust architecture should be able to withstand tech changes and not need constant refactoring. If it does that's a sign it was never the most appropriate one to begin with.

One thing that's important to keep in mind is to avoid refactoring or update the architecture of a system without unit/integration testing in place. You'll end up guessing whether anything is working correctly whereas with a test suite in place you can have much more peace of mind that what you've done hasn't ruined functionality that's already in place.