When building a multi-year architecture roadmap with several parallel workstreams (e.g., a new identity platform, a data-warehouse migration, and an API gateway rollout), how do you determine the sequencing order, and what technique makes the dependencies between work packages explicit?

## Where sequencing starts Dependency-driven roadmap sequencing starts from the **work packages** produced by gap analysis and asks, for every pair of packages, whether one must complete before the other can start. Those 'must-precede' relationships fall into a few recognizable categories: - **Technical dependencies** — a consuming service literally cannot call an API that doesn't exist yet, or a report can't be decommissioned until its replacement data source is populated. - **Data dependencies** — a migration must complete, and be validated, before the source system it replaces can be retired. - **Organizational dependencies** — a team must be hired, trained, or reorganized before it can own a new component, or a vendor contract must be signed. - **Business/regulatory dependencies** — a compliance deadline or budget gate that fixes a date regardless of technical readiness. These relationships are captured as a **directed graph** — each work package is a node, each 'must precede' relationship is a directed edge — which can be drawn as a dependency diagram or rolled into a Gantt-style roadmap once timeframes are attached to each node. ## Why the graph, and what it unlocks This exists because sequencing a multi-year program by intuition or stakeholder seniority routinely produces roadmaps that look reasonable on a slide but are technically impossible to execute — work gets scheduled ahead of the thing it needs, teams block on each other mid-quarter, and the program discovers its real ordering constraints reactively instead of up front. Making dependencies explicit as a graph turns sequencing into an analyzable problem: once the graph exists, standard techniques from project scheduling apply. - **Critical path analysis** walks the graph to find the longest chain of dependent work packages by duration — that chain sets a hard floor on the total program length, because no amount of parallelizing unrelated work shortens it, and every package on it is one whose slippage delays the entire program. - **Parallelization** — packages with no dependency relationship to each other can run in parallel across different teams, bounded only by the organization's actual capacity to run concurrent change without destabilizing operations. ## The trade-offs architects manage 1. **Resolving dependencies versus decoupling them.** The sequencing trade-off architects manage most is between resolving dependencies (adding coordination overhead, often bridging technology) versus decoupling them (adding design overhead, but letting teams proceed independently). For example, if package B depends on package A's new API, the team can either wait for A to ship, or agree an interface contract up front and have B build against a stub, decoupling B from A's actual delivery timeline. 2. **Enabler work packages.** A second trade-off is around 'enabler' work packages — shared platforms, identity systems, event buses — that unlock many downstream packages but deliver no direct business-visible value themselves; sequencing them early shortens the overall critical path but is a hard sell to stakeholders who want to see customer-facing progress first. ## Failure modes 1. The most common failure is an **incomplete dependency graph** — technical dependencies get captured because they show up as build errors, but organizational and business dependencies (staffing, vendor lead time, a compliance filing date) are missed, and the roadmap slips for reasons the dependency diagram never predicted. 2. A second is **ignoring the critical path** once identified — committing to an externally driven deadline shorter than the graph's longest chain, forcing scope cuts or silent slippage later. 3. A third is **over-optimistic parallelization**: the graph shows packages with no dependency on each other, but they're assigned to the same small pool of engineers, so the 'parallel' work is actually serialized by resource contention the graph didn't capture. 4. A fourth is **stale sequencing** — the graph is built once and never updated as work packages are re-scoped or delayed, so six months in it no longer reflects reality. ## A worked example An insurer rolling out a new claims platform might have three major work packages: | Work package | Dependencies and duration | |---|---| | A shared identity and entitlements platform | no dependencies, estimated 8 months | | A claims-intake microservice | depends on identity for authorization, 5 months once unblocked | | A claims-adjuster mobile app | also depends on identity, 4 months once unblocked, and additionally depends on the intake service's API | The dependency graph shows intake and the mobile app can start in parallel once identity ships, but the mobile app can't finish until intake's API exists — making identity-then-intake the critical path (8 + 5 = 13 months), with the mobile app's own 4 months absorbed inside that window. Recognizing this, the architect deliberately front-loads the identity platform — even though it has no visible feature for end users — specifically because shortening it shortens the entire program's critical path, while accelerating the mobile app would not, since it isn't the bottleneck.