Software architecture — Paying the Price for Neglecting it
In the business world, we usually build software to solve some business needs. With time the software evolves because it is successful in the marketplace, user demand is strong, the development atmosphere is vibrant and positive, and the return on investment is excellent. It gives us direct indications that software systems are critical business assets and to maintain the value of these assets they must be changed, updated, and managed.
>>>> Follow me on Medium and I’ll make sure you get quality content.
Due to the dynamic nature of the business environment (market), software system tends to or need to evolve to capture new and ever-changing user requirements of the system and its surrounding to keep it demanding and alive.
THERE IS NOTHING THAT FAILS LIKE A SUCCESS SPECIALLY WHEN WE KEEP IT AS IT IS.
As the software evolves, its size and complexity increase. Optimally, the architecture must scale up to support changes in the requirements. If these changes are not managed properly, the architecture of the software deteriorates and is hard to maintain and result in creating architecture debt. Software systems that have a large amount of technical debt may become increasingly difficult to maintain and modify over time. This can lead to the system becoming obsolete or unreliable, as it is unable to keep up with changing business needs or technological advancements. This phenomenon is commonly called ‘software aging’.
The architecture of the software moves away from its original shape if the architecture is changed without taking into account the impact of the change. This will naturally result in a drift of the architecture, as there is no longer an updated architecture to relate changes to. This situation eventually leads to architectural erosion. Architecture erosion is usually defined as a phenomenon in which an application’s initial architecture is modified arbitrarily to the point where it no longer holds its key properties.
It is more like the building base was built to handle a two-story building but as it looks good so we keep building more floors on top of the same base.
Over a series (n) of releases, the architecture of the next release (n+1) is designed based on the previously eroded architecture which raises questions on the validity of the designed architecture of next release and it worst if there is no direction to correct it.
Symptoms of software aging include decreased performance, increased errors or crashes, and a decline in user experience. It may also take longer to introduce new requirements due to increased complexity, leading to a slower release pace and later arrival in the market.
It’s important to point out that it is usually not due to the natural complexity of the business or software but rather it is due to the way it is built and grows which is not compatible with the growing business needs.
Architecture design vs architecture discovery
In most cases, the architecture document (of some kind) is developed at the start of the project and is not maintained properly during the development life cycle. Let’s face the truth that in most situations source code is left as the only available up-to-date documentation. Based on this, it can be inferred that the architecture of the software is not the architecture that is designed in the architecture document or diagrams or whiteboard; it is the architecture that is actually implemented.
It also means that we usually ‘discovered’ the architecture once we build it. Architecture discovery is reverse engineering a system in order to understand how it works or to identify opportunities for optimization or improvement. In addition, It may not always be possible to fully understand the motivations and decision-making processes of the original designers of the system. This can make it difficult to accurately interpret the design and identify opportunities for optimization or improvement.
Promote architecture design so architecture discovery is limited or not needed
As it’s not easy to change after its discovery so we provide a different kind of support to keep it running, in other words, put lipstick on the pig. I have also seen some efforts to document the architecture while discovering it, in terms of diagrams but the irony is that as long as it’s finished it’s already outdated.
Agile impact on architecture
Today most software is built using an agile approach that emphasizes flexibility, collaboration, and rapid iteration which allows teams to quickly deliver working software. This helps to ensure that the software being developed meets the needs of the user and is delivered as quickly as possible.
In some cases agile approach gear up the architecture erosion process.
Agile can sometimes have a negative impact on software architecture if it is not implemented properly. One common problem is that the focus on delivering small increments of functionality on a frequent basis can lead to a lack of consideration for long-term architectural issues. This can result in a software system that is difficult to maintain and scale, and that is prone to technical debt.
Another potential problem is that the emphasis on rapid delivery can lead to a lack of documentation and design, which can make it difficult for developers to understand the overall architecture of the system and how its various components fit together.
In such a situation or environment, the business usually gets much more focus, teams usually live under a high delivery pressure, and are led by a nontechnical team member. In such situations, architecture is usually not an important, appreciated, and easy topic to discuss.
Following a good idea does not guarantee success, the ability to tailor it to specific circumstances and environments often leads to great results.
Economic value
Everything in business boil down to money, economic value, and short-term profit, long-term investment. The cost of making changes to a system with eroded architecture is likely to be higher than a well-designed system.
When it is hard to maintain a software system then usually it is calculated in terms of economic value, the question normally asked is if it is worth enough to rewrite the system or if is it just okay to maintain the existing one even when it takes extra time to maintain and incorporate new requirements.
The point I want to make is that when a business discovered these challenges in software applications then it’s already late as it normally takes too much time&money&efforts to upgrade the software.
The question that business has the right to ask is why we came to that situation and how could we avoid such a situation in the future, lesson learned.
In some cases, I have also seen the second episode of this story where a business agrees to invest in rebuilding a software system from scratch in order to solve the software aging issue with the spirit of long-term goals and investments. So development team takes the lesson learned from previous experience, takes the business requirement of current and future needs, chooses the best available technology of that time, and starts building the system.
The most cases architecture is destroyed due to lack of process and rarely it is due to skills.
At this time, software applications and architecture got a lot of focus so most things go well (almost) with the software and architecture got well established. But as time goes on, business and software evolve, changes are incorporated, and people move between the departments or companies, new people have been introduced to the systems so again after some time software (and its architecture) starts deteriorating from its original shape and idea.
In my experience when people talk about architecture they take a very high level or abstract level of architectural view, which is a good and easy way to understand how the system is built BUT in most cases, as we all know, the devil is hidden in details. It is usually hard to get money from business owners for updating architecture that does not give any output in terms of functionality.
As a business owner, I would have a hard time releasing that kind of money without a clear business case, especially if it only addresses the symptoms rather than the root problem.
The architecture efforts should be part of the functionality releases, not the maintenance. The team should take continuous refactoring efforts as part of the development process. I understand it’s hard as the agile process mainly focuses on delivery and we don’t have any specific discipline to show and focus on architecture efforts that could be easily visible across the organization.
Solution
There are different great theories to address software aging and architecture erosion situation, here I dare to represent my own thoughts through the lens of my knowledge and industrial experience.
One of the best ways to overcome the negative effect of software aging is to place software change and evolution at the center of the software development process. Any subsequent changes to the software system should follow the same path. However, in most cases, neither the software development nor the evolution and maintenance process follows such a path. Due to several business or technical constraints, these changes are mostly introduced directly into the implementation.
In my opinion architecture vision is one of the great techniques to keep the software and its architecture in a healthy state. Even taking one step future, what if we devise a method or process based on the architecture vision that could help the team to make the vision as part of the software creation ingredient and daily routine, imagine how productive our team could be in delivering successful and well-maintained software.
I think it's such a great idea that I would dedicate a whole new article on architecture vision and vision-based development methods. Stay tuned.
