Enterprise Architecture Starter Guide

Purpose

This guide defines a pragmatic enterprise architecture approach for Calab.ai. It is intended to improve alignment between strategy, sales, delivery, technology, operations, and product/platform investment without introducing heavyweight enterprise architecture ceremony.

Recommended Approach

Calab.ai should not adopt a single heavyweight enterprise architecture framework as its day-to-day operating model. The recommended approach is:

• TOGAF-lite for structure and governance boundaries
• Capability mapping for business architecture and investment focus
• BPMN for value streams and cross-functional workflows
• DDD for domain boundaries, bounded contexts, and ownership clarity
• C4 for solution, platform, and system communication
• ADRs for consequential architectural and structural decisions

This keeps the architecture method aligned with the company’s current maturity, consulting-led delivery model, and emerging product/platform ambitions.

Why This Fits Calab.ai

The current organisational model already distinguishes between Guilds, Value Streams, Products, and company-level governance. The main gap is not lack of structure. The main gap is lack of a shared architecture method that connects:

• business intent
• delivery design
• platform reuse
• product evolution
• decision governance

This approach provides that connection while remaining maintainable in a Git-based handbook.

Architecture Principles

These principles should be adopted first and refined through use.

1. Reuse Before Rebuild

When a capability is repeatedly implemented across engagements or products, the default question is whether it should become a shared platform capability, reference pattern, or product asset.

2. Business Capabilities Anchor Architecture

Architecture decisions should be traceable to a business capability, value stream outcome, risk obligation, or product objective. Architecture should not be driven solely by technology preference.

3. Explicit Ownership Boundaries

Every meaningful business concept, platform capability, and architectural decision must have a clear owner. Ambiguous ownership is treated as an architecture issue, not only an operating issue.

4. Productise Repeated Delivery Patterns

Repeated consulting solutions should be treated as candidates for platform standardisation, accelerators, or products.

5. Favour Text-First Models

Architecture artefacts should default to text-first, versioned formats that are easy to review and update in Git. Formal tool-specific models should only be used where there is a clear payoff.

6. Decisions Must Be Durable

Important architectural decisions must be captured in ADRs with context, rationale, and consequences. Diagrams explain structure; decision records explain why.

7. Governance Must Enable Delivery

Architecture governance exists to improve decision quality, reuse, and risk management. It must not become a gatekeeping exercise detached from delivery reality.

Recommended Modelling Stack

Concern	Primary Technique	Purpose
Business architecture	Capability map	Show what the company must be good at and where investment should focus
Cross-functional flow	BPMN	Clarify value streams, handoffs, control points, and ownership
Domain boundaries	DDD context maps	Define bounded contexts, ubiquitous language, and integration seams
Solution communication	C4	Communicate context, containers, components, and interfaces clearly
Decision governance	ADRs	Record important architectural choices and trade-offs

When To Use What

Use capability maps when:

• leadership needs a shared picture of what the company does
• platform investment priorities are unclear
• multiple teams are discussing reuse, ownership, or strategic direction

Use BPMN when:

• a value stream crosses multiple Guilds or functions
• handoffs, delays, or control points are causing confusion
• Sales, Delivery, Technology, and Operations need a shared operational view

Use DDD when:

• a platform or product boundary is unclear
• different functions use different language for the same business concepts
• reuse efforts are being blocked by poor domain separation

Use C4 when:

• engineers need a clear and maintainable architecture view
• a new solution, platform, or integration is being introduced
• reviewers need fast understanding without formal EA tooling

Use ADRs when:

• a decision has long-term technical or organisational consequences
• a trade-off needs to remain understandable after the original discussion ends
• architecture review produces a meaningful decision rather than just comments

Minimum Artefacts For Material Changes

The minimum artefacts for any significant cross-team or cross-product change should be:

1. A reference to the impacted business capability or value stream
2. A C4 context or container view
3. A short impact statement describing ownership, reuse, and operational implications
4. An ADR if the change introduces a new pattern, platform dependency, or structural trade-off

For larger initiatives, add:

1. A BPMN process model if the work changes how value flows across teams
2. A DDD context map if the domain boundary or product/platform ownership is being established or changed

Lightweight Governance Model

Scope of review

Lightweight architecture review should apply to:

• new platform capabilities
• cross-product shared services
• materially new integration patterns
• architecture decisions with cost, risk, or ownership consequences across Guilds

Review intent

The review should answer only these questions:

1. What business capability or value stream outcome does this support?
2. What is being reused versus newly introduced?
3. Who owns the resulting capability or context?
4. What long-term decision is being made?

Decision authority

• Product and platform-local decisions remain with the relevant Product Owner and technical leads
• Cross-product technical standards sit with the Technology Guild
• Company-wide operating or governance implications escalate through the existing company governance model

Relationship To DDD

DDD is not the enterprise architecture framework. It is the domain design method inside the broader approach.

DDD should be used to:

• identify bounded contexts
• align business language with technical ownership
• separate reusable core capabilities from commodity or client-specific concerns
• define product and platform boundaries that can scale beyond one-off delivery

Anti-Patterns To Avoid

• adopting full TOGAF ceremony before a working architecture practice exists
• standardising on ArchiMate as the default language for delivery teams
• treating architecture as diagram production instead of decision support
• creating governance steps that are disconnected from real delivery and product work
• using platform language for capabilities that are still bespoke consulting work

First Implementation Priority

The first architecture deliverable should be a draft business capability map with candidate platform bets identified. That artefact creates the anchor for architecture principles, DDD boundary discussions, value stream optimisation, and platform/product investment decisions.