For Parleys Course creator Simon Brown, agile and architecture have a symbiotic relationship, and he believes that, “a lightweight approach to software architecture…can complement agile approaches rather than compete against them.” In this interview, we find out how decades in the field have shaped Simon’s approaches, and why we should be leery of “cargo-cult agile.”
Simon: Yes. The course has been around for a number of years, in several different formats, and it’s based on my experience of undertaking the software architecture/tech lead role on project teams when I worked for consulting companies. The great thing about being in consulting, and more recently being independent, is that you get to see many different teams, architectures, and technologies, and the different ways that people work. The diversity of culture across the globe throws in an extra dimension too. Whether it’s trying to find solutions to particular problems or stripping away excess material to boil ideas down to their essence, all of this plus feedback from participants has ultimately shaped what the course is today.
Who is your course aimed at? How experienced do people need to be?
The course is primarily aimed at software developers who are aspiring software architects/tech leads. It’s also aimed at anybody in a software architecture role who wants to improve the way that they communicate software architecture, particularly with regards to diagrams and lightweight documentation. Additionally, I see a large number of organisations struggling with how to blend up front thinking and agile approaches, so I provide some answers in how to do “just enough” up front design. The course is basically about technical leadership, so some software development experience is a must.
Do you think a good grasp of agile methodology is important for this course?
Not really. I’ve always tried to approach software architecture in a relatively lightweight way, partially because I like writing code, but also because too much up front thinking tends to waste time and there’s a danger that your ideas will be unsuitable once you start getting deeper into the problem you’re trying to solve. Writing some code early allows you to reach a deeper level of engagement with the problem, and doing some up front thinking can help set an overall direction. This approach is relevant regardless of whether you’re following an agile approach or not.
Can you give us an example of the kind of sketch you’d use to visualize your architecture?
“Simple sketches for diagramming your software architecture” summarizes my “C4 model” for describing, visualizing and communicating software architecture. It’s a simple hierarchical way to think about the static structures of a software system in terms of containers, components and classes. It says that a software system is made up of one or more containers (web applications, mobile apps, standalone applications, databases, file systems, etc), each of which contains one or more components, which in turn are implemented by one or more classes.
Visualizing this hierarchy is then done by creating a collection of system context, container, component and (optionally) class diagrams. For me, a common set of abstractions is more important than a common notation, so I don’t use UML for most of this. Maps are a great example of this principle in action. They all tend to show roads, rivers, lakes, forests, towns, churches, etc but they often use different notation in terms of colour-coding, line styles, iconography, etc. The key to understanding them is exactly that, a key/legend tucked away in a corner somewhere. We can do the same with our software architecture diagrams or use a notation that is much more self-describing.
What’s wrong with many of the software architecture sketches that you see?
In my experience, many people no longer know or use UML, so I see people struggling with notation. This covers everything from what sort of boxes and lines to draw through to colours, symbols, icons and so on. That aside, it’s really the way that people think about their software systems that’s the biggest problem. People will have often heard terms like “conceptual view”, “logical view”, “development view” and they try to draw these types of diagrams. But such terms are vague and ultimately result in very “fluffy” diagrams that include mixed abstractions and don’t really reflect the software system from the perspective of the code.
Diagrams that don’t reflect the code – why is this a problem?
It’s a problem because software architecture diagrams that don’t reflect the code have very limited value. Imagine a set of blueprints for a house that didn’t actually reflect the building in terms of structural walls, rooms, etc. A diagram consisting of a bunch of conceptual “components” is almost useless if there’s no clear explicit mapping between those components and the code. My C4 model addresses this by providing a way to think about the static structural elements of a software system, from the highest level right down to the code. Once you give people this vocabulary, they can then apply it to their own software systems and draw some diagrams to accurately portray what the software system looks like from a number of different levels of abstraction. The side-effect of doing this is that it forces people to think about structure, modularity and good design principles.
A recent article suggested young developers should avoid the agile manifesto – what’s your take on this?
As an industry we’re not very good at studying our own history, even though it’s relatively short. The problem with anything that attains mass adoption is that the core underlying values often get lost, and this is why you see a lot of people doing, what is sometimes described as, “cargo-cult agile”. For example, this could include religiously having daily stand-up meetings and doing TDD but not really understanding why. Adopting an agile approach isn’t about blindly performing agile practices, it’s about reflecting on and adapting the practices you use in order to solve problems, become more efficient or simply ship better software more frequently. I wouldn’t say that young developers should avoid the agile manifesto, but they should appreciate why it was created and what problems it attempts to solve.