Standardization

Introduction

Standardization is the principle that turns the good decisions of one team into the default for everyone else. The goal is simple to say and hard to do: the right way should also be the easiest way, so that teams spend their energy on the product and not on rediscovering, for the fifth time this year, how to call an API with retries.

In small companies, this happens almost by accident: there are five developers, they sit next to each other, and everybody uses whatever the most senior person chose. The problem shows up when the company grows. New teams arrive, each one with its own taste, its own favorite framework and its own "better" way of doing things. A few years later, you look at the landscape and find:

• Several logging libraries, each with its own format, so no one can correlate a request across services;
• Five different ways to call an HTTP API, three of them without timeouts;
• Every service with its own error format, so each client has to write a custom parser;
• Infrastructure copied and pasted between repositories, with small differences no one remembers the reason for;
• New hires who take months to become productive, because every repository is a new world;
• A critical security patch that takes weeks to roll out, because nobody knows where the vulnerable library is used;

Yep, it's rare, but it happens all the time... Who hasn't opened a repository and thought "wait, why does this service do everything differently from the others?" And the worst part is that each of those choices made perfect sense on the day it was made.

Naive Junior

"But isn't that what team autonomy is all about? Each squad picks the best tool for its problem. Standards sound like the architecture police coming to take my favorite framework away!"

Easy there, Junior! Autonomy is great, and nobody here wants an architecture police. But autonomy without any common ground has a price, and that price is paid by everyone: by the on-call engineer who has to debug a service written in a stack she has never seen, by the security team hunting for vulnerable dependencies, and by the next developer who joins your squad.

Good standardization doesn't take autonomy away. It takes away the decisions that don't deserve your attention (which logger, which log format, how to structure a pipeline) so you can spend your autonomy where it actually matters: the business problem.

The Story of 12 Logging Libraries and 5 Ways to Call an API

Let me tell you a story that, with small variations, I have seen in more than one company.

A company starts with a monolith. Then it adopts microservices, and each new team gets a lot of freedom. The payments team loves one logging library. The catalog team prefers another, because it's faster. The search team writes its own wrapper, because none of the existing ones "does exactly what we need". Three years and forty services later, someone counts: twelve logging libraries. And for calling HTTP APIs, there are five different approaches, from a well-configured client with retries and circuit breakers to a hand-rolled function that simply waits forever when the other side doesn't answer.

Everything works, more or less, until the day of the big incident. A customer reports that payments are failing intermittently. The on-call engineer tries to follow the request from the frontend to the payment provider, and discovers that:

• Each service logs in a different format, some in JSON, some in plain text;
• Only half of them propagate a correlation ID, and each one uses a different header name;
• The service that is actually failing uses the hand-rolled HTTP client, with no timeout, so threads pile up until everything stops;

The fix takes ten minutes. Finding the problem takes six hours.

A few months later, a critical vulnerability is announced in a popular logging library (anyone who lived through Log4Shell in December 2021 knows exactly what this feels like). How many services use it? Nobody knows. Each team has to check its own dependencies, some are on vacation, some repositories haven't been built in a year. The patch that should take a day takes three weeks.

Notice that nobody in this story was incompetent. Each decision, taken alone, was reasonable. The problem is the sum of reasonable local decisions, with nobody looking at the whole. That's exactly the gap this principle fills.

Why Standards Pay Off

It's easy to see standards as bureaucracy. So let's be concrete about what they buy.

Less cognitive load

Every technical decision a developer has to make, or understand, takes up a piece of their head. The folks behind Team Topologies talk about extraneous cognitive load: the effort spent on things that have nothing to do with the problem you're solving. Figuring out which of the twelve loggers this repository uses, and how it's configured, is pure extraneous load.

When the basics are standardized, a developer who opens any repository in the company already knows where the pipeline is, how logs are written, how errors are returned and how the service is deployed. Their head is free for the part that is actually new: the business logic.

Faster onboarding

A new hire in a standardized environment learns the platform once. After that, moving between teams costs days, not months. The same applies to internal mobility: people can help other teams during an incident, cover for colleagues on vacation or move to a new product without starting from zero.

Lower risk

Standards concentrate knowledge and effort. A shared HTTP client with sensible timeouts, retries with backoff and a circuit breaker protects every service that uses it. A security patch in a shared library is applied in one place and rolled out by updating a version. An inventory of which services use which building blocks tells you, in minutes, where you are exposed.

Economies of scale

Anything built once and reused many times gets better over time: more people use it, more bugs are found, more edge cases are handled. Anything built forty times gets forty times the bugs, and each copy improves (or rots) alone.

What to Standardize (and What to Leave Alone)

Not everything deserves a standard. A good rule of thumb is: standardize the seams, not the insides.

The seams are the places where teams, systems and people meet: API contracts, event formats, authentication, logs and traces, deployment, infrastructure. Inconsistency there hurts everyone, because it leaks into other teams. The insides are the implementation details of a service that nobody outside the team needs to see: how the code is organized internally, which testing helper they prefer, how they name private functions. Inconsistency there hurts, at most, the team itself.

This split also helps with the tension Junior raised. Teams keep their autonomy where it doesn't affect anyone else, and give up just a little of it at the seams, in exchange for a lot of collective benefit.

The Standardization Toolbox

There's no single tool that solves standardization. There's a set of complementary practices, each good at one thing. Let's go through them.

1. Keep a Technology Radar

Goal: make technology choices visible, explicit and easy to consult, instead of living in the heads of a few senior people.

The idea was popularized by ThoughtWorks, which has published its Technology Radar twice a year for more than a decade. Each technology (a tool, a platform, a technique, a language or framework) is placed in one of four rings:

• Adopt: the default choice for new work. If you pick something else, you should have a good reason;
• Trial: worth using on real projects where the risk is manageable. We're building experience with it;
• Assess: worth exploring, with a spike or a proof of concept, to understand how it could affect us;
• Hold: don't start anything new with it. Existing uses can stay, but the direction is to move away.

The magic of the radar is that it's a conversation, not a law. It tells teams where the organization is heading, it gives new technologies a legitimate path in (Assess, then Trial, then Adopt), and it gives old ones a dignified path out (Hold). ThoughtWorks even made their tooling open, so any company can build its own radar.

Benefit: fewer technologies in parallel doing the same job, fewer surprises, and a place where "why do we use X?" has a written answer. Tie the radar to your portfolio rationalization efforts: the Hold ring is often the first list of candidates for retirement.

2. Publish Reference Architectures

Goal: give teams a proven starting point for the most common kinds of systems.

A reference architecture is a documented, opinionated blueprint for a recurring problem: "a REST API with a relational database", "an event-driven worker", "a static site with a CDN", "a data pipeline". It shows the components, how they connect, which building blocks to use, how it's secured, monitored and deployed, and, very importantly, why each choice was made.

Cloud providers publish plenty of them (the Azure Architecture Center and the AWS Architecture Center are good examples), but the most valuable ones are your own, because they already include your identity provider, your network rules, your observability stack and your compliance requirements.

Benefit: a team starting a new service doesn't begin with a blank page. They begin with something that already passed security review, already fits the platform and already has a known cost profile.

3. Build Golden Paths on an Internal Developer Platform

Goal: turn standards into something teams use, not something they read.

Documents are great, but people don't read documents at 6 pm on a Friday. What works much better is making the standard the path of least resistance. That's the idea behind the golden path (Spotify's term) or paved road (Netflix's term): a supported, opinionated and well-maintained way of building and running a certain kind of software, from the first git init to production.

In practice, a golden path is delivered through an internal developer platform: a set of self-service capabilities, owned by a platform team and treated as a product. A developer picks a template in a portal (tools like Backstage are common here), answers a few questions and gets a repository with the service skeleton, the pipeline, the infrastructure, logging, tracing, dashboards and alerts, all already wired to company standards.

Naive Junior

"So the platform team decides everything and we just do what they say? What if my service really needs something the golden path doesn't have?"

Great question, Junior, and that's why the figure has an off-road box. A golden path is a recommendation made irresistible, not a cage. You're allowed to leave it, but then you own everything the platform would have done for you: the pipeline, the patching, the monitoring, the 3 am pager. Most teams, doing that math honestly, stay on the path. The few that leave usually have a real reason, and those reasons are the best input the platform team can get about what to build next.

The other half of the answer: a good platform team treats developers as customers. It has a roadmap, collects feedback, measures adoption and satisfaction, and competes for its users. If teams are escaping the golden path in droves, the problem is the path, not the teams. The CNCF's work on platforms and Team Topologies (with its "platform as a product" and "thinnest viable platform" ideas) are good places to go deeper.

Benefit: standards applied by default, without anyone having to remember them. A new service is born compliant, observable and secure, which is where operational excellence and security shift-left become cheap instead of heroic.

4. Offer Reusable IaC Modules and Templates

Goal: make the infrastructure itself a set of tested, versioned building blocks.

Copying infrastructure code from another repository and tweaking it is how most drift starts. A better approach is to publish modules (Terraform modules, Bicep modules, Pulumi components, CloudFormation templates) for the pieces every team needs: a network with the right segmentation, a database with backups and encryption enabled, a container app with the standard sidecars, a storage account with the correct retention policy.

A few practices make modules actually useful:

• Version them with semantic versioning, so teams can upgrade on their own schedule and know when a change is breaking;
• Keep them small and composable, one module per responsibility, instead of a giant "do everything" module with a hundred parameters;
• Encode the non-negotiables (encryption, tagging, private networking) inside the module, so teams don't have to remember them;
• Test them in the module's own pipeline, before any team consumes a new version;
• Publish them in a registry with docs and examples, so finding them is easier than rewriting them;

Benefit: consistent infrastructure, security and cost controls built in, and improvements that reach every team with a version bump.

5. Define Service and API Standards

Goal: make every API in the company look and behave like it was designed by the same person.

APIs are the most important seams of all. When every team designs its own, clients end up learning dozens of dialects. A short, practical API guideline typically covers:

• Naming: plural nouns for resources, consistent casing (pick camelCase or snake_case for fields and never mix), predictable URLs;
• Versioning: how versions are expressed (URL, header or media type), what counts as a breaking change, how long old versions are supported and how deprecation is announced;
• Errors: one error format for everyone;
• Pagination, filtering and sorting: one way to do each;
• Cross-cutting headers: correlation IDs, idempotency keys, rate-limit headers;
• Security: authentication scheme, scopes, what must never appear in a URL or a log;

For errors, you don't even need to invent anything: RFC 9457 (Problem Details for HTTP APIs) defines a standard JSON shape that many frameworks already support:

{
  "type": "https://api.example.com/problems/insufficient-funds",
  "title": "Insufficient funds",
  "status": 422,
  "detail": "The account balance is 30.00, but the transfer needs 50.00.",
  "instance": "/transfers/7f3c",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736"
}

If you don't want to start from scratch, public guidelines like Microsoft's REST API Guidelines and Google's API Improvement Proposals (AIPs) are excellent references to adapt. For events and telemetry, the same thinking applies: agree on schemas, and prefer open standards such as OpenTelemetry for traces, metrics and logs (which, by the way, is exactly what makes observability first possible across teams).

Benefit: clients integrate faster, generic tooling (gateways, SDK generators, linters, dashboards) works for every service, and an on-call engineer can read any error without a translator.

6. Choose Wisely Between Shared Libraries and Copy-Paste

Goal: share what really needs to be shared, and nothing more.

Here's a spicy one. Shared libraries are the obvious way to reuse code, but they also create coupling: every consumer depends on the library's release cycle, its transitive dependencies and its bugs. The Go community has a famous proverb for this: "a little copying is better than a little dependency".

So when is a shared library worth it, and when is copying fine?

A practical heuristic is the rule of three: write it once, copy it the second time, extract a shared component only when the third team needs it and the shape is clear. Extracting too early freezes the wrong abstraction and couples teams for no reason.

And never, ever put business logic in a "commons" library shared by every service. That's how you end up with a distributed monolith, where changing a customer rule requires coordinated deploys of fifteen services. Domain logic belongs inside its bounded context.

7. Embrace Inner Source

Goal: let everyone contribute to shared components, instead of queuing requests for an overloaded central team.

Inner source means applying open source practices inside the company: shared components live in repositories everyone can read, anyone can open a pull request, there's a CONTRIBUTING.md explaining how, and a small group of trusted committers reviews and merges. The InnerSource Commons community has plenty of patterns and material on this.

It solves a classic problem: the central team that owns the shared library becomes a bottleneck, teams get tired of waiting and fork the code, and now you have six "shared" libraries again. With inner source, the team that needs a feature can build it themselves, with the owners guiding quality and design.

Benefit: shared components evolve at the speed of their users, knowledge spreads across teams, and the owners stop being a bottleneck without losing control over quality.

How a Standard Is Born, Lives and Dies

A standard isn't a stone tablet. It has a lifecycle, and managing that lifecycle well is what separates living standards from dead documents that everybody ignores.

Birth: RFCs and communities of practice

The worst way to create a standard is for one person (usually with "architect" in their title) to write it alone and announce it by email. People don't follow rules they had no part in, especially rules that don't match their reality.

A much better way:

1. Start from a real pain. "We have twelve loggers and can't correlate requests" is a great reason. "It would be nice to have a standard for X" is not;
2. Write an RFC (Request for Comments): a short document describing the problem, the proposal, the alternatives considered, the migration cost and the trade-offs. Keep it in version control, where anyone can comment;
3. Discuss it in a community of practice: a group of practitioners from different teams who care about the topic (backend, frontend, data, observability). They review the RFC, bring the view from the trenches and become the standard's ambassadors in their teams;
4. Record the decision in an Architecture Decision Record (ADR), with the context and the reasons, so that two years from now nobody has to guess why;
5. Pilot it with one or two volunteer teams before rolling it out, and adjust based on what they learn;

Andrew Harmel-Law's article on martinfowler.com about scaling architecture through the advice process is a great read here: anyone can make an architectural decision, as long as they seek advice from those affected and from people with expertise. It fits standards very well.

Life: ownership and versioning

Once adopted, a standard needs what any product needs: an owner (a team or a named group, never "everyone"), a place where it's documented, a version, a changelog and a channel for questions and feedback. Standards also need to show up where developers already are: in templates, linters, pipeline checks and the portal, not only in a wiki page.

Death: deprecation and retirement

Standards should die. Technologies age, better options appear, and a standard that was great five years ago can become an anchor. Retiring one well involves:

• Moving it to Hold on the radar and announcing the replacement;
• Setting a sunset date, with enough time for teams to migrate;
• Providing a migration path: guides, codemods, updated templates, and help from the owners;
• Tracking usage, so you know who still depends on it and can help them specifically;
• Actually removing it when the date comes, instead of letting it linger forever;

Naive Junior

"Why retire anything? If the old standard still works, just leave it there. Nobody gets hurt!"

Ah, Junior, if only it were that simple! Every standard that is never retired stays in the landscape, and keeping it costs money: someone has to patch it, someone has to know how it works, new hires have to learn it. Without retirement, "standardization" slowly turns into accumulation. You end up with two standards for the same thing, then three, and you're right back at the twelve loggers, except now each one has an official stamp. Retiring standards is as much a part of this principle as creating them.

The Trap of Over-Standardization

Now the other side of the coin. Just as a lack of standards creates chaos, too many of them create paralysis. Signs you've gone too far:

• Teams need approval from a committee to use any library, even for a small internal tool;
• The approved stack hasn't changed in years, and every new idea hits "it's not in the standard";
• People spend more time filling out exception requests than writing code;
• Good engineers leave because they feel they can't learn or try anything new;
• Shadow IT appears: teams quietly use whatever they want and hide it;
• The standards describe how things were done in 2018, not how the best teams work today;

Over-standardization kills innovation in a very quiet way. Nobody forbids experimentation explicitly; it just becomes so expensive that nobody bothers.

A few ways to avoid it:

Tradeoffs

Standardization reduces variance, cognitive load and risk, and lets the organization learn once and apply everywhere. But, like every principle, it comes with trade-offs. Something that makes the landscape more consistent can hurt other qualities of the architecture, or of the organization.

Shall we look at the main ones?

Consistency vs Team Autonomy

This is the central tension. Every standard removes a choice from a team. When the choice didn't matter much (which logger), that's a gain. When the choice really mattered for that team's problem (a data team forced to use the same database as a CRUD service), it's a loss, and sometimes a big one.

The balance comes from the split we saw earlier: strict at the seams, flexible inside. And from a culture where teams can challenge a standard with arguments and data, and where the standard owners actually listen. Autonomy and alignment are not opposites; the goal is aligned autonomy.

Lock-in to Internal Platforms

Everyone worries about vendor lock-in with cloud providers, but few people notice the internal lock-in. When every service depends on the internal platform, the internal libraries and the internal templates, the company is locked into its own creation. If the platform team shrinks, if the platform ages or if the company is acquired and needs to integrate with another stack, that dependency can become very expensive.

Some mitigations: build the platform on open standards (OpenTelemetry, OCI containers, standard IaC tools) instead of proprietary internal formats; keep the abstraction layers thin, so teams can see what's underneath; and document the escape routes. The "thinnest viable platform" idea exists precisely for this.

Maintenance Cost of Shared Components

Nothing is free. A shared library, an IaC module or a golden path template needs people: to fix bugs, to update dependencies, to answer questions, to keep backward compatibility, to write docs. When this cost is not planned, the shared component slowly rots, teams lose trust in it, and they go back to building their own. That's how you get twelve loggers with a standard.

If the organization wants reusable building blocks, it has to fund them as products, with a team, a roadmap and a budget. Otherwise, it's better to have fewer of them and maintain them well.

Tradeoffs with Reliability

Shared components create shared failure modes. A bug in the common HTTP client or a bad version of the base container image can hit every service at once. The blast radius of a mistake grows with adoption. Monocultures are efficient until the day they get sick all together.

Mitigations: roll out new versions of shared components progressively (canary teams first), keep them backward compatible, test them heavily, and make sure services pin versions instead of always pulling "latest". On the positive side, a well-built resilience library can raise the reliability of every service at once.

Tradeoffs with Security

Standardization is mostly a friend of security: fewer technologies mean a smaller attack surface, patches are applied in one place and inventories are easy. But the flip side is that a single vulnerability in a widely adopted component exposes everything simultaneously, and attackers love widely used components for exactly that reason. The shared pipeline and the internal package registry also become high-value targets in the software supply chain, so they need to be protected accordingly (frameworks like SLSA help here).

Tradeoffs with Cost Optimization

Platform teams, communities of practice, RFC reviews, migrations to new standards and the retirement of old ones all consume time and money that could go to product features. In the short term, standardization often costs more than it saves. The return comes later, through faster onboarding, fewer incidents and less duplicated work. On the other hand, standards can also improve cost optimization directly: standard modules with mandatory tagging, right-sized defaults and consolidated licenses.

Tradeoffs with Performance Efficiency

Standards are built for the common case. A generic HTTP client, a default database configuration or a standard container size will be good enough for most services and suboptimal for a few. A service with extreme latency or throughput requirements may need to go off-road, and the standards should allow that when there's evidence (measurements, not feelings) that the default isn't enough.

Naive Junior

"Hold on... So too few standards is chaos, too many is paralysis, and each one has a cost. How do I know where the right point is?"

Exactly, Junior, there's no magic number. The right point depends on the size of the company, its regulatory context, its maturity and its strategy. A startup with three teams needs very few standards; a bank with three hundred teams needs many more. What works everywhere is to start with the seams that hurt the most, measure whether the standards help, listen to the teams using them and keep retiring what no longer makes sense. Standardization is a continuous practice, not a project with an end date.

Conclusion

Standardization is how an organization stops paying, over and over, for the same decisions. Technology radars make choices explicit, reference architectures give teams a proven starting point, golden paths and internal platforms turn standards into the easiest path, reusable IaC modules and API guidelines keep the seams consistent, and inner source keeps shared components alive and evolving.

Most importantly: good standards are born from real pain, are built with the people who will use them, have owners, and die when they're no longer the best option. They reduce cognitive load, onboarding time and risk, without killing the experimentation that keeps the company moving forward.

And remember: standards define the what. Who decides, how compliance is checked and how exceptions are handled is the job of governance. Get both right and you have an organization where teams move fast because they share a solid common ground, not in spite of it.

Next Steps

1. Take inventory of the current landscape Map which languages, frameworks, libraries, pipelines and infrastructure patterns are in use today. You can't standardize what you can't see, and the inventory alone usually reveals the worst duplications.

2. Pick the seams that hurt the most Start with the areas where inconsistency causes real incidents or delays: logging and tracing, API errors, authentication, deployment pipelines. Leave the insides of services alone.

3. Publish your first technology radar Even a simple one, with a few dozen entries, gives teams a shared reference and opens the conversation about what to adopt, try, assess and hold.

4. Build one golden path end to end Choose the most common kind of service in the company and make it possible to go from zero to production on the paved road in hours. Measure time to first deploy before and after.

5. Set up the lifecycle Create an RFC template, a community of practice, ADRs and an owner for each standard. Define how standards are reviewed, deprecated and retired, and use the process for real.

6. Measure and listen Track onboarding time, incident resolution time, adoption of shared components and developer satisfaction. When teams keep leaving the golden path, treat it as feedback about the path.