Enterprise Architecture Starter
Executive Summary
This plan proposes the first 90 days of enterprise architecture work for Calab.ai. It is intentionally lightweight and is designed to improve decision quality, reuse, and business-to-technology alignment without creating a heavyweight EA practice.
The recommended starting point is:
- establish architecture principles
- validate a first-pass business capability map
- identify platform bets
- pilot the method in one value stream
- introduce a small set of required artefacts and one lightweight review point
Why Start Here
The current organisational model already provides Guild, Value Stream, Product, and company governance structure. The immediate problem is not missing hierarchy. The immediate problem is weak translation between:
- business and sales intent
- delivery and solution design
- platform reuse
- product evolution
- cross-team ownership
This plan focuses on those gaps first.
Success Criteria
After 90 days, this effort should demonstrate:
- faster and clearer architecture decisions
- better alignment between business intent and technical design
- at least one visible platform reuse opportunity with an owner
- a repeatable set of lightweight architecture artefacts
- one value stream pilot that proves the approach is practical
First-Pass Capability Map
This is a draft business capability map based on the current handbook structure and should be validated with leadership and Guild leads.
Visual View
The diagram below groups the draft capabilities into a practical enterprise view. It is intended to show how the capabilities cluster, not to imply reporting lines.
Capability Reference Table
| Capability | Description | Primary Organisational Anchors |
|---|---|---|
| Strategic Direction and Governance | Define company direction, policy, decision rights, and structural controls | Leadership Team, Executive Guild |
| Commercial Development and Growth | Generate demand, shape opportunities, and grow client/product revenue | Sales Guild |
| Opportunity Discovery and Solution Shaping | Turn client or market needs into viable solution and product options | Sales Guild, Delivery Guild, Technology Guild |
| Client Delivery and Engagement Management | Execute consulting and solution delivery outcomes reliably | Delivery Guild, VS02 |
| Product Mgmt | Define product strategy, roadmap, and prioritisation for reusable offerings | Product Owners, Delivery Guild |
| Platform and Solution Eng | Design and evolve shared platforms, solution patterns, integrations, and engineering standards | Technology Guild, Products |
| Service Operations and Reliability | Release, support, monitor, and restore services and platforms | Technology Guild, VS03, VS04 |
| Security, Risk, and Compliance | Manage cross-cutting risk, controls, information security, and assurance obligations | Executive Guild, Technology Guild |
| People and Capability Development | Recruit, develop, and evaluate capability across Guilds and roles | Administration Guild, VS01 |
| Knowledge and Decision Management | Maintain standards, decisions, reusable guidance, and organisational memory | Executive Guild, all Guilds |
| Corporate Operations and Finance | Run internal operations, finance, administration, and business enablement | Executive Guild, Administration Guild |
| Continuous Improvement and Portfolio Evolution | Improve value streams, practices, platforms, and product/platform investment choices | Leadership Team, Guild Leads, Value Stream Owners |
Candidate Platform Bets
These are the strongest initial platform candidates implied by the current operating model.
1. Delivery Accelerator Platform
A reusable internal capability for solution templates, reference architectures, deployment baselines, and common delivery assets.
Why it matters: This directly targets repeated one-off delivery effort and improves consistency across consulting work.
2. Shared Integration and Data Backbone
A common approach for integrations, data movement, event flows, and system-of-record boundaries that can support both client delivery and internal products.
Why it matters: This reduces bespoke integration sprawl and creates a stronger foundation for reusable IP.
3. Agent and Automation Primitives
A shared capability set for agent workflows, orchestration patterns, evaluation, governance, and operational controls that can be reused across offerings.
Why it matters: This aligns with the company’s product direction and turns repeated automation work into a more coherent platform capability.
Recommended Pilot Value Stream
The best initial pilot is VS02 Discovery to Deployment.
It is the strongest candidate because it sits closest to the current pain points:
- poor alignment between business, sales, strategy, delivery, technology, and operations
- inconsistent solution design outputs
- weak reuse from one engagement to the next
The pilot should focus on one recurring opportunity type or solution pattern rather than attempting to model the entire company at once.
Minimum Artefact Set
The initial enterprise architecture artefact set should be limited to:
- capability map
- BPMN value stream or cross-functional flow view
- C4 context and container view
- ADR for material architectural decisions
- DDD context map only where ownership or domain boundaries are unclear
Interactive Enterprise C4 Landscape
The enterprise C4 landscape diagram is being migrated to Mermaid/Excalidraw format. A placeholder will be replaced with an embedded diagram in a future update.
90-Day Rollout
Days 0-30
Objectives
- agree the architecture principles
- validate the first-pass capability map
- choose the first pilot problem in VS02
Deliverables
- approved starter architecture principles
- revised capability map
- named owners for 2-3 candidate platform bets
- selected pilot use case
Key workshops
- leadership and Guild lead capability review
- business-to-technology alignment workshop for the pilot scope
Days 31-60
Objectives
- model the pilot value flow
- standardise the first architecture artefacts
- expose reuse and ownership gaps
Deliverables
- BPMN model for the pilot flow
- C4 context and container views for the pilot architecture
- DDD context map if the pilot exposes unclear domain boundaries
- first ADRs for key platform or pattern decisions
Expected outcomes
- clearer handoffs across Sales, Delivery, Technology, and Operations
- one or more candidate capabilities promoted from bespoke delivery into reusable platform assets
Days 61-90
Objectives
- introduce the lightweight review point
- formalise the initial platform bets
- decide whether to scale the method to another value stream or product area
Deliverables
- lightweight architecture review checklist
- initial platform bet backlog
- recommendation on next rollout scope
- summary of lessons learned from the pilot
Lightweight Review Point
The first review checkpoint should not be an architecture board. It should be a short review for significant changes that asks:
- Which business capability or value stream outcome does this support?
- Are we reusing an existing pattern, platform, or context?
- Who owns the resulting capability?
- Does this require an ADR?
Risks
| Risk | Consequence | Mitigation |
|---|---|---|
| Starting with too much modelling ceremony | Low adoption and slow delivery | Keep the artefact set intentionally small |
| Treating capability mapping as an org chart exercise | Weak strategic value | Define capabilities around what the company must do, not who currently does it |
| Picking too broad a pilot | Slow progress and ambiguous outcomes | Constrain the pilot to one recurring opportunity or solution pattern in VS02 |
| No clear owner for platform bets | Reuse opportunity stalls | Assign an explicit owner before platform work begins |
Immediate Next Actions
- Review and refine the first-pass capability map with leadership and Guild leads
- Confirm the initial platform bets and assign provisional owners
- Select one VS02 pilot scenario and produce the first BPMN and C4 views