Sambit Sarkar
ADR-001AcceptedArchitecture

Why I Started Documenting Architecture Decisions

2026-07-16

Problem

Most architecture knowledge is trapped inside organizations and disappears over time.

I have spent 17+ years making architecture decisions — choosing between native and cross-platform, designing offline sync strategies, evaluating build-vs-buy trade-offs, modernizing legacy systems. Nearly all of that thinking was captured in internal documents, Confluence pages, and Slack threads that no one will ever read again.

When I changed teams, the context was lost. When colleagues left, their reasoning left with them. When new engineers joined, they had no way to understand why things were built the way they were — only what was built.

This is a common pattern across the industry. Architecture decisions are made in meetings, justified in presentations, and then forgotten. The next team facing the same problem starts from scratch.

Decision

I will document architecture thinking, trade-offs, and decisions publicly using Architecture Decision Records (ADRs).

Each ADR follows a simple structure:

  • Context: What situation prompted the decision
  • Decision: What was decided and why
  • Consequences: What trade-offs were accepted
  • Notes: Lessons learned over time

The format is intentionally lightweight. An ADR should take 30-60 minutes to write, not days. The goal is to capture the reasoning, not to produce a comprehensive specification.

I will focus on decisions that are:

  • General: Applicable beyond a single organization
  • Reusable: Useful to other architects facing similar problems
  • Safe: Based on public knowledge, not proprietary information

Trade-offs

Writing takes time. Every ADR is an hour that could be spent coding, reading, or resting. This is a real cost, especially in the early months when few people will read what I write.

Public writing invites disagreement. Architecture is full of trade-offs, and reasonable people disagree. Some readers will think my decisions are wrong. That is fine — the goal is clear thinking, not universal agreement.

Consistency is hard. Starting is easy. Publishing regularly for months and years is the actual challenge. Many architecture blogs start strong and go silent after a few posts.

Expected Benefits

Clearer thinking. Writing forces you to articulate what you actually believe and why. Vague intuitions become concrete positions. Gaps in reasoning become visible.

Better documentation. If I can explain a decision clearly to strangers on the internet, I can certainly explain it to my team. The writing discipline improves all my technical communication.

Building a public body of work. Over time, a collection of 50+ architecture decisions becomes a portfolio of thinking. It demonstrates how an architect approaches problems — which is more valuable than any resume bullet point.

Giving back. I have learned enormously from architects who shared their thinking publicly. Mark Richards, Martin Fowler, Gregor Hohpe, and many others shaped how I think about software. Documenting my own decisions is one way to contribute to that tradition.

Notes

This is ADR-001 for a reason. The decision to document decisions is itself an architecture decision — it shapes everything that follows.

The hardest part is not the writing. It is choosing to start.