Predictability is underrated. Not simplicity — predictability. A system can be deeply complex and still be predictable, if it behaves consistently with its design. What breaks engineers is the system that appears one way and behaves another: the network topology that looks clean on paper but has an undocumented dependency that only surfaces during failover. The platform that seems stable until you add one more user group and discover that the permissions model was always wrong.

This series is about that gap — between intent and implementation — and what it takes to close it.

The thread

The five posts in this series span two distinct domains (networks and enterprise platforms) but follow the same pattern:

  1. Inherit or design a system
  2. Discover that the system’s behaviour doesn’t match your mental model of it
  3. Build the correct mental model — which usually requires going back further than you expected
  4. Make a change that aligns the implementation with the intent
  5. Document it, so the next person doesn’t have to do it again

Steps 3 and 4 are where most of the interesting work happens.

The posts, in order

Making Networks Predictable The foundational post. On why predictable network behaviour matters more than optimal network behaviour, and what it actually takes to achieve it in a multi-site environment.

Separating the WAN from the Core A specific design decision — moving WAN termination off the core switching layer — and why the performance argument was less important than the fault-isolation argument.

Making Redundancy Real On the difference between designed redundancy and tested redundancy. The network had failover paths on paper. The question was whether they worked.

The Accidental SharePoint SME The series crosses into platform administration here. The pattern is the same: an inherited environment, undocumented decisions, and behaviour that only made sense once you understood the history.

Oracle WebCenter — Inheriting the Unmappable The most recent and most complex version of this pattern. Two hundred and forty-four portals. No ownership records. No documentation worth the name. The story of making sense of it anyway.

Recommended addition: What Counts as Disaster Recovery? is a natural companion to this series — a post about the gap between the DR plan and the DR reality. Worth reading alongside Making Redundancy Real.

Tags