Standardization before individualization
No budget has a line called complexity. It hides inside every other line instead: the migration that takes three times as long as planned, the audit finding that surprises everyone, the onboarding that takes months because nothing works the way the documentation says, the change nobody dares to make because nobody knows what depends on it. Complexity is the largest cost driver in most IT organizations, and it never once appears under its own name.
Where it comes from
Not from villains. From reasonable people making reasonable local decisions. One team needs a special configuration for a real requirement. One project picks a different tool because it is genuinely better for their case. One exception gets granted because the deadline was tight and it was just this once. Every single decision is cheap and defensible in the meeting where it is made. The sum is a landscape where everything is a special case, and where every piece of work starts with archaeology.
The compounding is the point. An exception does not cost what it costs today. It costs a share of every future migration, every audit, every security review, every handover from now until someone finally pays to remove it. Every exception is a future migration. Most organizations are running dozens of them in parallel without ever having decided to.
The principle
Standardize the majority, and make the minority deliberate. The default configuration serves eighty percent of cases and lives on a paved road: documented, supported, fast. The twenty percent that genuinely needs to be different gets to be different, consciously: each exception with an owner, a written reason, and a review date. The difference between an architecture and an archipelago is not zero exceptions. It is zero accidental ones.
This only works if the standard deserves to win. A standard nobody follows is a document; a standard everyone routes around is an indictment. The paved road has to be genuinely faster than the detour, or people will take the detour and they will be right to. Which means standards need to be treated as products: maintained, versioned, with users whose feedback changes them. When shadow solutions bloom, the correct first response is not a compliance campaign. It is fixing the road.
The innovation objection
Doesn't standardization kill creativity? In practice, the opposite. Innovation runs on attention, and attention is exactly what complexity eats. Teams that spend their days navigating special cases have nothing left for the work that actually differentiates. Boring foundations are what interesting work stands on. Be uniform where it does not matter, so you can afford to be different where it does.
Measuring it
Three numbers tell the truth better than any maturity model. The count of open exceptions per service, and whether it trends up or down. The number of variants of the same capability running in parallel. And the time it takes to provision the standard thing, because that number is the honest quality score of the paved road itself. If provisioning the standard takes six weeks, the exception list will grow no matter what the policy says.
Exceptions are not the enemy. Accidental exceptions are. An organization that knows exactly where it deviates, why, and until when has an architecture. One that has to find out has a history. The work of moving from the second state to the first is slow and unphotogenic, and it is worth more than most modernization programs, because it is the one that makes all the others cheaper.