[Reading time: 2 minutes 17 seconds]
Are you familiar with Conway’s Law?
To summarise, it claims that technical and organisational structures will always mirror one another. For example, if you have three teams working on your product, it will have three distinct parts to it.
Depending on how you organise your teams, the parts will also have clearly visible shapes. Say, if you organise your teams by specialty (say, frontend, backend, database), you’ll end up with a frontend, backend, and database layer.
If you organise them by functional area (e.g. billing, content delivery, search), then these will be the block that become visible.
Now, functional architectures (for example microservices) are all the rage. Complete independence and autonomy… Except now you have five teams, but only two database experts.
This is a problem pretty much everybody is intimately familiar with. But what do we do about it?
The common solution is to share the two database experts between the five teams – what else can you do, right?
They get treated as a “shared resource”, and jump all over, helping everybody out.
Don’t get me wrong, it may work, but it sounds stressful – and by experience, it tends to work badly.
Coordination is hard, information flows worse than it ought to. Development will just be clumsy.
To me, sharing experts like that is a smell. Something’s off about the architecture.
In many cases, it would be better to instead create a distinct architecture element which holds data, and all teams make use of it. The database experts (plus others such as a backend person, if that’s helpful) would be responsible for building and running this thing – or things. Nothing wrong with a team taking responsibility for several small services.
This might sound pretty inflexible and non-autonomous: separate out a team, everybody has to come to them to be blessed with database functionality – that’s just the silo organisation we want to leave behind us, isn’t it?
But if done right, it isn’t. If that functionality is exposed on a self-service basis, everybody retains full autonomy. The database team can build and run their database service whichever way they like, while the consumers of this service don’t need anyone’s permission on if or how to use it. You need another database, sure, knock yourself out.
Of course communication is still required (feature requests will be made, capacity may need to be planned, etc), but nobody needs anyone’s permission. That’s the big difference, and that’s a worthy goal to aim for.