[Reading Time: 1 minutes 53 seconds]
Yesterday we discussed the risk of mis-slicing your architecture. Today, I’d like to discuss how to slice it safely.
Before we get into the thick of it, we should take a step back and understand what makes a good architecture.
I could throw all sorts of technical terms at you, like the Single-Responsibility Principle, or the Open-Close Principle, or many other important-sounding Principles.
I want to talk about something else: dealing with risk.
To me, that’s the fundamental purpose of any kind of architecture. It’s also the fundamental question that needs to be asked of it: to what degree does it create or mitigate risk?
Seen through that lens, our example from yesterday starts making sense: having a shared electrician carries little risk. Fundamentally, as far as power, all machines have similar and well-understood needs, and the ways to meet them are similarly honed. Sure, go ahead, share an electrician. The risk is pretty minimal.
On the other hand, sharing a database system between teams/parts of the product feels more problematic. There are cases where it makes perfect sense, but equally there are cases where it would be a terrible choice, be it because of data structure, or load, or reliability, or what have you.
So there are certainly technical risks. However, in light of thinking about DevOps transitions, I’m rather thinking of something easily overlooked: organisational risk.
In what ways would a certain architecture shackle several teams together? Risk hampering their growth? Encroach on their autonomy?
In order to preserve autonomy, wouldn’t it make sense to keep everything as independent as possible? It feels like it.
Here’s the kicker though: sometimes, more separation requires a team taking on more responsibility – which may well decrease their autonomy.
This is a question that’s rarely asked when discussing architectures, but I consider this kind of organisational debt much more insidious than any technical debt you may be worrying about.