Six weeks, one mandate: architecture decisions when the date is not negotiable

There is a particular kind of work in government where the date arrives before the requirements do. An executive priority lands, a launch is announced, and the architecture conversation starts with a number of weeks rather than a set of options.

I led one of these end to end: an executive-priority meeting-request system taken from requirements to production in six weeks, including architecture decisions, API contracts, implementation guidance, deployment, and production readiness. I am currently holding a much larger version of the same problem: a Premier-mandate initiative working to a fixed launch date.

Both taught the same lesson. Speed came from deciding earlier which decisions were irreversible.

Sort by reversibility

Under time pressure, most teams triage by importance. That is the wrong axis, because everything looks important when the date is public.

Sort by reversibility instead. A choice you can change in a sprint (a component library, a page layout, a field name) can be made quickly and badly, and corrected. A choice you cannot change without a migration, a re-accreditation, or a new security review is a different category entirely: hosting and data residency, identity, the integration contract with systems you do not own, and the information-protection posture.

The irreversible set is small. On the six-week system it was perhaps four decisions. Spending two of the six weeks getting those four right is what makes the remaining four weeks parallelisable.

Write the API contract before the implementation plan

The artefact that pays for itself fastest in a compressed timeline is the API contract, and it should exist before anyone agrees how the thing will be built.

A contract lets front-end, back-end, and integration work start on the same day instead of in sequence. The most expensive kind of rework is two teams discovering in week five that they assumed different shapes, and a published contract turns that into a conversation in week one. It is also the artefact a reviewer can actually assess, which means the governance conversation happens against something concrete rather than against a diagram.

Write it, publish it, and treat changes to it as decisions with owners.

Deployment is a week-one problem

Teams under pressure defer deployment because it feels like the end of the work. Deployment is the constraint that determines whether the end of the work exists at all.

Standardising the delivery path (GitHub Flow, merge queues, staging gates, quality-assurance approval, rollback-ready deployments) looks like process overhead when the clock is running. It buys time back. A rollback-ready deployment is what lets you ship on a date without requiring that the release be perfect. It converts a binary, terrifying launch into a sequence of small, recoverable ones.

If you have to choose between a feature and a rollback path, choose the rollback path. You will ship the feature the following week.

What you must not trade

Compressed timelines create pressure to defer exactly the things that cannot be deferred. The honest list of what stays non-negotiable:

• Security posture. The hosting and integration patterns are set at the start, or they are set by an incident.
• Privacy obligations. These are statutory. A date does not amend a statute.
• Accessibility. Retrofitting it costs more than building it and is usually done badly.
• The decision record. Under pressure the reasoning is what evaporates first, and it is what the next team will need most.

Everything else is genuinely negotiable: scope, sequencing, polish, the number of user journeys in release one. Being explicit about which list an item is on is most of the job.

Sequencing is the architecture

For a mandate with a fixed date, the architecture deliverable people expect is a target-state diagram. The deliverable that actually determines success is a sequence: what must be true by when, which pieces can proceed in parallel, and which dependencies sit outside your control.

Dependencies you do not own are the real risk. On tribunal and case-management work, including the platforms now running in production on the Alberta Digital Service Platform, the technical build was rarely the critical path. Alignment across ministries, platform service availability, and integration with systems owned elsewhere were. Those need to be surfaced in week one, with named owners, or they will surface in the final fortnight with none.

The uncomfortable part

A fixed political date is not a technical constraint, and pretending otherwise is the fastest way to lose credibility with the people who set it. The date exists for reasons that are legitimate and not yours to relitigate.

What you can do is be precise about consequences. “We can hold the date” and “we can hold the date with this scope, this sequence, and this decision made by Friday” are different sentences, and only the second one is architecture.

Delivering fast is a skill. Delivering fast without trading away security, privacy, or governance posture is a different discipline, and it is mostly about deciding early, writing it down, and refusing to be vague.