Case Studies and Anti-Patterns

Part VI turns from the craft to the experience of practising it. This chapter collects what recurs: three cases in which a security architecture practice changed, and five anti-patterns that appear when it changes badly or not at all. It concerns all four shifts, because each anti-pattern is a way of failing one of them. The diagram nobody runs and the control catalogue nobody maps fail Shift 1, from documents to code. The architect as bottleneck fails Shift 2, from gatekeeper to boundary designer, and with it Shift 3, from periodic to continuous, at machine speed. The AI that approved itself and the sign-off in seconds fail Shift 4, from sole author to conductor of an AI team. Nordvik Region and Hansa Mutual stay out of the cases; the closing section shows only which anti-patterns each recognised in itself.

An anti-pattern is not a mistake: it is a solution that looks reasonable, is adopted repeatedly and produces the same bad outcome each time. Architecture as Code (Chapter 26B) catalogued the anti-patterns of architecture programmes (161, Nordqvist, 2025), and AI Governance, Chapter 20, those of enterprise AI programmes (162, Nordqvist, 2026). This chapter catalogues the failures of the security architecture practice itself.

The first two cases are illustrative composites: each combines the experience of several organisations, details are altered, and the figures show proportion, not measurements. The third case is observable and rests on public incidents of 2025 and 2026. The anti-patterns are the author's synthesis, citing published findings where they exist.

Primary topics explored

1. How to read the cases
2. Case: a review board that became a design authority
3. Case: an authority that held boundaries through contracts
4. Case: an agent incident reconstructed
5. The anti-patterns
6. Patterns across the cases