Between the 6th and 7th of September 2022, I attended the Agile meets Architecture conference in Berlin. Like for most of us, it has been quite some time since I have been at such an event so I was looking forward to it - and (spoiler) was not disappointed ;-)
The conference's venue was lovely Kulturbrauerei at Prenzlauer Berg. I found this out the hard way as my brain had memorized "Kalkscheune" - the venue the MicroXchange conference was held some years before. Luckily enough, my bike quickly brought me to the right place.
Kulturbrauerei at Berlin Prenzlauer Berg (source)
The format of the conference was unique:
We have noticed that organizations struggle with the marriage between agile and architecture. Sometimes agile takes precedence, sometimes architecture takes precedence. Our attempt with the conference is to encourage conversation between practitioners of these different domains, further understanding and respect, and find new ways to achieve common goals for modern organizations. (source)
I must admit that I liked the idea. Particularly in larger environments, you can't think of architecture without the surrounding organization. Like most of the conference guests, I've been a busy listener and a busy note-taker as well. However, instead of summarizing every single talk, I'd like to wrap up the ideas and topics I've seen popping up more than once.
Just arrived
Evolutionary Architecture
"Evolutionary Architecture" is not only a book but a real thing. It has spread and was discussed and referred to many times. Rebecca Parson introduced the topic in her talk "Building Evolutionary Architecture". If you haven't been there, it is now also available on YouTube.
She started by asking how long-term planning under constant change should be possible. Gone are the days of 5 to 10-year architectural roadmaps. She and her co-authors suggest an evolutionary approach instead:
An evolutionary architecture supports guided, incremental change across multiple dimensions. (source)
A fundamental part of evolutionary architecture are fitness functions. As they kind of become a brand of their own, I dedicate the next section to them.
I particularly enjoyed Rebecca's reference to the need for experimentation including the possibility of failure. There should be a culture which supports experiments. Management can be a role model here. To back this up she told the story of a manager, who, after taking the wrong decision although he had been warned by his team, returned to the team and apologized: "Sorry, I was wrong".
Here we are again at the conference's mission - it's not only tech. It's also the people and their interactions. Or as Uwe Friedrichsen in his talk "Tell me why - About the purpose of architectural work" stated: It's not a computer business, it's a people business.
Fitness Functions
An integral part of an evolutionary architecture are fitness functions:
An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s). (source).
I had difficulties grasping this rather abstract definition and was glad that Patrick Kua in his talk "Organising and Governing Evolutionary Architectures" provided a more approachable definition: How close is a solution to a given goal?
In the second part of his presentation, Patrick provided some concrete examples that further enlightened the topic 😉. Here is a small selection:
| Fitness Function | Approach | Example Tool |
| Is the code structured in layers? | Pat discussed a couple of approaches. Popular are code scanners which run as part of your test suite and check if the predefined rules are not violated. | ArchUnit, JDepend |
| Is the content of my web page understandable? | This example was referring to a previous project in the UK where the function was manually executed aka a person had to read the text and judge. Potential automation could be to feed the text via an API to an AI-based grammar tool and decide on the score returned. As I understood this approach is just an idea but I liked it. | Grammarly, Hemmingway |
| Are the production Servers (if you still have any 😉) safe? | Here you can employ automated tests to check if desired server state matches your expectation. | InSpec |
The examples above always aim for automation. Generally, this is what you want to do. Manual fitness functions scale not well (e.g. you can't review everything). Also, there is an interesting human effect: If an automated fitness function fails, there is no blaming as people are less likely to take it personally.
Code The Architecture
In his talk "Coevolution of Architecture and Code - Closing the Gap" native agilist Dave Thomas (I was there) was pointing in the same direction. The architecture needs to co-evolve with the code he stated and called to code the architecture.
Dave gave a couple of examples including API definitions, Infrastructure as Code and also coded diagrams like structurizr for C4 type of diagrams. As I am also a fan of the latter I'd like to add mermaid as it is natively supported by Github and GitLab markdown.
I enjoyed Dave's presentation style and recommend watching his talk once it is available on the conference's YouTube channel.
Upfront Design
Another reoccurring topic at the conference was upfront design and how much of it is needed. Randy Shoup stated in his 1st-day keynote "Agility and Architecture Together – Enabling a Fast Flow of Change": Big upfront design doesn't work but also no design up front does not work. He suggested starting with a minimal design and then continuing with prototypes or pilots to receive real-world feedback.
Dave Thomas and Simon Brown in their talks equally agreed that Big upfront design is dumb but no upfront design is dumber.
So there seems to be some consent here. An interesting perspective was brought in by Uwe Friedrichsen in his talk "Beyond 'it depends' - How much architectural work do we need?".
Uwe added the level of uncertainty your product is facing - the more you are in a "save space" (e.g. a regulated environment) the more extensive you can allow for designing upfront. Here, it is rather unlikely that a disruptive market turns your product ideas upside down. On the other end, however, e.g. in the startup or pure innovation space where there is little or no certainty, you have to be able to rapidly adopt when you observe that you and your product are on the wrong path. This in turn limits your upfront design possibilities.
My suggestion is, that if Big Design UpFront (BDUF) is not what we want, then let's settle with Some Design UpFront (SDUF).
My "Need to look into that" boxes
At our last local meetup we came up with the metaphor of packing each other little imaginary "you need to look into that" boxes. As the evening goes on, these invisible boxes pile up next to you. At the end of the meetup, you take them home (again, they don't exist). We had fun packing each other these boxes: "Oh, you haven't heard about XYZ? - Well, then here is another little box for you." ;-).
(source)
Unsurprisingly, I packed quite a few of these "need to look into that" boxes at the conference. Here is my list:
- book "Team Topologies" by Matthew Skelton and Manuel Pais. Cited a lot. This is a must-read.
- "Continuous Delivery" Youtube channel by Dave Farley. Just skimmed over the existing videos. Looks promising. A good candidate for binge-watching.
- book "Drive" by Daniel Pink. Also seen on a lot of slides.
- book "Modern Software Engineering" by Dave Farley again. According to Dave Thomas, the content of this book is by no means "modern" but essential knowledge. Just read the intro and can't wait to find time to continue.
- book "Just Enough Software Architecture" by George Fairbanks
- fresh DDD material and illustrations ♥: github.com/ddd-crew
Closing
As you can imagine, the points above are just a glimpse of what happened at the conference but there is a rescue. The conference's YouTube channel will eventually contain the recordings of all the talks - check them out!
Amongst the many things discussed over the track of the conference I am glad to got reminded again that architectural problem solving is almost never about technology decisions (tnx Philip). Nowadays magic enterprise triple Kubernetes, Kafka and Java is no guarantee for project success. With an eye on the operational complexity, they might even worsen your situation.
The closing keynote was held by Luxshan Ratnaravi of Comic Agilé. I didn't count how often I burst out laughing. Here is one of the reasons:
There is more on comicagile.net. If you are a paper person, there are even printed books.
Overall these were two marvellous days. It was all there:
- good conversations
- meeting people I only met online before (hello Stefan 😉) and
- lots of thoughts and insights.
Like after a good party I was quite sad when the lights turned on - and I had to catch the train home.
Thank you
Dear organizers - thank you so much for all the work you put into these two days. As a meetup host, I can imagine that there is a looooot to it.
Dear sponsors, thank you for making this event possible. The fewest I can do is to name you here:
Dear guests, dear speakers, it's been a pleasure to spend these two days with you. See you 👋