Resolve the question before funding the build.
The purpose of a Decision & Architecture Sprint is to replace expensive uncertainty with a grounded implementation decision. It is not an invitation to hold unlimited strategic meetings.
Which unresolved choice is expensive enough to settle?
A paid sprint earns its place when a bounded question prevents a responsible build decision. Its output should make the recommendation, rejected alternatives and remaining uncertainty inspectable.
The engagement at a glance
- When it fits
- Use when product scope, data ownership, deployment or platform choices remain unsettled.
- Bring to the work
- The business job and decision needing resolution
- Available discovery, systems, data and identity material
- Necessary client owners and their constraints
- Leave with
- Business Job Charter, options record, architecture decision, acceptance plan and proposed first milestone, as scoped.
- Decision authority to agree
- Client owners establish requirements and accept tradeoffs; Marmation develops the recommendation and its reasoning.
- Stop or reframe
- Do not repeat adequate discovery. Scope a feasibility spike when a material technical unknown needs testing.
An architecture decision you can inspect.
What approach can meet the business job within the real constraints?
Record the required outcome, data and identity boundaries, operating constraints and evidence available. Agree the question and timebox before the work begins.
- Recommendation
- State the preferred option and the requirements it satisfies.
- Alternatives rejected
- Explain the tradeoffs that ruled out the other feasible approaches.
- Unresolved uncertainty
- Name the assumptions still requiring evidence and their effect on scope.
- Next commitment
- Propose the first build milestone and how its acceptance would be evaluated.
Could another decision-maker act on it?
The record should explain what is recommended, why the alternatives lost and what remains uncertain. If it cannot support a decision or a concrete implementation scope, the engagement has not yet produced its intended output.
The full argument for a bounded architecture decision
For CIO, CTO, CPO, COO
The situation behind the request
A company has budget for an AI initiative, but data ownership, model deployment and product scope are unsettled. Three teams recommend different platforms and nobody has yet defined what must be true for a successful first version.
Where the obvious solution falls short
A rushed estimate will hide assumptions. An enormous transformation roadmap may take too long and still leave the real architectural decision open.
How we would approach the work
Agree the question and timebox. Interview necessary owners, review constraints and available technical evidence, compare feasible options and produce a decision record and proposed first build milestone.
What the engagement may include
- Business Job Charter and measurable success definition.
- Existing systems, data and identity map; risks and dependencies.
- Build/buy/extend options with cost and implementation considerations.
- Architecture decision, acceptance/evaluation plan and implementation proposal.
The choices worth making explicitly
If the client has enough discovery and architecture material, do not resell it. If a technical unknown matters, explicitly scope a feasibility spike instead of claiming the answer is known.
What we would test before calling it ready
Deliverables are reviewable and actionable. Client should understand what is recommended, why alternatives lost and what remains uncertain.
A sensible first step
Share the problem, systems involved and the decision needing resolution. We can determine whether a paid sprint is appropriate.