The three transitions: architecture, delivery, adoption

When an initiative fails, a phase usually gets the blame: the architecture was too abstract, the team too slow, the business side too unwilling. In hindsight the break almost never sits in the middle of a phase. It sits at the transitions.

Transition 1: architecture → delivery

An architecture picture is handed over and the team starts building. What gets lost are the reasons. The team sees the outcome of the decisions, not the trade-offs behind them. At the first friction with reality the decision is quietly corrected — without anyone checking whether the original constraint still holds.

What helps:

• Capture decisions as short ADRs: context, options, choice, consequence. Two paragraphs are enough.
• The person who cut the design stays reachable during implementation — not as oversight, but as a counterpart.
• An event model instead of a box diagram: it describes flows, not just components, and is readable for both the business side and the team.

Transition 2: delivery → operations

The feature is done, the pipeline green, the ticket closed. That nobody knows how to reconstruct state in a failure case only surfaces in the first incident.

Production readiness is not an acceptance gate at the end but a property that grows with every slice: logging with correlation, metrics with thresholds, an alert that actually reaches someone, a runbook for the two most likely failures. Deferring this builds technical debt with compound interest.

Transition 3: operations → adoption

The most expensive transition. The system runs reliably, and the department keeps working in its spreadsheet.

Adoption rarely fails on features. It fails because the new flow takes more effort than the old one, because nobody explained why something changed, or because the person who could explain it left after go-live.

What helps:

• Plan adoption from day one, not after go-live. If the business side is in the event modeling session, there is less to convince later.
• A named person in the department who represents the system — not a role, a name.
• Measure whether the flow is actually used. Usage numbers are more honest than feedback rounds.

Ownership is the bracket

All three breaks share one cause: responsibility changes hands without anyone saying so out loud. That is why we start an initiative with an ownership map: who decides, who builds, who operates, who explains — by name, not by role. That map costs an hour and later answers the questions that would otherwise circle for weeks.

Good software does not come from executing one phase particularly well. It comes from not leaving the transitions to chance.