Five Things Every Developer Should Know about Software Architecture

The software development industry has made huge leaps in recent years, yet software development teams are often more chaotic than they are self-organizing, with the resulting code being more of a mess than was perhaps anticipated. Successful software projects aren’t just about good code, and sometimes you need to step away from the IDE for a few moments to see the bigger picture.

We asked Simon Brown, creator of C4 Software Architecture model and author of Software Architecture for Developers, what five core things every developer should know about software architecture.

Here is what he had to share:

1. Software architecture isn’t about big design upfront

Upfront design is not necessarily about creating a perfect blueprint, a perfect end goal, a perfect end-state or complete architecture. In your upfront design you should be doing “just enough” and creating a good starting point — choose the overall shape, the starting materials, the extension points you think you’ll want to use in the future.

When sketching out your architecture ideas, you want to be able to answer to basic questions like:

Because some design decisions are more important than others, for example major technology choices (the things that become engrained in our codebases) and the way we use these technologies in terms of structure and modularity, like:

• Choice of language: once chosen, this can be hard to change
• Overall structure: if you choose to make a monolith, converting to microservices take a lot of time
  
  

What’s a concrete experiment?
There are lots of names for the same thing: proof of concept, prototype, spike, tracer, vertical slice, walking skeleton, executable reference architecture… essentially writing some code to prove our hypothesis.

How do you know which concrete experiments to run?
You should identify and mitigate your highest priority risks.

And how do you identify risks in the first place (because risks are subjective)?
Using the risk-storming technique — a visual and collaborative technique for identifying risk.

How much upfront design should you do?
Enough to create a good starting point and set an initial direction. Any changes you make should be done in a structured and justified manner.

2. Every software team needs to consider software architecture

When teams don’t think about all the things outlined in your architecture, you get chaos. And it is applicable to every team — every software development team needs technical leadership, and every software system or every product also needs technical leadership.

Sometimes the teams start making changes in very inconsistent ways. You need think about technical issues from an architecture perspective.

3. The software architecture role is about coding, coaching & collaboration

Your technical leadership should be continuous, and it could be made up of one person or a whole bunch of people. Different types of teams need different leadership styles. If you have a team of junior developers, guiding them through their tasks and what they have to do would make them work faster. On the other hand, having a team of senior developers, ‘rockstars’ — don’t try to manage them, just remove the blockers and get out of their way.

Different types of teams with different levels of maturity need different leadership styles. Even with the immature/inexperienced team you still need to give them some time and space, so they can start to understand and solve their own problems, and therefore become more mature.

Should we have one person doing the architecture role or should we have many people?
A good starting point is to think about pair architecting, but this requires some specific soft skills.

If you can’t lead people well and can’t collaborate and influence a team well, you are going to have a hard team leading in an architecture role.

Should software architects know how to write code?
Most definitely yes — it’s good for them to have a hand on the pulse of the system — good software architects are usually good software developers. They have good technical backgrounds, some deep specialism and a broader range of design and architecture knowledge. The people designing software need to understand technology in order to assess trade-offs.

The software architecture role is multi-faceted, it requires good tech skills and good soft skills.

4. You don’t need to use UML

Teams need a visual ubiquitous language to describe your software architecture and communicate effectively. In other words, your diagrams need to make sense. It doesn’t matter so much the tool you use.

Having a common set of abstractions is more important than a common notation.

Something to look at using is the C4 model: a set of hierarchical diagrams that you use to describe different levels of abstractions in your software systems which stands for:

• Context
• Containers
• Components
• Code

The best way to think about it is that diagrams are like maps that help software developers navigate a large and/or complex codebase. For example when you look at Google Maps from a high level and zoom in to see more detail, the same thing should be done in your architecture models, enabling you to have different conversations with different audiences.

5. A good software architecture enables agility

Agile is about moving fast, embracing change, releasing often, delivering value quickly and getting feedback. But for others, agile is about a mindset of continuous improvement. From this perspective, agile is a quality attribute.

Do you need that level of agility on your entire code base, or maybe only in some certain parts of your code base? Once you know that, you can figure out how to support the appropriate level of agility.

“A good architecture rarely happens through architecture-indifferent design”
– George Fairbanks

Check out Simon Brown’s Five Things Every Developer Should Know about Software Architecture talk from GOTOpia November 2020.