Solution architecture is the least-photographed part of software work. There are no screenshots to share, no keystrokes to demo. And yet — of every failed enterprise project we’ve ever inherited or reviewed, more than three-quarters trace back to a decision (or a non-decision) at the architecture stage.
This is the checklist we run before any enterprise engagement crosses the six-figure line. Twenty-five items across five categories. If you can answer each in one paragraph, you have an architecture. If you can’t, you have a hope.
Category 1 — Business context
1. Why does this project exist right now?
Not “digital transformation.” Not “modernisation.” The specific business event or pressure that made this quarter the quarter this project has to happen. Regulatory deadline? Customer defection? M&A? Support end-of-life? Board mandate?
If nobody can name the specific trigger, the project has no defensible priority and will lose funding as soon as budget season pinches.
2. What business decision would this system change?
Every enterprise system either enables a new decision, speeds an existing one, or reduces the cost of a repeated one. If you can’t finish the sentence “once this ships, we will be able to ___ that we can’t today,” the system doesn’t have a purpose.
3. Who is the executive sponsor, and what do they lose if this fails?
Not “supports.” Loses. Reputation, budget, bonus, position. If nobody at the executive level has skin in the game, the project will not survive its first stakeholder disagreement.
4. What’s the honest budget, and does it include year 1–3 operating costs?
Sticker cost is only ~50% of five-year TCO for most enterprise systems. If the budget covers implementation only, someone is going to be surprised in year two when hosting, licensing and BAU support hit.
5. What’s the timeline pressure, and is it real or negotiable?
A real deadline (regulatory, product launch, contract renewal) shapes architecture — you optimise for risk reduction and time-to-value. A soft deadline shapes it differently — you can afford to sequence for longer-term architectural health.
Category 2 — Users and domain
6. Who are the primary users, and how many are there?
Not personas. Named user groups with headcounts. “1,200 field engineers, 40 dispatchers, 8 regional managers, unlimited read-only executives” is useful. “Various stakeholders” is not.
7. What do the users do today, and what will they do differently after this ships?
Process, tools, workarounds, spreadsheets. The change has to be described in terms of the current-state workflow, not aspirational future-state. If the current-state answer is “we don’t really know what they do,” you’re not ready to build.
8. What’s the domain model, in one paragraph?
The five to twelve core entities and how they relate. Written in plain sentences, not ERDs. If the domain can’t be described in a paragraph, either the domain is genuinely complex (which is fine but changes scope) or nobody has understood it yet (which is not fine).
9. What are the domain invariants?
The rules that must never be violated. “Every invoice must belong to a purchase order that has been approved.” “A shipment cannot leave a warehouse without a signed inspection.” These are the constraints the system has to enforce and — critically — has to enforce even when data is created outside the system.
10. Where is the domain expertise, and can we get access to it?
Every enterprise project needs a subject-matter expert who can answer domain questions in hours, not weeks. Identify them by name in scoping. If they’re not available for regular working sessions, scope shifts to “we’re going to be wrong about the domain and iterate expensively” — which is a real strategy but has to be sized accordingly.
Category 3 — Data and integration
11. Where does the data come from, and where does it need to go?
An inventory of upstream sources and downstream consumers. Systems by name, with owners. Interfaces are not free — every one is a project inside the project.
12. What’s the data volume today, and what’s it projected to be in three years?
Rows of primary entities. Storage per row (rough). Growth rate. This drives the choice between a normal relational schema, a partitioned schema, or a full data platform. Getting this wrong at design time is expensive to unwind.
13. What’s the master data story?
Who owns the source of truth for each core entity? If two systems both claim to own “Customer,” you have a data-governance problem that will express itself as an application bug six months in. Solve it now, or budget for the pain.
14. What’s the data quality baseline?
If the source data is clean, the migration is a one-week project. If it’s a mess of duplicates, format drift and orphaned records — the data-cleansing phase is often 30% of total programme effort. Sample the data before scoping, not after.
15. What’s the failure mode if a downstream integration is offline?
Retries? Queue-and-forward? Circuit-breaker? User-visible degradation? Every integration answers this differently and the answers cost different amounts to build. Enumerate.
Category 4 — Technology and delivery
16. What’s the target platform, and why?
Cloud (which one)? On-prem? Hybrid? RISE / private cloud? The answer usually pre-exists (corporate standard, existing licensing, compliance) but has to be surfaced explicitly. Fighting a target platform mid-programme is a career-limiting move.
17. What are the non-functional requirements — with numbers?
Performance targets. Availability targets. RTO/RPO. Concurrency. Peak-vs-average load. Number of concurrent users. These drive infrastructure choices and cost. “Fast” and “reliable” are not requirements — they’re feelings.
18. What’s the security and compliance posture?
Regulatory constraints (HIPAA, PCI, DPDP, GDPR, sector-specific). Data-residency requirements. Auditability requirements. Encryption in transit, at rest, in memory. Authentication and authorization model. Get these on the table before technology choices, not after.
19. What’s the team, and what’s the team’s skill profile?
Named individuals or job roles, with skill assessments. If the target architecture requires skills the team doesn’t have, either budget for hiring or pick a different architecture. Don’t quietly assume the team will “pick it up.”
20. What’s the delivery model — waterfall, agile, or hybrid?
For programmes over 6 months, some form of phase-gated hybrid usually beats either extreme. Pure agile struggles with year-long enterprise programmes. Pure waterfall struggles with any programme where scope is genuinely uncertain. Pick and document.
Category 5 — Risk and durability
21. What are the top three risks, and who owns each?
Not “risks and issues log.” Three specific risks that could kill the programme. Each with a named owner and a mitigation. If the top-three list is longer than three items, prioritisation hasn’t happened.
22. What decisions have not yet been made, and when do they need to be made by?
Every enterprise project has 5–15 outstanding decisions at the start of design phase. Explicit decision tracking (with dates) is the difference between a controlled project and a chaotic one.
23. What’s the architectural runway — the assumptions that hold true for 3 years?
Cloud provider. Programming language. Framework version. Auth model. Database engine. If any of these are likely to change inside the programme lifecycle, treat them as risks, not assumptions.
24. What’s the maintenance model post go-live?
Which team owns it? How is on-call structured? How are bug fixes prioritised against new features? What’s the release cadence in year one? Systems that are architected without a maintenance model become tech-debt hostages within 18 months.
25. What’s the exit strategy for the technology choices?
You don’t build to exit — but you architect knowing that in five years, someone might want to replace this system. Loose coupling between UI, API, and data layer preserves options. Deep vendor lock-in destroys them. Keep options as a design principle, not an accident.
The three-page architecture document
The output of running this checklist is a three-page document that lives at the front of every project. Not a 200-page enterprise architecture opus — three pages.
- Page 1 — Business context and users (questions 1–10).
- Page 2 — Data, integration and technology (questions 11–20).
- Page 3 — Risks, decisions, durability (questions 21–25).
Everyone on the project reads this. Everyone can find it. When someone new joins, this is what they read on day one.
If a project has been going for two months and doesn’t have this document, that’s a signal — often a leading indicator of scope drift and stakeholder confusion.
Where solution architecture goes wrong
Three patterns we see repeatedly:
Pattern 1: architecture-as-diagram. The solution architect draws a beautiful C4 diagram and calls it architecture. The diagram is fine. But it doesn’t answer any of the twenty-five questions above. It’s cartography, not architecture.
Pattern 2: architecture-as-technology-selection. “We chose Kubernetes, Kafka, PostgreSQL and Next.js.” That’s a tech stack, not an architecture. Same technologies solve very different problems depending on how you use them.
Pattern 3: architecture-as-ceremony. A 40-page architecture document nobody reads, updated by nobody, contradicted by the actual system within a quarter. Length is not depth. If the team can’t tell you what’s in the document, the document has failed.
The architect’s actual job
The solution architect on an enterprise project has three jobs, in decreasing frequency:
- Make the trade-offs visible. Not decide them alone — make them visible to the sponsor, the engineers, the users. Trade-offs stated in plain language, in plain sentences. Never in bullet points that hide the choice.
- Hold the line on invariants. Loose coupling, clean interfaces, boring choices, security posture. When someone wants to shortcut, the architect is the person who says “yes but if we do that, here’s the cost in year three.”
- Sequence the work. What must be decided first. What can be parallelised. What can be deferred. Sequencing is often the difference between a project that hits budget and one that doesn’t.
If your solution architect is drawing diagrams full-time and not doing these three things, you have a diagramming resource, not an architect.
What we bring to enterprise engagements
We staff senior architects on every enterprise engagement over roughly $200k. Not to draw the diagram — to answer the twenty-five questions and hold the line during delivery. It’s the most cost-effective role on the project in every engagement we’ve measured.
If you’re at the start of an enterprise project and want a second opinion on the architecture — or a first opinion, if you don’t have one yet — we’re happy to sit in the conversation. One senior architect, a two-hour working session, and a summary document. That’s usually enough to tell whether a project is set up to succeed or set up to struggle.
Related: API-first, UI-first, or database-first? covers the sequencing question in more depth; ABAP to S/4HANA — a practical migration playbook is the same architecture lens applied to a specific engagement type.
