Software architecture may not be what you think it is

Author | Pierre Pureur, Kurt Bittner

Translated by | Hirakawa

Planning | Ding Xiaoyun

Software architecture is controversial in the agile community. In the experience of many, architecture can only lead to worthless meetings and insignificant documents, and the phrase "maps are not territories" can aptly sum up this view. However, poorly architected applications can quickly become like abandoned vehicles on the side of the road, broken and irreparable. So, is there a useful middle ground between meaningless poles?

Part of the reason for this problem is that architectural design is an inappropriate metaphor for the outcome of software systems architecture work. Compared to the work of architectural designers, the term conjures up images of designs that herald a utopian future. However, the architecture of software systems is far more varied than architectural architecture. Buildings are static, and the architect's job is done only once. Software, by its very nature, is constantly changing and dynamic; when it stops changing, it begins to die.

In order to better understand software architecture, it is necessary to trace the origin of the word architect. It comes from the ancient Greek word arkitekton, i.e. ρχι-(arkhi-, "chief") + τ κτων (téktōn, "builder"). Architecture is created by the people who build things. In the work of architects, this meaning has disappeared. Many of them have never poured foundations, framed buildings, or installed water or heating pipes. Design and construction have been separated. But this is not the case in the software world, where the way you build affects what you build and vice versa.

1

Software architecture is about decisions, not structure

The analogy of buildings has led some software architects to focus too much on structure and behavior rather than on the decisions that produce those structures and behaviors. This is not to say that structure and behavior are not important, but that they are the result of the thought process. If the system is to continue to evolve over time, this thought process must be preserved. Knowing why someone does something is just as important as knowing what they do. If the code is well organized and commented, what they do should be easy to see from the code, but why they should do it is often overlooked.

The reason for this is that software's architectural decisions are rarely self-explanatory; almost every architectural decision is a compromise between competing alternatives. And, there are some alternatives that it's hard to see their merits if you don't try them and see how they work. Knowing what you've tried and what you've given up is often more valuable than knowing what works. There is an old saying that good judgment comes from experience, and most experience comes from bad judgment.

This is one of the reasons why software architects must still be developers; they cannot understand or predict the influencing factors in the system without developing and testing something. Software architects should not pay as some kind of honorarium to people who have withdrawn from active development, but have knowledge that the organization considers still valuable; it should be more than that. Architecture work requires sufficient knowledge of the system to be able to make assumptions that benefit quality attributes, as well as expertise in writing code and designing tests to evaluate hypotheses (or working closely with team members who can evaluate those hypotheses).

2

Architecture is a skill, and architect is not a role

In fact, in terms of the nature of the work, using a title like software architect conveys the wrong message. The reality is that a lot of software developers are doing architectural work, they just don't realize it. As long as they make decisions about how to meet quality attributes, it affects the architecture of the system. Fully understanding how the decisions behind them affect the system's ability to achieve quality goals is the first step in improving the system architecture.

So, what skills do people need to master to improve the quality of their architecture work? There are the following aspects:

Pay more attention to quality attributes, which is a key cross-cutting requirement that a good architecture should address. Functional requirements are easily noticed by teams because they are often tangible, even some of the things that the system does for its users to be visible to the naked eye. However, the quality properties of a system determine whether it can survive for a long time, such as scalability, performance, security, carrying capacity and maintainability, and so on.

Ability to conceptualize and solve problems for the entire system. Quality attributes are often determined by factors that affect the entire system, rather than just a certain part. While modular design and separation of concerns are essential to building a good system, they also make it harder for team members to have a holistic view of the system.

Understand the full life cycle of a system. This requires experience not only in developing systems, but also in testing systems, deploying systems, running systems in production environments, maintaining systems for a long time, and substantially modernizing systems when they require major innovations. Understanding the life cycle of a system and how it responds to change is critical to making informed decisions to limit technical debt, which over time threatens the survival of the system.

The ability to balance concerns and reconcile compromises. Architecture work rarely has the right answer. Architectures often involve making trade-offs between conflicting quality attribute requirements (QAR) and constraints.

The ability to learn and synthesize new methods from experience. This ability refers to making a direct attempt (running an experiment) and summarizing the results of the experiment as principles that can further guide the experiment. Some of these principles take the form of "standards". The term is a bit misleading because standards need to be constantly tested experimentally to determine when they are no longer useful. We see that many developers are frustrated with the "standards" of the organization because they made sense at some point in the past, but now they are trapping the team in the past.

Demonstrate leadership skills. Being able to raise concerns and engage people with different perspectives to discuss and reach consensus helps teams face and overcome complex architectural problems. Anyone on the team can do this, and anyone responsible for architectural design must do it.

3

Architecture means continuous exploration

Modern software application architecture design is a fundamental exploration activity. Today, teams building applications face new challenges every day: unprecedented technical challenges, and new ways to solve new problems and a variety of other problems for customers. This ongoing exploration meant that the architecture could not be predetermined based on past experience; the team had to find new ways to meet quality requirements.

Regarding the importance of exploration for architectural discovery, consider an example such as assuming you are part of a team that works on software systems development. Originally designed, the system was designed to handle structured tabular data stored in SQL Database. Now, the system needs to be enhanced so that it can handle unstructured data, including images and videos, and the amount of data is expected to be much larger than the system currently handles. You're considering introducing NoSQL databases into your technology stack to handle new data types, but since your team doesn't have much experience with the technology, experimentation is essential to choosing the right database product, configuring it, and meeting new data volume requirements.

As the team solved these technical problems, they developed their own assumptions about which methods would best meet the desired QAR, which changed over time. They build a subset of solutions to test these hypotheses and make decisions based on the results. These decisions about how to satisfy QAR add up to the architecture of the system. Teams may communicate these decisions in different ways, including using documents and diagrams. However, documents and diagrams are not architectures, what matters is the decision and why it was made.

The following information is important regarding these decisions:

If necessary, explain the cost of overturning a decision. If you have to change a service, a DBMS, or even a framework, know how expensive it will be to replace it. In some cases, this may mean rewriting the application.

Clearly state any limitations or assumptions. Understanding usage constraints and assumptions may help teams that want to update your work in the future. For example, knowing that you've made assumptions that the number of concurrent users doesn't exceed X and causes you to make certain decisions about concurrent threads or processes can help your future colleagues understand what changes they might need to make if they exceed this constraint.

How do you meet specific Quality Attribute Requirements (QAR). For each QAR, you should describe what you did to make sure it was met, not just in theory, but also what tests you ran to prove it. Links to specific test cases and their associated automated tests. This makes it easy to re-evaluate the architectural quality of the system when QAR changes.

What options do you consider before making a decision. Knowing what you've considered and what you've given up is often more useful than knowing your final decision; it shows your thought process, from which others can see what kind of limitations you may be subject to in making your decisions. If these limitations disappear in the future, knowing why you made certain decisions will help future developers make better decisions.

Figure 1: QAR, decision-making, and technical debt

What technical debts were generated knowingly. Some decisions will inevitably lead to technical debt; for example, a decision to use a SQL database to meet reliability goals can have some side effects on technical debt (see Figure 1). Now, the "millennium bug problem," which has long been a thing of the past, stems from the conscious decisions of developers at the time. To reduce data storage, memory usage, and processing time, they did not store century data when storing standard dates. The reason for this problem is that they didn't expect the app to be around for so long, long after those restrictions were out of date. If they could communicate their decisions more accurately and describe the potential impact, people might not have had such a strong reaction at the end of the last century.

4

brief summary

As a discipline, software architecture needs to be radically changed. Perceptions of it are subject to a lot of old ideas about what it needs to solve and how it should solve them. Considering software architecture as a continuous activity, working to make assumptions about how the system meets the quality attributes, and then empirically demonstrating that the system can meet these attributes, is the fundamental point of the software architecture continuity approach. What also needs to be changed is to separate the software architecture from the committees that are disconnected from development and put into the hands of people (developers) who can actually implement and turn it into an executable program. Only then will we be able to get the resiliency and sustainability we need from today's applications.

About the Author:

Pierre Pureur is an experienced software architect with a broad background in innovation and application development, extensive exposure to the financial services industry, extensive consulting experience and comprehensive technical fundamentals. He has previously served as lead enterprise architect for a large financial services company, leading large architecture teams, managing large-scale concurrent application development projects, guiding innovation initiatives, and developing strategies and business plans. He co-authored "Continuous Architecture in Practice" (2021) and "Continuous Architecture" (2015). He has also published numerous articles on this topic and has spoken at several software architecture conferences.

Kurt Bittner has over 30 years of experience delivering working software in short, feedback-driven cycles. He has helped a variety of organizations adopt agile software delivery practices, including large banking, insurance, manufacturing, and retail organizations, as well as large government agencies. He has worked for or worked with large software delivery organizations such as Oracle, HP, IBM, and Microsoft, and has served as a technology industry analyst at Forrester Research. His primary job is to help companies build strong, self-organizing, and efficient teams that deliver solutions that customers love. He has written four books on software development topics, including The Nexus Framework for Scaling Scrum. He works in Boulder, Colorado as Vice President of Enterprise Solutions for Scrum.org.

https://www.infoq.com/articles/what-software-architecture/