Dieser Artikel ist auch auf Deutsch verfügbar

In the previous article, we familiarized ourselves with the key aspects of software architecture: system, components, interfaces, and (crosscutting) concepts.

The definition of software architecture already presents us with two tasks: first, designing structures (components and interfaces), and second, defining these crosscutting concepts or principles.

Key aspect: Reasonable requirements

But wait. Before we get started with “designing” our architecture, we need to have reasonable requirements: What should the system do, which tasks or processes should it support (a.k.a. functional requirements)? This goes hand-in-hand with the difficult topic of quality requirements (see here [1]), such as performance, throughput, security, modifiability, and so on. Finally, you must also understand constraints that limit the options of architects when making decisions.

We aren’t concerned here with all of the requirements, as then we would be taking an upfront, waterfall-ish approach. We are interested only the aspects that are currently known and relevant (i.e. for this sprint, iteration or development phase). You should be primarily focused on architecturally significant requirements. These include requirements imposed by particularly important stakeholders (i.e. upper management, the customer, etc.), that are especially risky or costly, that involve difficult or critical qualities, or that are exceptionally innovative in nature (first of a kind).

If these requirements are too vague, unclear, or contradictory, or if they are lacking altogether, you will need to take the initiative and work with the stakeholders to clarify them or at least identify the parties who are responsible for the requirements. That’s why various stakeholders are symbolically connected with the task of “Clarify requirements” in Figure 1.

Figure 1: Architecture activities
Figure 1: Architecture activities

This figure also indicates a number of other activities that I will be explaining shortly.

Two kinds of architecture decisions

Already in the previous article of this series, you learned about the key terms of “structures” and “concepts”. These two describe the two kinds of architecture decisions.

Whether these decisions are made by you personally, in collaboration with others, or collectively by the entire development team is quite another question, one we will take up in detail in part 4 of this series. For this reason, I speak here very generically of “architecture,” rather than specifically addressing you or another person.

These two activities yield the core architectural decisions. An area of overlap can be seen in the figure above, and I have magnified this in Figure 2 below:

Figure 2: Overlap between structures and concepts
Figure 2: Overlap between structures and concepts

Some decisions involve both structures as well as crosscutting concepts, for example:

Communicating (and documenting)

Now you have clarified the requirements and made design decisions in the form of components, interfaces, and concepts. But how do these decisions and their explanations reach the development team or other participants?

Clearly, you need to communicate these decisions (typically orally) or document them (typically in writing) in order for other people to work with these architecture decisions or provide feedback. This is indicated by the bidirectional arrows between the activities.

As an architect, you should be open to constructive criticism and actively request feedback on your proposals and decisions.

Allow me to interject a small plug for my own (open source) project: The arc42 template offers a time-tested framework for communication and documentation of software architectures, including numerous practical examples. It is entirely technology- and process-agnostic. All that merely by the by, as the Kangaroo likes to say. For those of you who like taking shortcuts, there is also an arc42 canvas, which helps you describe your architectures in an extremely compact form as a one-pager. It also makes for a great elevator pitch!

Of hidden treasures and misunderstandings

When working in a team, there is always the risk of people misunderstanding each other. This is a fundamental human problemfeature, and you essentially won’t be able to change it. When you explain something to the team, whether orally or in writing, people might interpret your words to means something other than what you actually intended.

We have all experienced such misunderstandings before. In your architecture work, you must actively work to address these misunderstandings: Sheperd the implementation! For example, check whether the implemented code corresponds to what you intended in the architecture. Code reviews, pull/merge requests, or static code analysis are just a few of the tools you could employ here. Also consider design reviews, pair, mob or ensemble programming, coding style guides, reference implementations, checklists, and many more.

Plus, sheperding the implementation yields another important effect: Quite often the other team members will hit upon more appropriate, simpler, faster (and therefore better) ideas than the original architecture decisions. I like to refer to such structural and technical improvements, simplifications, more streamlined approaches, and the like as “hidden treasures,” and they should be incorporated into the architecture as well – not least because you as the architect simply can’t know everything.

The big picture

IT is an industry in constant flux, and even the business requirements of our projects are sometimes subject to tremendous change. For this reason, you should occasionally (perhaps have six or twelve months) ask yourself the fundamental question of whether the architecture (a.k.a. solution approach) and the current requirements are still a good match. An unbiased review or at least a qualitative architecture analysis can provide a useful impetus for adaptions or future changes.

Curiosity required

As an architect, you should remain on the ball when it comes to new industry developments. You should at least maintain an overview of new technologies, tools, and methods. It might be worth trying out a new framework or two once in a while. Know the most recent version of important tools, and attend industry conferences occasionally to garner inspiration. I know that takes time, and the high rate of innovation in IT makes it impossible to understand all the relevant aspects in detail. But curiosity and openness to new approaches are essential to building appropriate solutions in the future. Without this willingness to continuously keep learning, the value of architecture knowledge and skills will inevitably decline over time. I’m sure you are already familiar with the short half-lives of many IT topics.

Order of tasks

We have already discussed the “it depends” rule. Architecture is not an exact science. In contrast to mathematics or physics, we cannot calculate our results exactly or precisely evaluate our decisions. For this reason, I can’t offer you any generally applicable order or weighting of the tasks. You will have to decide for yourself according to the “it depends” rule.

Skills and capabilities

Up to this point, we have discussed specific tasks and activities involved in software architecture. To complete these tasks appropriately, you need a number of skills and capabilities. I would like to mention a few of these here:

You are designing and building software in a team and should therefore have good people skills and an understanding of individual working styles. Along with the technical and methodological know-how required for the tasks described above, the ideal profile of a software architect includes soft skills as well.

This means a capacity for empathy as well as communication skills such as persuasion and assertiveness.

On top of that, both flexibility and the ability to accept and constructively provide criticism would be desirable. Finding all of that in a single person might sound like a tall order, but allow me to ask: Which of the listed skills and capabilities would you be willing to do without on critical, expensive, or risky projects?

With all of that taken care of, nothing now stands in the way of your core activities – specifically, ensuring the optimal conditions for your team to build good software.

Who should play this role?

Considering the range of tasks and skills described, it is worth asking who should do all this. A single person who is responsible for nothing other than architecture? A small group with members responsible for the different aspects? Or should we distribute these tasks throughout the entire development team?

This question will be answered in the fourth installment - in German of this series. Stay tuned.

Acknowledgements

Thanks to Martina “m”, Martin Weck and Benjamin Wolf for their thorough reviews!

Sources

  1. A pragmatic and practical approach to quality requirements can be found at quality.arc42.org, entirely free and open source in typical arc42 fashion. This approach attempts to improve on some of the deficits of the widespread ISO–25010 model.  ↩

TAGS