Pitfalls and antipatterns

The book catalogues patterns that look reasonable but reduce evolvability. The ones most relevant to enterprise and cloud work:

Antipattern	What happens	Mitigation
Vendor king	The architecture is built around one big vendor product, so the vendor’s roadmap becomes yours.	Treat vendor products as integration points behind your own boundaries.
Leaky abstractions	A layer hides details until it fails, and then you need to know everything underneath.	Know what your abstractions depend on; test failure modes.
Last 10% trap	Low-code or framework tools get you 80–90% there quickly, then the rest is very hard.	Check the edge cases before committing.
Code reuse abuse	Shared libraries everywhere couple teams’ release cycles.	Reuse where it reduces coupling; accept duplication across quanta.
Inappropriate governance	One technology standard for every team, regardless of needs.	Govern outcomes with fitness functions; allow a range of choices (“goldilocks governance”).
Resume-driven development	Technology picked because it’s interesting, not because it fits.	Tie choices to prioritised characteristics; record the reasoning in ADRs.
Planning horizons	The more effort spent on a plan, the harder it becomes to abandon it (sunk cost).	Plan in short horizons; keep options open.
Bit rot / architectural drift	Unmonitored structure degrades over time.	Continual and triggered fitness functions.

Key takeaway

Several of these are directly relevant to cloud platforms: deep use of one cloud provider’s proprietary services is a form of vendor king (sometimes a deliberate and fine trade-off), and a single mandated platform stack for every workload risks inappropriate governance. The right answer is usually to make the trade-off explicit, record it, and know how you would get out.