How to Decide on Software Architecture Modifications

How to Decide on Software Architecture Modifications

Throughout the software development lifecycle, the foundational decisions that define a product’s architectural design impact every aspect of the application, so the process of modifying that architecture requires extensive analysis and consideration.

This topic crops up on a regular basis at every company. Most of the time, you’ll have an existing architecture that needs to be rewritten or refactored. Using these situations, you can quickly learn to pinpoint what to analyze, how to analyze it, and how to appropriately act on the findings.

When choosing to refactor or rewrite an application’s software architecture, or to understand when it’s completely unviable, use the following considerations.

Refactoring vs. Rewriting

For the sake of clarity, here’s how we differentiate between rewriting and refactoring.

Refactoring, according to Martin Fowler, is about changing the design of something without impacting its behavior. It’s generally a reorganization process that results in higher quality code.

A rewrite is like a nuclear football: hitting that switch requires heavy, careful consideration because it’s usually the most expensive option and slows down timeto-market

or the delivery of new features.

Factors Driving Architectural Decisions

Architecture is influenced by three major drivers that should always play a key role in an organization’s decision to refactor or rewrite it: business drivers, quality attributes and risks.

Business drivers are usually related to the direction of the company and its overall mission or vision. An example of a business driver is a need to create 10 new integrations a month, or perhaps 5,000 integrations by the end of the year. Another is an expected incremental increase in users or a boost in sales orders.

Quality attributes are aspects of the software that require protection, such as maintainability, accessibility, resilience, agility, security, and performance, to name a few. Organizations should define which quality attributes are most important to the business because adjusting one is usually detrimental to another. For instance, enhancing a product’s security can result in performance drop-offs, and improving an application’s resilience might result in longer deployment cycles.

The final drivers, risks, include things like slow time-tomarket, market competition, or financial risks related to the software’s user base. Again, organizations should decide which risks pose the biggest threat to the software’s success and trade them off against the lesser threats to better analyze their software architecture for its capability to mitigate these risks.

Consideration of all of these drivers is an essential part of the decision-making process, both when defining architecture from the start of a project and analyzing the need to refactor or rewrite an existing application. If any drivers are still relevant or have created a positive impact on the business, then any planned modifications must take those facts into account.

Soft Changes and Rigid Changes

After analyzing the relevance of drivers for architecture modifications, it’s important to look for any gaps in the source code and ensure that important quality attributes are protected. On a deeper level, perhaps there is a lot of technical debt to deal with, or coding standards are not as high as they could be. We call these examples “soft” changes, which means they are easy to adjust and there is no need for foundational modifications to the source code.

If, on the other hand, there are many instances where the architectural source code fails to align with the business drivers or quality attributes, then the necessary changes are “rigid,” which translates to difficult, timeconsuming and risky.

If organizations can categorize the findings in their analysis in terms of this scale of rigidness, it becomes easier to decide what to do with the application.

As a rule of thumb, if the architecture is very rigid and any changes would have no noticeable impact on the business, it’s best to do nothing. However, if changes to the architecture are soft or easy to implement, but the business impact of any changes is still low, companies should consider tweaking it on a sprint-by-sprint basis to improve it in small chunks and measure the impact after each sprint. Things change when the business impact is higher. In these cases, if the architectural changes are soft, then it’s highly recommended to refactor the application, but when rigid changes are necessary then it’s often worth considering a full rewrite from scratch.

To summarize, when evaluating the health of an application’s architecture, engineers need to consider many things to decide on modifications, from issues with the tech stack and unprotected quality attributes to elements that play no role in achieving business goals. By evaluating the viability and severity of these changes, it becomes much easier to assess the difficulty of any modifications from a technical perspective and analyze the potential impact they will have on the business.

Sebastian Velez is head of technology and also oversees PSL’s training and development program and R&D innovation lab. He has been in the industry for more than a decade, with experience as a developer, software architect, scrum master and college professor.