Order Your -ilities Before You Pick Your Architecture
"Our architecture is microservices" names one of four dimensions and answers almost nothing. Style is the hardest decision to reverse, so it should be derived from a ranked list of characteristics — not chosen first and justified afterwards. Here is the meeting that does it.
Ask a team what their architecture is and you will usually get a style name. "Microservices." "Event-driven." "It's a modular monolith."
Then ask what the system needs to be good at, and watch the room.
The second question is the architecture. The first is one of four dimensions — alongside architectural characteristics, architectural decisions, and logical components — and it is the one people wrongly use to describe the whole. "Our architecture is microservices" names a deployment model and answers almost nothing about what the system is shaped for.
Worse, it is usually chosen first and justified afterwards, which is exactly backwards for the decision that is hardest to reverse.
What a characteristic actually is
Architectural characteristics are the capabilities a system needs in order to succeed, independent of what it does — the "-ilities." Scalability, availability, testability, deployability, security, maintainability.
There is a three-part test, and all three parts must hold. A characteristic:
- Is not about what the system does — it is a how or a why, never a what.
- Influences some structural aspect of the design — it changes the shape of the system, not just the code inside it.
- Is critical or important to application success — not merely nice to have.
That second clause is the useful filter. Security is only an architectural characteristic when the architect must make special structural effort to accommodate it. If your framework handles it and nothing about the structure changes, it is not one — it is a requirement you satisfy, not a force that shapes the system. The same goes for half the words that end up on these lists.
Why the ranking is the work
Everyone wants scalability. Everyone wants maintainability, availability, simplicity and security. Ask a room to list desirable characteristics and you get all of them in ninety seconds, and you have learned nothing.
A list is free. A ranking costs something, and that cost is the design work.
If you find a decision in software architecture that doesn't involve a trade-off, you have not looked at it hard enough yet.
Ranking forces the trade into the open. Putting scalability first means accepting worse simplicity — structurally, those two move in opposite directions almost perfectly. Putting simplicity first means accepting a ceiling on scale. Both are defensible; refusing to choose is not, because the system will embody a choice whether or not you made it.
The test for a real ranking: name what you gave up. If nothing was given up, the ranking is decorative.
Three is the practical limit. Beyond that you have not prioritised, you have re-listed.
The meeting
Ninety minutes, before anyone says a style name.
1. Candidates (20 min). Everyone proposes characteristics. Apply the three-part test to each — especially clause two. Anything that does not change the structure gets struck. This alone usually halves the list.
2. Forced ranking (30 min). Pick the top three, in order. The rule that makes it work: for each one, say what you are accepting less of. "Scalability first — we accept a more complex deployment and slower local development." If someone cannot complete that sentence, the characteristic is not really first.
3. The binding constraint (10 min). Of the three, which one is currently hurting or will hurt first? Ranking is theory; this is the one you are buying now.
4. Derive the style (20 min). Only now name candidate styles, and score each one against your three ranked characteristics — strong, adequate, weak, plus what it costs to operate. With a ranking already on the wall this stops being a debate about fashion and becomes a lookup, which is the only honest way to compare structurally different systems.
5. Record the why (10 min). Not the decision — the reasoning. A decision without its rationale is unmaintainable: in a year nobody can tell whether it still applies, so it either gets cargo-culted forward or thrown out for the wrong reason.
The template
System: ______________________ Date: ________
Top three characteristics, in order:
1. ____________ — we accept less: ____________
2. ____________ — we accept less: ____________
3. ____________ — we accept less: ____________
Binding constraint right now: ____________
Therefore, style: ____________
What would change our mind: ____________
That last line is the most valuable and the most often omitted. It converts the decision from a belief into a falsifiable position — and it is what lets a future team revisit it honestly instead of relitigating from scratch or defending it out of loyalty.
Two honest caveats
That scoring is a shape, not a score. One verdict on "performance" covering every possible implementation of a style is obviously lossy. Use it to see which characteristics a style structurally favours, not to compute a winner and end the conversation.
Rankings expire. The constraint that binds a ten-person startup is not the one that binds the same product at eighty engineers. Re-run this when the team size, the load profile, or the failure cost changes materially — which is also why "what would change our mind" earns its place on the page.
The takeaway
Requirements tell you what to build. Characteristics tell you what shape it has to be. Style is downstream of both, and it is the decision you will find hardest to undo.
Rank three -ilities and name what each one costs you. The style is then a lookup, not an argument.
If the meeting produces a style name before it produces a ranking, it was not an architecture meeting. It was a preference being ratified.