A solution pack is a design plus its questions
Not a template. A solution architecture, the design decisions needed to make it real, and therefore the questions that must be asked to make them.
Enterprise architecture · From design workshop to signed-off design pack
The design workshop is the product. Everything else should follow from it.
Architecture Engine takes a solution architect from a customer briefing through to an approved design pack. The architect runs the workshop in front of the portal, the questions come from a chosen solution pack, the answers are captured as needs, and the proposal, requirements, high-level design and detailed designs are generated from them — each reviewed, each traceable back to the need it came from.
Status. Prototype. Being built out area by area with a starter catalogue of Red Bear-curated solution packs.
The business problem
The understanding captured in a design workshop is the most valuable thing an architect produces, and it is normally thrown away.
An architect runs a workshop, fills a notebook, and then writes a proposal from it. The proposal is rewritten as a statement of work, which is rewritten as a functional specification, which is rewritten as a high-level design. Each rewrite loses something, and no two documents quite agree.
The decisions made along the way — why this pattern, why not that one, what was assumed because nobody could answer — exist nowhere. When the project goes wrong eighteen months later, the reasoning cannot be recovered.
And the review process is email. A document goes out, comments come back in five formats, and the architect reconciles them by hand while the proposal's commercial assumptions quietly go out of date.
The platform
Five stages, one traceable thread from need to design
Positioning
What makes it different
Needs become requirements, traceably
What the customer says is a need. Requirements, user stories, assumptions and dependencies are derived from needs, and every one points back at the need it came from.
Unanswered questions become assumptions
The question list is prioritised rather than capped. What the architect does not get to is carried forward as a tracked assumption, to be signed off or to adjust scope.
Every decision gets the four questions
What happens if we do, if we do not, what will not happen if we do, and what will not happen if we do not — drafted by the engine, refined by the architect, with a reversibility rating and a cost of delay.
Reviewers see only their part
Commercial reads the whole statement of work; the security architect reads the security design. Nobody is sent four hundred pages to find their twelve.
01
Workshop capture — The architect works in front of the portal, not a notebook
A briefing arrives, the architect picks a solution pack or takes the engine's suggestion, and the portal presents the questions to put to the customer. The answers are captured as needs, in the customer's words.
The problem. Workshop output lives in notes, and the quality of a design depends on how good that particular architect's notes were on that particular day.
| Functionality | What problem it solves | Impact on the business |
|---|---|---|
| Pack-driven questionsThe chosen solution pack supplies the questions, prioritised rather than capped at a fixed number. | Question lists are written from memory, so coverage varies by architect. | The weakest workshop in the organisation gets the same question set as the strongest. |
| Pre-workshop suggestionFrom a short briefing, the architect picks a pack or the engine proposes good-fit packs with a rationale for each. | Choosing the wrong starting architecture costs a whole workshop. | The choice is made deliberately, with the reasoning recorded. |
| Structure that matches the workCustomers, opportunities, projects, then workshops and streams — a stream being a workstream such as data, security or UI, each with its own packs and its own SME lead. | A real solution is several designs at once, and flat tools force them into one. | Each stream is led by the person who should lead it. |
| Three marks on any answerAn answer can be flagged as having a document behind it, as an assumption, or as a customer dependency. | Assumptions and dependencies are remembered, not recorded, and surface as scope arguments later. | They are tracked from the moment they arise and carried into every generated document. |
Business value
- Consistent coverage regardless of who ran the workshop
- Assumptions and dependencies captured at source
- Multi-stream designs held in one structure
How it connects
Needs captured here are the only input to analysis. An excluded component automatically becomes a customer dependency.
02
Analysis and requirements — Needs in, requirements out, with the thread intact
At the end of a workshop the architect triggers analysis. The engine derives requirements, non-functional requirements, user stories, use cases, assumptions, dependencies, risks and constraints from the captured needs, and the architect reviews and edits each before accepting it.
The problem. Turning customer statements into structured requirements is slow, and it is where consistency between architects breaks down first.
| Functionality | What problem it solves | Impact on the business |
|---|---|---|
| Derived, then reviewedNothing is accepted automatically. The architect edits every generated artefact before it enters the design. | Generated requirements that nobody checks are a liability dressed as a time saving. | Speed on the draft, judgement on the accept. |
| Traceable in both directionsEach requirement points back at the need it came from; each need shows what was derived from it. | When a requirement is challenged, nobody can say where it came from. | Scope arguments are settled by looking rather than remembering. |
| Assumptions reviewed with the customerBefore a statement of work is generated, the architect is prompted to walk the assumptions through with the customer, who signs off or the scope changes. | Assumptions become disputes at the point of invoice. | The conversation happens while changing scope is still cheap. |
Business value
- Requirements consistent across architects
- Every requirement traceable to a customer statement
- Assumptions settled before commercial commitment
How it connects
Accepted requirements are what every generated document is built from, and what the review standards are checked against.
03
Design pack generation — Proposal, then requirements, then design — in that order, on purpose
Generation runs through approval gates: proposal, then requirements document, then solution architecture, then anything else — statement of work, detailed designs, test strategy, implementation plan, dependencies document. Word and PDF for everything; a summary deck for the proposal and the architecture.
The problem. Documents written in parallel contradict each other. Documents written from scratch each time lose the decisions made in the last one.
| Functionality | What problem it solves | Impact on the business |
|---|---|---|
| Gated sequenceEach stage is drafted from the accepted requirements, decisions and pack templates, and reviewed before the next begins. | A detailed design built on an unapproved architecture is work done twice. | Rework is caught at the cheapest stage it can be caught at. |
| Vendor reference architecturesPatterns harvested from Microsoft, Amazon, Google, Anthropic and OpenAI, with the architectural principles a design must follow selected at organisation and project level. | Generated designs drift toward whatever the model saw most of. | Designs are shaped against principles the organisation chose. |
| Regeneration applies changesAfter the customer sees the proposal and architecture, their feedback prompts changes that flow into the downstream artefacts — applied to the existing design, never recreated from fresh. | Regenerating from scratch discards every decision made since. | The design evolves instead of restarting. |
| A dependencies document for the customerA checklist of everything the customer must provide before work starts, with instructions, owners and a ten-day clock that escalates to the executive sponsor. | Projects start and then stall waiting for access nobody asked for in writing. | The prerequisites are a document with a deadline, not an assumption. |
Business value
- Documents that agree with each other
- Designs shaped by chosen principles
- Customer prerequisites tracked from day one
How it connects
Generation consumes requirements and decisions, and produces what the review workflow checks.
04
Commercials — Price the design, and see what the discount does to the margin
Rate cards, margin and discount dials, non-labour cost estimates, multi-currency with a live exchange feed, and a proposal that expires in thirty days so it has to be refreshed rather than quietly honoured.
The problem. Pricing is a spreadsheet beside the proposal. The two disagree, discounts are given without anyone seeing the margin effect, and a six-month-old proposal is honoured at rates that no longer hold.
| Functionality | What problem it solves | Impact on the business |
|---|---|---|
| Rate cards with an ownerAn organisational default plus customer-specific cards where a framework exists; the engine picks the right one. The Chief Architect owns them. | Rate cards live in a finance folder and are out of date by the time they are used. | The price comes from the card that actually applies. |
| Discount within a trust dialEach lead architect has a discount limit set by the Chief Architect. Beyond it, approval is required. | Discretion on price is either unlimited or requires a meeting. | Latitude is explicit, and exceeding it is a route rather than a refusal. |
| Margin floor warns, does not blockThe engine warns when a discount pushes a phase below the minimum margin, and lets the business proceed anyway. | A hard block means the deal gets priced outside the tool. | The decision to take a loss is made deliberately and recorded. |
| Rate locked at issueThe exchange rate is fixed when the proposal is issued, and the thirty-day term returns it to the lead architect to refresh. | Currency movement silently erodes margin on a proposal left open. | An expired proposal is reissued at today's numbers. |
Business value
- One number in the proposal and the model
- Discretion on price made explicit
- Stale pricing cannot be honoured by accident
How it connects
Commercial decisions — payment terms, milestones, invoicing — route to a commercial approver and are recorded in the decision log like any other.
05
Review and sign-off — Structured feedback, from the right reviewer, before they even open it
The Chief Architect sets which reviewer roles review which artefact types. Reviewers get only their relevant sections, raise structured feedback against a page or section with a severity, and can interrogate the document conversationally. Automated standards checks run before the document reaches them.
The problem. Review is email and goodwill. Feedback arrives as prose, severity is implied by tone, and the approver who matters is on holiday.
| Functionality | What problem it solves | Impact on the business |
|---|---|---|
| Standards checked firstEach reviewer type defines checks the engine runs automatically — ISO and NIST compliance, defence-in-depth patterns — and the resulting report goes to the reviewer and to the lead architect. | Reviewers spend their time finding things a checklist would have caught. | The architect fixes the obvious before a human is asked to look. |
| Severity that means somethingCritical blocks progress, moderate must be fixed, warning flags a risk, informational requires no change. | Prose feedback leaves the architect guessing what is mandatory. | The rework list is unambiguous. |
| Scoped to the reviewerCommercial reads the whole statement of work, the project manager reads project and resourcing, detailed designs go to the nominated SME. | Reviewers sent everything read nothing. | Review quality holds because the ask is proportionate. |
| Routed around absenceEach approver has a nominated fallback, and the engine checks their out-of-office status before sending. | A document sits unread for two weeks because its approver is away. | The chaser goes to someone who is actually there. |
| Interrogate the documentReviewers can ask where the security risks are, whether it meets a standard, or what the gaps are. | Finding the issue in a two-hundred-page design is the slow part of reviewing it. | Reviewers spend their time judging rather than searching. |
Business value
- Obvious defects caught before human review
- Unambiguous rework lists
- Approvals that do not wait on one person's diary
How it connects
Review feeds the lessons-learned record, and proposed changes to a principle or a pack go to the Chief Architect.
What it looks like
The screens, drawn to the current specification
Drawn from the specification rather than captured from a running build, and each is labelled as such in its own frame. Showing you a prototype screen built to a superseded model would be worse than showing you a drawing of the right one.
Capturing what the customer actually said
Workshop · Data design · Question 7 of 23Conceptual interface
Where does the customer's master data live today, and who owns changes to it?
Three systems. Finance owns the customer master in Oracle; sales keeps a parallel list in the CRM; the branch network maintains its own spreadsheets. No single owner.
A document will be suppliedThis is an assumption✓This is a customer dependency
Marked as a dependency: tracked from here into the proposal, the statement of work and the dependencies document, with a ten-day clock after kick-off.
Analysis · derived from workshop 3Conceptual interface
Need, in the customer's words
“No single owner for customer master data.”
→
NFR-11A single system of record for customer master dataaccepted
REQ-28Reconciliation of three existing customer lists at migrationedited
ASM-04Finance will be the accountable data owner post-go-liveassumption
DEP-09Customer to nominate a data owner before design sign-offdependency
Turning it into a design pack
Design pack · Gulf Industrial · generationConceptual interface
1
Proposal
Approved · 3 Oct
2
Requirements
Approved · 7 Oct
3
Solution architecture
In review · 2 of 4 reviewers
4
Detailed designs
Locked until the architecture is approved
5
Statement of work
Locked · assumptions review outstanding
Review · Solution architecture v2Conceptual interface
Critical§4.2 NetworkNo private endpoint on the data tier. Cannot proceed to build.Security architect
Moderate§6.1 IdentityConditional access policy does not cover guest reviewers.Identity architect
Warning§3.4 HostingSingle-zone tier accepted; note the availability implication.Peer architect
Informational§9 PlanConsider sequencing migration after the quarter end.Project manager
Automated standards checks run before any of this reaches a human, so reviewers spend their time judging rather than finding.
Pricing it
Commercials · Gulf IndustrialConceptual interface
Rate cardGCC framework · customer-specific
CurrencyAED · rate locked at issue
Proposal valueAED 1,840,000
Discount applied9% · within your 12% limit
Warning. Discovery phase margin falls to 17%, below the 20% floor set by the Chief Architect. You may proceed.
Valid 30 days. After that it returns to you to refresh against today's rate card and exchange rate.
Evidence
What the first engagement measures
Architecture Engine is a prototype and has no published results. These are the measurements a first deployment produces, taken from the organisation's own workshops and reviews.
| Measure | How it is produced |
|---|---|
| Time from workshop to proposal | Measured from workshop close to the proposal reaching the customer |
| Rework after review | Critical and moderate findings per artefact, by reviewer type, over time |
| Assumption conversion | Proportion of assumptions resolved with the customer before the statement of work |
| Dependency ageing | Customer prerequisites outstanding past the ten-day mark |
No values are quoted here because none have been earned yet. We publish no benchmark we cannot reproduce from a live engagement.
Read further
11 documents on this product
Every one is a working draft, and says so. No form, no email address — the link downloads the PDF.
- White paper: Enterprise Ontology for Federated OrganisationsEOM-WP-01 · v0.1
- White paper: Enterprise Ontology for Inter-Entity AutomationEOM-WP-02 · v0.1
- White paper: Enterprise Ontology Maturity and BaseliningEOM-WP-03 · v0.1
- White paper: Enterprise Architecture Roadmap HarmonisationEOM-WP-04 · v0.1
- White paper: Enterprise Architecture Decision IntelligenceEOM-WP-05 · v0.1
- Data sheet: Suite overviewEOM-DS-00 · v1.0
- Data sheet: Knowledge and evidenceEOM-DS-01 · v1.0
- Data sheet: Understanding the enterpriseEOM-DS-02 · v1.0
- Data sheet: AnalysisEOM-DS-03 · v1.0
- Data sheet: Decisions and recommendationsEOM-DS-04 · v1.0
- Data sheet: Roadmap and governanceEOM-DS-05 · v1.0
Next step
Start with one solution pack and one real opportunity
The fastest way to see whether this fits is to run a live design workshop on it with a single pack, and compare what comes out against what your architect would have written by hand.
One pack, tuned to you
A Chief Architect tunes a Red Bear-curated pack to the organisation's capabilities, maturity and house style before it is used.
A real workshop
Not a demo dataset. One genuine opportunity, run in front of the portal.
Compare the output
The generated requirements and proposal against what the architect would have produced unaided.
Keep the decision log
Whatever you decide about the product, the decision record from that workshop is yours.