Most IT investment proposals have the same problem. They are either too thin to support a good funding decision, or they contain so much detail that they are effectively doing the architecture work that should come after funding is approved, not before.
Business Outlines — specifically Solution Overviews — are the AMBIT answer to this problem. Getting them right is one of the most practically impactful skills an architect can develop.
A Solution Overview is the investment case document for an IT initiative. It sits between the strategic direction (Business Visions) and the detailed design (IT Designs). Produced during Initiation and approved by the Investment Forum, its purpose is to answer one question: is this initiative worth funding? That question has two dimensions: business value and technical feasibility. The document needs to answer both in business language, not technical language.
The ten sections
- Business context — why does this need doing now? What business problem or opportunity does it address?
- Current state — what does the current landscape look like in the relevant area? IT Landscape content translated into business terms, not a technical diagram.
- Proposed solution — what will be built, at a conceptual level accessible to non-technical readers?
- Future state — what will the business environment look like after delivery? Before/after framing, in business terms.
- Business benefits — what specific outcomes will the organisation achieve? Quantified where possible.
- Cost and timeline — indicative, not committed. Enough precision to support a funding decision, not a project plan.
- Risks — the top three to five risks, stated clearly with their mitigating factors.
- Strategic alignment — which Principles does this comply with? Which Roadmap entries does it address? Which Business Capabilities does it strengthen?
- Technical concept — a brief explanation of the proposed solution approach for a technically literate reader. One page maximum.
- Sourcing recommendation — buy, build, or outsource, with rationale.
Over-specification is the most common failure mode. When a Solution Overview contains integration architecture diagrams, API specifications, or detailed user stories, the architect has produced design work that belongs in an IT Design — work that should only be done after funding is approved, because it is too expensive to invest in before knowing whether the initiative will proceed.
Under-specification is less common but equally damaging. A Solution Overview with no technical concept, unrealistic cost estimates, or a strategic alignment section that simply says “aligns with digital transformation strategy” has not done enough work to support a good investment decision.
The calibration question is: does this section help the Investment Forum decide whether to fund? If yes, it belongs. If no, it doesn’t.
Related artefact types
Not every initiative begins with a full Solution Overview. The typical sequence is:
- Initiative Proposal — a brief statement of a proposed initiative for early-stage portfolio consideration, before enough analysis has been done.
- Options Assessment — used when multiple credible solution approaches exist and the organisation needs to evaluate them explicitly before committing to one. Compares typically two to four options against business fit, technical risk, cost range, time to value, and strategic alignment.
- Solution Overview — the full investment case, once the approach is selected.
- IT Design — the detailed specification, once funding is approved.