A five-person team, no dedicated enterprise architect — from 3–5-year strategy to production in 20 weeks
A multi-site EV-dealership group needed to integrate seven disconnected SaaS systems and move to an event-driven, data-driven platform with a customer portal on top. No big-bang — a three-act story: a 3–5-year strategy on the TOGAF ADM, a 1–3-year agile plan on Open Agile Architecture, and a Loop Engineering Factory that shipped each wave to production.
The baseline
What the engagement started from
- 7 disconnected SaaS systems, with a single spreadsheet as the system-of-record for stock
- 8+ manual touchpoints per deal, spread across three systems
- No dealership-level CRM — the manufacturer's view only, and it was being replaced
- No real-time analytics: no dashboards, no KPI model, stale manual stock updates
- Customer PII moving over uncontrolled WeChat, email, and spreadsheets — no DLP, no RBAC, no secrets vault (a live privacy exposure)
The team
The team: five people plus 12 specialist agents
There was no architecture office and no EA headcount to staff the 3–5-year strategy. A five-person core team — a product lead, an IT support, a finance operator, a data reporter, and a business lead — was augmented by 12 specialist agents covering architecture, UI/UX engineering, data, and security, and together they ran every ADM and Open Agile Architecture step as a controlled agent-assisted workflow, with human-in-the-loop gates at each decision point.
Agents author, humans gate
ArcKit generates the schema-validated artefacts; each gate (interview, architecture review, UAT) is where a person holds the pen. No gate passes on the model's say-so.
Standards, not headcount
The Open Group TOGAF ADM and Open Agile Architecture templates are the control — structure substitutes for a staffing office. The team consumed the workflow; it never had to build one.
One spine, three horizons
The 5-year strategy, the 3-year mid-term plan, and the 1-year delivery plan are the same document set at three zoom levels — no translation layer, no drift between them.
Act 1 · 3–5 years · Business Architect
The strategy and target state, on the Open Group ADM
The arckit-togaf-adm plugin ran the ADM as an executable workflow: Preliminary through transition. The 3–5-year business strategy and the Open Group TOGAF-standard enterprise architecture are the output of these four ADM milestones — each a schema-validated, cross-referenced artefact, not a slide deck.
Preliminary · ADM 0–A
Frame and preliminary architecture work product: scope, drivers, constraints, success criteria. The engagement charter that turns 'modernise our systems' into an addressable architecture problem.
PRIN · DISC · REQ · STKE · ADMP
Business · ADM B
Capability map and value stream: where the money leaks. 8 L1 domains, 24 L2 capabilities, maturity scored — the map that tells the board which architectural decisions unlock which strategic outcome.
BPCM · OASTR (dual-transformation canvas)
Data & Applications · ADM C
The golden-record decision: customer, stock, and deal data consolidated onto one lakehouse, with per-domain ownership and classification before a single system is retired.
DATA · APP / APP R (rationalisation)
Technology & Transition · ADM D–E
Target-state platform, event bus and API gateway, and a 20-week, three-wave transition architecture, each wave funded at gate. The 3–5-year strategy spans this delivery horizon; each wave is one Loop Factory run.
TECH · GAPA · TRANS · BORD
Act 2 · 1–3 years · Solution Designer
The agile transformation plan, on Open Agile Architecture
The 3–5-year strategy sets the destination; the 1–3-year agile plan sets the pace — and the first delivery horizon (20 weeks, three waves) is its committed first step. The arckit-oaa plugin (Open Group C208) translates it into product and sprint language — so the strategy the board approved is the same backlog the teams sprint on.
Agile strategy · 0–6 mo
The dual-transformation canvas (OASTR): legacy modernisation and greenfield innovation run in parallel, not in sequence. Every wave in the canvas carries an 'expected win' and a KPI anchor.
OASTR · OAGOV (sprint governance)
Product architecture · 6–18 mo
The transition plan becomes product backlog: epics, features, and release trains owned by stream-aligned product teams — the OAPR backlog is what the delivery loop consumes.
OAPR (epics & backlog)
Sprint mapping · 24–36 mo
ADM-Lite: the TOGAF ADM cycle compressed into 2–4-week engagement windows that map onto product releases, so architecture stays a by-product of delivery, not a document that decays.
OAAL · OASEC (security in sprint rhythm)
Delivery horizons
One strategy, three horizons — and six features delivered
The 3–5-year ADM output is held at three horizons that the five-person core team actually funds and measures: a 5-year long-term strategy, a 3-year mid-term plan, and a 1-year short-term plan. Each horizon re-bases the same document set; each re-basing is a cross-reference enrichment, not a rewrite.
5-year · long-term strategy
Target platform and capability roadmap: event-driven core, MDM and Customer Data Platform, steady-state governance and KPI model. Re-baseline at every gate: scope, maturity, and capability decisions confirmed against the target state.
G5 · horizon re-baseline → next 5-year view
3-year · mid-term plan
The 1–3-year Open Agile Architecture plan: product backlog, sprint map, release trains, and OASEC security-in-sprint across the 8 L1 domains. This is the horizon that owns the three waves and their gates G1–G4.
OAPR · OAAL · OASEC · G1–G4
1-year · short-term plan
The committed 20-week, three-wave delivery — one Loop Factory run per wave, gate-funded. This is the first-year slice of the 3-year plan: the six features below, with success criteria SC-1…SC-7 defined before the first wave starts.
TRANS · BORD · SC-1…SC-7
| Feature | Shipped in | Success criteria | Business value |
|---|---|---|---|
| 1 · Unified Customer CRM — single customer view | Wave 1 · G1 | SC-1 · SC-4 | Single customer view across 5 sites and 2 service centres; lead capture and routing automated; manual work per deal cut by 60% |
| 2 · Event-driven integration bus & API gateway | Wave 1–2 · G1–G2 | SC-7 | Seven SaaS systems decoupled behind a bus; API < 2 s, event processing < 5 s — no more point-to-point glue |
| 3 · Central inventory service (replaces the spreadsheet of record) | Wave 2 · G2–G3 | SC-2 · SC-3 | Golden inventory with audit trail and real-time dashboard; VIN consistency closed; Kevin's spreadsheet decommissioned |
| 4 · Microsoft Fabric executive dashboards & KPI model | Wave 2 · G2–G3 | SC-2 · SC-3 | Live KPIs replace stale manual stock updates; board-level visibility into every site |
| 5 · Predictive lead scoring (AI) | Wave 3 · G4–G5 | SC-5 · SC-7 | Lead scoring in production; data-quality gates enforced; shadow IT retired; governance in steady-state |
| 6 · Customer omnichannel app | Ongoing · G5→ | SC-1 · SC-4 | Unified customer app across web, WeChat and in-store channels; a growth surface for new products and services, extending the Customer 360 record |
Execution
A transition plan an ARB can actually run
The transition architecture sequences the work into three waves, each ending at a gate the Architecture Review Board passes before the next wave starts.
| Wave | Weeks | Gate | Exit state |
|---|---|---|---|
| Wave 1 · Foundation & Unified CRM | 1–8 | G1 | Event bus live; CRM live across 5 sites and 2 service centres; SalesLog + WeChat migrated; lead capture & routing automated |
| Wave 2 · Integrated Operations | 9–16 | G2–G3 | Titan DMS + MyOB integrated via the event bus; Microsoft Fabric replaces Power BI for executive dashboards; Kevin’s spreadsheets decommissioned |
| Wave 3 · AI & Steady-State | 17–20 | G4–G5 | New customer app live and website uplifted; predictive lead scoring operational; data-quality gates enforced; shadow IT retired; governance in steady-state |
Outcome
Before, and the committed target state
Each row is a success criterion (SC-1…SC-7) defined in the vision and carried into the transition plan. The right-hand column is what the plan commits to, not a result already achieved.
| Dimension | Before | Target state (committed) |
|---|---|---|
| Work per deal | ~8 manual touchpoints | ~2 touchpoints (−60%) — SC-1 |
| Stock of record | One spreadsheet: single point of failure, no audit trail | Central inventory service, real-time dashboard — SC-2 / SC-3 |
| Customer record | Fragmented across 7 SaaS systems | Single Customer 360 in the CRM — SC-4 |
| Go-live | Uncoordinated, manual rollout | Phased 6A → 6B → 6C, zero critical incidents — SC-5 |
| Integration speed | None — the systems didn't talk to each other | API under 2 s; event processing under 5 s — SC-7 |
Decisions
Five architecture decisions, each documented
ADRs capture the platform choices with their alternatives and trade-offs — the reasoning an ARB can review and defend.
Event-driven integration
Azure Service Bus + API Management as the bus and gateway. Chosen over point-to-point and M365-only: it decouples the seven systems and stays SaaS-first.
MDM / data warehouse
A central golden-inventory MDM plus warehouse, retiring the spreadsheet system-of-record and closing the VIN-consistency gap.
CRM platform
A CRM-agnostic adapter, not a locked vendor. An open-source CRM was rejected (no dealership-grade fit or support); the manufacturer view was being replaced.
Customer Data Platform
A CDP for the golden customer record and lead capture, so marketing and service share one source of truth.
Omnichannel frontend
Next.js on a unified domain with per-region subdirectories; WordPress and Angular were rejected. All PII stays on governed channels.
Act 3 · Delivery · Agentic Agile Delivery
From OOA artefacts to shipped, production software
ArcKit produces the architecture; the Loop Engineering Factory — a self-improving LangGraph state machine — delivers it. Each OAA artefact is a machine-readable input to a governed build–verify–ship loop around an OpenHands coding agent — one run per wave, gate-gated end to end.
ArcKit artefacts in
Each phase of the transition plan is one Loop Factory run. DISCOVER ingests the schema-validated ArcKit artefacts — the product backlog, strategy waves, sprint map, NFRs, security controls, and data model — auto-populating the project setup and interview without a human.
Gated, agent-driven build
BUILD delegates to the OpenHands coding agent; quality gates (security, UAT, review) decide the route forward. ARCH_REVIEW keeps a human on the approval loop; a rejection loops back to PLAN with feedback.
Ship, verify, learn
SEED_DATA and VERIFY load fixtures and run deterministic, machine-checkable acceptance tests — never a 'trust me'. SHIP deploys to production; REFLECT stores the patterns this cycle learned so the next wave starts smarter.
| Phase | ArcKit / OAA artefact it consumes | Gate |
|---|---|---|
| DISCOVER | ADMP + OAPR backlog + OAAL sprint map + strategy waves (auto-populated, no human setup) | HIL x2 |
| DEFINE | DATA / OASEC / OAA-ADM-lite advisory context + integration standards + NFR constraints | |
| PLAN | OAAL sprint map + product backlog + BPCM capabilities | |
| ARCH_REVIEW | OASEC compliance-as-code rules + ADMP baseline + open questions | HIL x1 |
| BUILD | Task breakdown + security controls, delegated to the OpenHands agent with per-task gates | gates |
| SEED + VERIFY | Fixture data + OAGOV UAT criteria + rollback thresholds — deterministic, machine-checkable | gate |
| SHIP + REFLECT | Deploy to production; arckit:health + arckit:traceability — learned patterns stored for the next cycle |
Why it stayed trustworthy
The agent is the author; the standard is the gate
When an agent writes the documents, the trust has to come from the structure, not from the model. Four mechanisms keep hallucinated content out of the artefacts.
Structured intake interview
Before the agent writes anything, every Open Group / TOGAF template field (required sections, enums, cross-references) is captured in a guided interview. An incomplete field fails the build — it is never silently hallucinated.
Build recipes with hard dependencies
The togaf-adm and oaa-full recipes encode the required phase order. The foundations (principles, requirements, stakeholders) must run first; the agent cannot skip a phase.
Schema-validated templates
Every artefact (OASTR, OAPR, OAAL, ARC-*) has a strict structure. Intake guarantees completeness before render; schema validation catches it again after.
Per-phase gates
Each phase carries its own completeness check — required sections, cross-references, consistency with the previous output. The gate is the control; the agent is the executor.
Lessons
What made it hold together
Strategy and agility, one spine
The 3–5-year TOGAF ADM set the destination; the 1–3-year O-AA plan set the pace. Both share one document set — no translation layer, no drift between the board deck and the sprint board.
Traceability, not a wall of text
Every section cites the artefact that actually defines it. v1 → v2 revisions are cross-reference enrichments, not rewrites — the doc set stays a single source of record.
Delivery is the loop
The architecture never sits on a shelf: the same doc-types an ARB reviews are the machine-readable inputs the Loop Factory consumes — one source of record, from board decision to production deploy.
The suite
Eight EyWALink products, one lifecycle
The three acts above are three of the suite: Business Architect, Solution Designer, and Agentic Agile Delivery. The other five did the rest of the work — here is where each one shows up in this engagement. Every product runs on your private cloud or on-prem, so the client kept the models, the data, and the stack — no lock-in.
EYwALINK Business Architect
Ran the 3–5-year TOGAF ADM as executable commands — scope, capability map, the golden-record decision, and the three-wave transition. The whole strategy spine in this case is its output, fundable at each gate.
Built over arckit-togaf-adm
EYwALINK Solution Designer
Turned the transition into sprint-ready canvases: the event bus and API gateway, lakehouse sizing, and the 20-week, three-wave plan the teams actually shipped against — buildable in weeks, not quarters.
Built over arckit-oaa
EYwALINK Enterprise Agent Planner
Designed the 12-agent layer: which specialist agent did what, how they handed off, and where a human held the gate — the inventory and orchestration plan that let a five-person core team run an agent org.
Built over arckit-agent-architecture
EYwALINK Agentic Agile Delivery
The self-improving LangGraph loop that turned each OAA artefact into shipped software — one run per wave, gated end to end, so delivery was a by-product of the architecture rather than a separate project.
Built over loop-factory
EYwALINK Agentic Evaluator
The four-phase E2E gate behind every 'shipped': generate realistic fixtures, drive a real browser, correlate server logs. This is the VERIFY step that kept acceptance deterministic — a build counted only when it was proven, not asserted.
Built over super web testing
EYwALINK Agentic Workflow
The per-tenant substrate the agents called: private LLM workflows, a RAG knowledge base, and MCP tooling — one instance per tenant, governed and audited like everything else.
EYwALINK Agent Mission Control
The operating plane that ran the 12 agents under multi-tenant isolation, kept a full audit trail of every action, and wired observability into the stack — how a five-person team ran and watched an agent org.
Built over multi-tenant Paperclip
EYwALINK Compounding Knowledge Graph
The hub the whole suite writes to and grounds on. REFLECT stored what each cycle learned here, so the next wave started smarter — and the next engagement starts already grounded.
Built over digital-twins
One suite, four lifecycle phases plus a knowledge hub that compounds across them:
See how the whole suite maps to a client lifecycle on the products page.
When the framework is executable, it stops being a slide deck
The full story of how ArcKit and the Loop Factory turn the TOGAF ADM and the Open Group Open Agile Architecture standards into an agent-runnable, auditable workflow that ships software.