What are the trade-offs between running a tech radar as purely advisory guidance versus backing it with mechanical enforcement (like architecture fitness functions or CI dependency gates), and when would you deliberately choose the lighter-weight advisory approach?

## The choice, stated The choice between advisory and enforced governance is really a choice about where an organization wants to spend its scarce trust and engineering effort, and it should be made **per-category** rather than as a single blanket policy for the whole radar. ## Mechanism — advisory governance The radar is published (a wiki page, a dashboard, a quarterly presentation), ring placements are communicated, and compliance relies entirely on teams voluntarily consulting it and social/managerial pressure to follow it. There's no automated check stopping a team from using a Hold-ringed dependency; at most, a code reviewer might flag it, or an architect doing a periodic audit might notice and raise it after the fact. ## Mechanism — enforced governance Specific, checkable rules get encoded into automated gates. Common implementations include: - a CI pipeline step that runs a software composition analysis (`SCA`) scan and fails the build if a manifest references a denied package or version; - an **architecture fitness function** (a term popularized in the book 'Building Evolutionary Architectures') — an automated, executable check that continuously verifies an architectural characteristic holds, such as a static-analysis rule asserting that no service in a given bounded context imports a library outside the Adopt list, or that all outbound HTTP calls target an approved list of internal domains; - or infrastructure-level controls like a cloud landing zone's service control policies blocking provisioning of a non-approved managed service entirely, so the violation is prevented rather than merely detected. ## The two at a glance | | Advisory | Enforced | |---|---|---| | Cost to run | cheap to run | costs real engineering investment to build and keep current | | What it buys | maximum team autonomy and exploration speed | real, continuously-verified consistency | | How a violation surfaces | a code reviewer might flag it after the fact | a fitness function catches a violation the moment it's introduced | | How it fails | the moment a delivery deadline gets tight, the guidance gets quietly ignored | unless there's a fast, well-known waiver path, engineers start working around the gate itself | ## Cheap guidance versus real teeth **Why both approaches exist, and the real trade-off:** - **Advisory governance** is cheap to run and preserves maximum team autonomy and exploration speed — nobody has to build or maintain a checking tool, and edge cases don't get mechanically blocked by a rule that didn't anticipate them. Its cost is that it has no teeth: the moment a delivery deadline gets tight, the guidance gets quietly ignored, and because nothing detects the deviation automatically, the organization typically doesn't find out until an incident, an audit, or a much later, expensive migration effort surfaces just how far actual practice has drifted from the published radar. - **Enforced governance** buys real, continuously-verified consistency — a fitness function catches a violation the moment it's introduced, not months later — but costs real engineering investment to build and keep current (fitness functions need to be updated every time the standard changes, or they become a source of false positives that erode trust in the whole system), and it adds friction: a legitimate edge case that the rule didn't anticipate gets blocked just like a genuine violation would, and if there's no fast, well-known waiver path, engineers start working around the gate itself (vendoring a denied library under a different import path, disabling the check locally) rather than through it — which is strictly worse than not having the gate, because it hides the deviation from view instead of surfacing it. ## Choosing per category **How to decide, deliberately:** the right lever is blast radius and cost-of-mistake, applied per-category rather than uniformly. - **For genuinely exploratory categories** — Assess and Trial-ring technologies, or anything a small, low-blast-radius internal system is using — advisory is usually the right call: the cost of a bad outcome is contained, and the enforcement overhead would strangle exactly the exploration the radar's outer rings exist to enable. - **For anything with regulatory, security, or brand-risk exposure** — cryptographic libraries, PII-handling data stores, anything touching payment flows — enforcement earns its cost even for a small organization, because the downside of a silent violation (a breach, a compliance finding) is disproportionate to the friction cost. Organizational scale matters too: a five-team startup can often get away with purely advisory governance because informal social pressure (a Slack channel, a weekly sync) is a functioning enforcement mechanism at that size; a two-hundred-team enterprise cannot rely on that — nobody has visibility into what every team is actually doing, so mechanical checks become the only scalable way to know reality matches policy. ## Two ways it goes wrong **Failure modes in production:** - **An org that enforces everything** ends up with brittle, high-maintenance fitness functions that engineers route around, and a security team perpetually fighting waiver-ticket backlogs. - **An org that enforces nothing** discovers, usually during a security audit or an incident postmortem, that the actual technology footprint bears little resemblance to the published radar — dozens of undocumented deviations that accumulated silently because nothing was ever checked. ## Where enforcement effort actually goes A concrete instance: Netflix's well-known internal use of architecture fitness functions targets exactly this pattern — automated checks continuously assert specific, high-consequence architectural rules (e.g., service dependency constraints, required resilience patterns) are held to, while broader technology exploration across their famously heterogeneous stack remains comparatively unconstrained and advisory, concentrating enforcement effort precisely where the cost of a silent violation would be highest.