Context
When I first opened TOGAF, I got stuck on a basic problem — there's no clear starting point. Every section references another. Every process assumes a governance structure most teams don't have. Same problem was with Zachman. By the time you understand them well enough to follow, you've spent a lot of time. And even then — it's too heavy for most real projects.
Over the years of my work as an architect I accumulated notes: what to do on a new project, what to check before moving to the next phase, where things typically go wrong. Templates I kept reusing. Checklists I open on day one. At some point I had enough material to structure it into something I could share. I called it D3.
What is D3?
D3 is a lightweight architecture delivery framework built around three phases:
Discover → Design → Deploy
Each phase has a clear goal, concrete steps, a list of common pitfalls, and a definition of done checklist. The checklist is the key part — you don't move to the next phase until every item is checked. No guessing whether you're ready. No open unknowns quietly becoming risks later.
It works for solo architects and teams. Startups and enterprises. It doesn't require certifications, governance boards, or months of setup — just a clear problem and a structured way to work through it.
The three phases
Discover — understand the actual business problem, not just the stated request. Agree scope with the right people, capture requirements, document assumptions and open questions. The goal is enough clarity to design with confidence, not perfection.
Design — translate what you learned into a validated architecture. Always present at least two options with trade-offs, never a single answer. Share early — a rough diagram reviewed now is cheaper than a finished document reviewed late.
Deploy — deliver and hand over. This phase ends only when the stakeholder can operate the system independently. Not when the code is deployed. Not when documents are sent. When ownership has actually transferred.
Project types — the framework scales with you
D3 has three project types based on the size and risk of your engagement:
| Type | Duration | Goal |
|---|---|---|
| Advisory | 3–4 weeks | Strategic direction and high-level design |
| Pilot | 2–3 months | Validated prototype or workload integration |
| Delivery | 6+ months | Full production system with operational handover |
Each type is cumulative — Pilot includes all Advisory outputs, Delivery includes all Pilot outputs. You pick the type that fits the engagement, the framework adjusts depth accordingly.
What's inside each phase
Beyond the steps themselves, each phase includes:
- Common pitfalls — specific mistakes I've made or seen, written plainly. Things like treating the stakeholder's request as the problem, presenting one option instead of two, or deprioritizing CI/CD until the end.
- Definition of done checklist — a concrete list of items to check before moving forward. The rule: don't proceed with open unknowns.
- Internal tools — working documents for the architect (assumptions log, open questions log, stakeholder map) kept separate from client-facing deliverables.
- Session guides — how to run discovery, design review, and handover sessions. Before, during, and after.
Who it's for
Junior or senior — a new project can still leave you unsure what to do first. D3 gives you a clear action plan from day one.
It's aimed at architects, tech leads, and engineers who end up designing systems regardless of title. It's not a methodology or a certification path. It's a structured way to go from a stakeholder's pain point to a delivered, handed-over system — and always know what phase you're in.
The framework is free and open: d3-architecture-framework.vercel.app
I'd love to know if it's useful — or where it doesn't fit your experience.
Top comments (0)