[Reading time: 2 minutes 6 seconds]
I’d like to explore this intersection between architecture and team organisation some more.
I find it infinitely interesting, because it shows how technical aspects by necessity influence, and are influenced by, human aspects.
So… good architecture is one that is one that’s good at dealing with risk. OK. Fine.
Of course there are many types of risk, some purely technical: e.g. the risk of having too little capacity – there are several ways of dealing with that.
Let’s go for more exciting risks.
How do you deal with risks during the development process? These almost always take the form of having incomplete, incorrect or otherwise bad information.
The thing is: during development, information is produced, consumed and shared by humans. So any issues that arise, even if they seem to be technical, immediately have a human component to them.
This is where well-crafted architectures shine: not only can you make technical changes without too much effort, but the humans involved are able to deal with the changes well too.
It’s a bad sign if you need to change something about your technical architecture, and you need to reshuffle your teams. Or spend time and effort aligning different parts of the organisation to end up with the desired result.
I have a big corporate client where it takes six weeks to get a new virtual machine. That… sounds like a problem.
A new VM, on the face of it, is a technical thing. But this technical thing is impeded by organisation and processes. To me, that’s a huge architectural risk: the technical architecture demands VMs, but the organisational architecture makes that close to impossible.
So in order to deal with risk and surprises, a team needs to be autonomous: be empowered to find their own solutions. That has a cultural aspect (are you allowed to make your own decisions?), but it also has an organisational aspect: can a team, say, create new VMs without having to ask for permission? And a technical one: are they technically capable of doing it – are there interfaces to enable them?
So, when setting up an architecture, consider the connections between the boxes you’re drawing not just from a technical, but also from a human communications and agency perspective.
In my observation, that is at risk of being overlooked.