Arch Squared

The Architectural Archetype Framework

Define once. Instantiate many times. Adapt endlessly.

The Problem: Speed vs. Coherence

Organizations face an impossible choice:

Build everything custom and your teams drown in complexity. Every new requirement starts from scratch. Similar problems get solved differently across teams. Quality varies wildly. Technical debt compounds.

Force everything through rigid standards and delivery grinds to a halt. Teams wait months for architecture approval. Business context gets ignored. Exceptions proliferate until the standards become meaningless.

The Architectural Archetype Framework provides a third way: structured flexibility that enables both speed and coherence.

How It Works: Three Levels, Three Speeds

The framework operates through three distinct levels, each with different ownership, governance, and change velocity:

Level 1: Architectural Archetypes

The reusable template. Few. Stable. Enterprise-owned.

Architectural Archetypes are the fundamental patterns your organization uses repeatedly across domains. They’re abstract, business-agnostic templates that define structure without dictating implementation.

Examples:

  • Case Management (tracking work items through states)
  • Charge Calculation (computing fees based on inputs and rules)
  • Financial Reporting (aggregating and presenting financial data)
  • Party Management (managing individuals and organizations across contexts)
  • Document Generation (creating formatted outputs from templates and data)

Characteristics:

  • Quantity: few archetypes for most organizations
  • Stability: Very stable. Change rarely.
  • Ownership: Enterprise Architecture team
  • Governance: High. Architecture Council approval required.
  • Purpose: Define “this is how we approach this category of problem”

You don’t have many Archetypes. You don’t change them often. But every one you define unlocks dozens of implementations.

Level 2: Instances

Business purpose. More numerous. Domain-owned.

Instances are where Archetypes meet business reality. An Instance applies an Archetype to a specific business purpose, inheriting the structural template while adding domain context.

Examples (showing Archetype → Instance relationship):

Case Management Archetype instantiated as:

  • Customer Support Flows
  • Hiring Workflow
  • Incident Management
  • Procurement Processes

Charge Calculation Archetype instantiated as:

  • Transaction Fees
  • Subscription Billing
  • Late Payment Penalties
  • Usage-Based Pricing

Party Management Archetype instantiated as:

  • Customer Records
  • Vendor Management
  • Employee Directory
  • Partner Registry

Characteristics:

  • Quantity: As many as needed to operate the organisation i
  • Stability: Moderately stable. Can be built out as you change your organisation.
  • Ownership: Business domain owners and Solution Architecture.
  • Governance: Medium. Domain owner approval required and potentially a Solution Design Auhority or similar.
  • Purpose: “This is how we solve [business problem] using [Archetype]”

Instances multiply Archetypes across your business. Each inherits proven structure while adding necessary business logic.

Level 3: Variants

Context configuration. Many. Operational teams.

Variants are where Instances adapt to specific contexts. They configure rather than redefine, adjusting parameters and rules for particular situations while preserving the underlying Instance structure.

Examples (showing Instance → Variants relationship):

Customer Support Flow (Instance) → Variants:

  • Technical Support (SLA: 4 hours, escalation: engineering)
  • Billing Support (SLA: 24 hours, escalation: finance)
  • General Inquiries (SLA: 48 hours, escalation: supervisor)

Transaction Fees (Instance) → Variants:

  • Standard Customer (2.5% + $0.30)
  • Premium Customer (1.8% + $0.25)
  • Enterprise Customer (negotiated rates)

Customer Records (Instance) → Variants:

  • B2C Customers (individual profile, preferences, order history)
  • B2B Customers (company profile, multiple contacts, contract terms)
  • Trial Customers (limited data, conversion tracking)

Characteristics:

  • Quantity: Many
  • Stability: Changes frequently. Weekly or daily updates.
  • Ownership: Operational teams
  • Governance: Light. Self-service as long as you adhere to the Archetype and Variant.
  • Purpose: “This is how we handle [specific context]”

Variants multiply Instances across contexts. Teams clone and adapt without rebuilding from scratch.

The Three-Speed Architecture

The framework’s power comes from different change velocities at each level:

Rarely (Archetypes): Enterprise Architecture defines or refines fundamental patterns. High governance, careful consideration, broad impact.

Ongoing as Needed (Instances): Business domains create new Instance or enhance existing ones. Medium governance, domain expertise, focused impact.

All the time (Variants): Operations teams add or adjust Variants continuously. Light governance, rapid response, localized impact.

This creates governed autonomy: teams move fast within understood boundaries, making local decisions without creating organizational chaos.

Why This Framework Works

Enables Speed

  • Clone Variants instead of building from scratch
  • Configure Instances instead of coding
  • Reuse Archetypes across domains
  • Different speeds at appropriate levels

Teams don’t wait for architecture. They inherit proven patterns and adapt them to context.

Reduces Risk

  • Changes isolated to appropriate level
  • Archetype changes rare and carefully governed
  • Variant changes frequent but contained
  • Clear ownership prevents confusion

When something breaks, you know exactly which level to fix.

Improves Quality

  • Proven Archetypes reduce errors
  • Consistent approach across Instances
  • Lessons learned propagate upward
  • Testing focused at right level

Quality compounds as patterns mature through use.

Scales Effectively

  • Add new Variants easily (clone and adapt)
  • Add new Instances without Archetype changes
  • Archetype library grows slowly
  • Operational teams empowered

Your architecture grows with your organization without losing coherence.

Independence at Each Level

A critical principle: changes at one level don’t force changes at other levels.

Enhance an Archetype without breaking existing Instances. Add new capabilities; Instances adopt them when ready.

Create a new Instance without changing the Archetype. Apply the template to a new business context; the Archetype remains stable.

Add Variants freely without touching the Instance. Configure for new contexts; the Instance structure stays intact.

This independence is what enables different change speeds. You’re not choosing between “move fast and break things” or “move slow and break nothing.” You’re choosing the right speed at the right level.

Real-World Application

Consider how this framework handles growth:

Scenario: Your company expands internationally

Without the framework:

  • Engineering builds “UK Customer Management,” “US Customer Management,” “Singapore Customer Management” as separate systems
  • Code duplicates across implementations
  • Bug fixes applied inconsistently
  • Each market becomes harder to support

With the framework:

  • Party Management Archetype (already exists)
  • Customer Records Instance (already exists)
  • Add new Variants: UK Customers, US Customers, Singapore Customers
  • Each Variant configures: local data requirements, compliance rules, communication preferences
  • Core structure shared, local adaptation isolated
  • New market = new Variant (days), not new system (months)

Getting Started

Most organizations discover they already have implicit Archetypes buried in their architecture. The framework makes them explicit, governed, and reusable.

Start with one proven pattern: Identify something you’ve built successfully multiple times. That’s your first Archetype candidate.

Document the template: What structure, data, and logic patterns repeat across implementations? That’s your Archetype definition.

Map existing implementations: Your current systems likely map to Instances and Variants. Make the relationships explicit.

Govern appropriately: Establish different governance for each level. Archetypes need Architecture Council approval. Variants need operational boundaries, not approval chains.

Build the next one using the framework: Don’t retrofit everything. Apply the framework to new work, proving value through delivery.

Who This Framework Serves

Enterprise Architects who want their architecture to actually ship rather than gather dust in documentation

Product Teams who need structural guidance without bureaucratic bottlenecks

Operations Teams who need to adapt systems to local contexts without engineering intervention

Engineering Leaders who need to scale delivery without scaling chaos

Business Owners who need technology that adapts to business reality rather than forcing business to adapt to technical limitations

The Framework Principle

The Architectural Archetype Framework embodies a core principle: Build structure that enables, not structure that constrains.

Archetypes provide proven templates. Instances apply them to business contexts. Variants adapt them to specific situations. At every level, teams inherit wisdom without surrendering agency.

This is architecture that ships.

The Architectural Archetype Framework is part of the NovaFraming Methodology but can be used on its own.

© 2026 Charlotte Malmberg | charlotte-malmberg.com

If you want to know more please contact me on LinkedIn.