Post

We spent two days training architects and tech leads and never gave them a definition of architecture. That was deliberate. There is no settled definition, and that is a large part of why architecture frameworks travel so badly from one organisation to the next.

Two companies, two days, and Evelyn van Kelle and I ran them differently because they are at different points in their learning journey.

The first group had not worked through what architecture means in their own context yet. So we started from the significant decisions that shape a system, put that system in its sociotechnical context, and looked at why behaviour matters when you design systems.

We closed that day with Team Topologies and team interaction modelling. Designing a software system means designing how your teams interact.

The second group had already done that work. What they were missing was the landscape those decisions get made in, so we started with @swardley.bsky.social Wardley Mapping and where users, their needs and the market sit within it.

Then user needs mapping on top of it, team structures against the value chain, reliability engineering and threat modelling, all on one map, one landscape.

We finished with a stressor analysis from Barry O'Reilly's Residuality Theory, which opened up complexity and why understanding the strategy, the landscape and the market is what lets an architecture survive significant changes it was never designed for.

AI came up once across both days, and only to say that none of this gets easier to skip. The hard part has always been building a shared understanding of the user, their needs and the market they are in.