I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Simon Brown (@simonbrown) spoke on “Agility and the essence of software architecture”. (Slides, Video)
He started with a great Dave Thomas quote:
“Big design up front is dumb.
No design up from is even dumber.”
Software Architecture Agility
He went on to tell us…
Delivering software in an agile way doesn’t guarantee that you’ll develop an agile architecture.
A good architecture enables agility.
He asked “Are monolithic architectures agile?” and proposed the answer, “Well, they could be. Just because you have to deploy it all at once doesn’t mean it’s not agile.”
Which naturally lead into a discussion of what does agility mean? Simon presented John Boyd’s OODA loop as a candidate answer: Observe, Orient, Decide, Act. Applied to software: agility is relative and time-based. (GL: I think what he was trying to say was that agility is the ability to move through this OODA cycle quickly.)
Software Architecture Diagrams
He then moved on to talking about architecture diagrams, which I gather is what his book (Software Architecture for Developers) is about and is also the domain of part of his personal development work.
Lots of people try to show their architecture using custom diagrams. He believes it can be very advantageous to have multiple diagrams, showing different views of the system, and that having a common set of abstractions is more important than a common notation.
He described 4 levels of detail that he thinks are most useful to diagram:
- System Context = what the system interacts with outside it
- Containers = the runtime containers that will host the software components
- Components = the logical high-level parts of the software that communicate with each other
- Classes (optional) = the code design inside a component
(GL: Since hearing Simon’s talk, we’ve started using #1 & #3 above at Tyro for describing the architecture of our biggest project. We’ve found it’s really advantageous for newcomers to the project to understand the context first, with all the detail of the innards presented later and not distracting them at first contact. We don’t use #2 because we generally don’t care too much where things are run. We do have some “zones” marked on our Components diagrams, but these are more coarse-grained than containers.)
Having these different levels allows you to show, e.g. a collaboration diagram between components, or a mapping from containers to physical infrastructure.
Remember that the agile manifesto doesn’t say that you shouldn’t write documentation.
(GL: It recommends: Value working software over comprehensive documentation)
Software Architecture as Code
Sketches get out of date. Can we automatically generate the diagrams instead? A lot of existing tools for doing this kind of thing aren’t great, but maybe you can write your own tools?
How about describing the software architecture using code?
Simon talked about how he’s working on a tool at structurizr.com to partially generate architecture diagrams from code.
Software Architecture Tips
Architectural refactoring is considered hard mostly because people don’t know where they’re at and aren’t clear on where they want to get to.
One of the reasons a lot of monolithic systems end up looking like big balls of mud is that code is organised by layers, rather than by component.
GL: I really liked this piece of advice:
“If you think your system’s hard to understand, change it.”
(GL: We have the power! Let’s fix it! Although, in practice, I suspect winning business support to “make the system easier to understand” will be hard for many.)
Stop making everything public.
He asked: What’s the essence of software architecture? It is CHAOS! Does the team understand what they’re building and how they’re building it? If not, they can end up with lots of non-functional problems: speed, security, stability, maintainability, etc.
We should be doing just enough up front design to understand the structure to create a shared vision for the team. Go down to the level of components, then stop. This should take a small number of hours or, for a very large system, a couple of days.
Simon said architecture sketching assists with collective ownership of the code. Good architecture diagrams can be used for “risk-storming“: take a big architecture diagram, have each person write down risks they can see and share them on the diagram.
Do just enough architecture to create firm foundations for the software product and its delivery. It’s about structure, vision and risk.
Make sure that every developer understands what software architecture is. Talk about architecture in retrospectives. Consider using architecture katas: practice drawing it a couple of times over.
Ultimately, he said, the architecture role is about educating: understanding the system that’s been built or is being built, then coaching & training others to align the team.
Image credit: “What’s That? (94)” by Steve Jurvetson
Want to learn more?
 |
  |
  |
  |
Simon’s 4 views are analogous to (if not stolen whole cloth from) Philippe Kruchten’s classic 4+1 model of architecture but somewhat modernized for today’s cloudy deployments. I agree that it is a useful paradigm for sorting things out up front in a fairly lightweight way. I’ve used 4+1 many times just to flesh out a conceptual model of a system and it became clear what sorts of tasks, teams, and resources were needed. However, there is often pushback from Agile extremists who insist on whiteboard+post-it mode of design since they perceive it as too formal.
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model