Software Architecture May Not Be What You Think

Software architecture is controversial in the agile community. In the experience of many people, architecture leads to worthless meetings and irrelevant documents, a view aptly encapsulated by the saying “maps are not territories.” However, poorly architected applications can quickly become like a vehicle abandoned on the side of the road, broken and beyond repair. 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 fruit of software system architecture work. Contrasted with the work of architects, the word conjures designs that herald a utopian future. However, the architecture of software systems is far more varied than the architecture of buildings. 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.

To better understand software architecture, it is necessary to trace the origin of the word architect. It comes from the ancient Greek word arkitekton, which is ἀρχι – (arkhi-, “chief”) + τέκτων (téktōn, “builder”). Architecture is created by people who build things. In the work of architectural designers, this meaning has disappeared. Many of them have never poured foundations, framed buildings, or installed water or heat pipes. Design and construction have been separated. This is not the case in software, where how you build affects what you build and vice versa.

Software architecture is about decisions, not structure

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

The reason for this is that architectural decisions for software are rarely self-explanatory; almost every architectural decision is a compromise between competing alternatives. Also, there are alternatives, and it’s hard to see the merits of them without trying them out and seeing how they work. Knowing what has been tried and what has been given up is often more valuable than knowing what has worked. 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 a system without developing and testing something. A software architect should not be paid as some kind of remuneration to someone who has retired from active development but has knowledge that the organization considers still valuable; it should mean more than that. Architecture work requires sufficient knowledge of the system to be able to formulate hypotheses 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).

Architecture is a skill, architect is not a role

In fact, by the nature of the job, using a title like software architect sends the wrong message. The reality is that a lot of software developers are doing architecture work, they just don’t realize it. As long as they make decisions about how to satisfy the quality attributes, it affects the architecture of the system. Fully understanding how the underlying decisions 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 acquire to improve the quality of their architecture work? There are the following aspects:

• Pay more attention to quality attributes, a key cross-cutting requirement that a good architecture should address. Functional requirements are easy for teams to focus on because they tend to be tangible, or even visible things the system does for its users. However, the quality attributes of a system, such as scalability, performance, security, carrying capacity, maintainability, etc., determine whether it can survive in the long term.

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

• Understand the complete life cycle of a system. This requires us to have experience not only developing the system, but also testing it, deploying it, running it in production, maintaining it over the long term, and substantially modernizing it when it needs major innovation. Understanding the life cycle of a system and how it responds to change is critical to making informed decisions and limiting technical debt, which over time threatens the survival of a system.

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

• The ability to learn from experience and synthesize new methods. This ability refers to directly trying (running an experiment) and generalizing the experimental results into principles that can further guide the experiment. Some of these principles take a “standard” form. This term is a bit misleading because standards need to be constantly tested experimentally to determine when they are no longer useful. We’re seeing many developers frustrated with organizational “standards” because they made sense at some point in the past, but now trap teams in the past.

• Demonstrate the ability to lead. Being able to raise concerns, enabling discussion and consensus among people with different viewpoints, helps teams face and overcome complex architectural issues. Anyone on the team can do this, and anyone in charge of architectural design must do it.

Architecture means continuous exploration

Modern software application architecture design is a fundamental exploratory activity. Today, teams building applications are confronted with new challenges every day: unprecedented technical challenges, and new ways to solve new problems and a variety of other problems for customers. This continuous exploration means that architectures cannot be predetermined based on past experience; teams must find new ways to meet quality requirements.

Regarding the importance of exploration for architectural discovery, consider this example: Suppose you are part of a team working on software systems development. Originally designed, the system was designed to process structured tabular data stored in an SQL database. Now, the system needs to be enhanced so that it can handle unstructured data, including images and video, and the volume of data is expected to be much larger than the system currently handles. You’re considering introducing a NoSQL database into your tech stack to handle new data types, but since your team has little experience with the technology, experimentation is a must to choose the right database product, configure it, and meet the new data volume requirements. Essential.

As the team worked through these technical problems, they developed their own assumptions about which methods would best meet the desired QAR, and these assumptions changed over time. They build part of the solution to test these hypotheses and make decisions based on the results. These decisions about how to satisfy the 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 schemas, what matters are the decisions and why they were made.

With regard to these decisions, the following information is important:

• If necessary, state the cost of overturning a decision. If you have to replace a service, a DBMS, or even a framework, know how expensive the replacement is. In some cases, this might mean rewriting the application.

• Clearly state any limitations or assumptions. Understanding usage constraints and assumptions may help teams who will update your work in the future. For example, knowing that you made the assumption that the number of concurrent users does not exceed X, and that led you to make certain decisions about concurrent threads or processes, helps your future colleagues understand that if this constraint is exceeded, they may need to make what changed.

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

• What options did 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, and others can see what constraints you may have had when making a decision. If these limitations go away in the future, knowing why you made certain decisions will help future developers make better decisions.

Figure 1: The relationship between QAR, decision making, and technical debt

• What technical debt is being incurred knowingly. Some decisions will inevitably result in technical debt; for example, the decision to use an SQL database to meet reliability goals will have some side effects of technical debt (see Figure 1). Now, the “Year-Year Bug Problem”, long gone, stems from a conscious decision made by 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 more accurately communicate their decisions and describe the potential impact, perhaps people would not have reacted so strongly at the end of the last century.

summary

As a discipline, software architecture requires a radical change. People’s perception of it is governed by a lot of old ideas about what problems it needs to solve and how it should solve them. Viewing software architecture as an ongoing activity, dedicated to making assumptions about how a system satisfies quality attributes, and then demonstrating empirically that the system satisfies those attributes is fundamental to a software architecture continuance approach. What also needs to change is to separate software architecture from committees that are disconnected from development and into the hands of the people (developers) who can actually implement it and make it executable. Only then can we get the resilience 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. In the past, he served as Chief Enterprise Architect for a large financial services company, leading large architecture teams, managing large-scale concurrent application development projects, directing innovation initiatives, and developing strategy and business plans. He co-authored “ Continuous Architecture in Practic ” (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 with large software delivery organizations such as Oracle, Hewlett-Packard, IBM, and Microsoft, and has served as a technology industry analyst for Forrester Research. His primary focus is helping businesses build strong, self-organizing, high-performing teams that deliver solutions that customers love. He has written four books on software development topics, including The Nexus Framework for Scaling Scrum . He is based in Boulder, Colorado, as Scrum.org’s Vice President of Enterprise Solutions.

Original link:

Software Architecture: It Might Not Be What You Think It Is

The text and pictures in this article are from InfoQ