Introduction

In a previous post (Different Roles and Responsibilities for an IT Architect), I outlined the different roles in architecture. The natural next question is: what work actually sits with each role?

This is where I see organizational struggle—not because roles are unclear, but because the work boundaries are.

A useful lens here comes from Svyatoslav Kotusev’s The Practice of Enterprise Architecture, where architecture is described not as a set of roles, but as practices operating at different levels of the organization.

What follows is a practical way to make that explicit.

Note: In my previous post I also included Infrastructure Architects. They are intentionally left out here to keep the focus on how application and solution-level architecture work is split. Infrastructure Architecture operates with similar principles, but across platform and environment concerns.

The Core Principle

For clarity on naming:

  • Enterprise Architect (EA)
  • Domain Architect (DA) — equivalent to what many organizations call Solution Architect
  • Software Architect (SA) — equivalent to Tech Lead

The SA abbreviation is overloaded in many organizations, so in this post SA refers to Software Architect, not Solution Architect.

Each role operates on a different level of abstraction and time horizon:

  • Enterprise Architecture (EA) → direction and constraints  — Sets business-driven direction and guardrails that shape all downstream decisions.
  • Domain Architecture (DA) → alignment and structure  — Translates direction into coherent structures and boundaries across a business area.
  • Software Architecture (SA) → design and execution  — Turns structures into concrete, implementable systems and makes final design decisions.

Enterprise is horizontal across the organization (cross-cutting capabilities, standards, and direction), while Solution/Software is vertical (aligned to specific business areas and initiatives).

Examples:

  • Enterprise looks at things like Customer Management, Product Management, Order Management, Finance, or Supply Chain across all business areas.
  • Domain Architects works within a specific area or initiative and ensures systems in that context fit together.
  • Software Architects decides on software architecture implementation patterns.

If those are confused, enterprise architects turn into domain or software architects—and everything fragments.

Enterprise Architect — The Direction Layer

This layer focuses on business-driven direction and constraints.

Primary work:

  • Define architectural principles and guardrails
  • Align architecture with business strategy and operating model
  • Set direction based on business capabilities and needs
  • Establish governance and decision frameworks

Artifacts:

  • Principles
  • Target architecture (at capability level — e.g. Customer Management, Product Management, Order Management, Finance, or Supply Chain as cross-cutting business capabilities shared across the organization — not specific systems or tools)
  • Strategic direction

What it’s not:

  • Deciding architectural styles (e.g. event-driven vs request/response)
  • Choosing integration patterns or technologies
  • Designing systems or interactions
  • Translating direction into technical solutions

Enterprise architecture answers why and in which direction, not how.

Domain Architect — The Alignment, Design, and Execution Layer

This is where architecture becomes concrete.

Primary work:

  • Shape how business capabilities are realized across systems in a given domain or initiative
  • Ensure consistency and coherence across solutions
  • Design the solution end-to-end
  • Translate enterprise direction into a working architecture
  • Make concrete design choices (e.g. event-driven vs request/response)
  • Define APIs, data flows, and interactions
  • Make trade-offs under real constraints
  • Ensure compliance with standards and principles

This is where architectural intent meets real delivery and must align with defined rules and processes.

Artifacts:

  • Solution designs
  • Architecture decision records
  • Reference patterns (within the context of the domain/initiative)

What it’s not:

  • Defining enterprise-wide principles
  • Working purely at strategy level without delivery responsibility
  • Escalating every decision upward

This is the level where decisions like event-driven vs request/response, Kafka vs REST, data ownership, and consistency models are actually made.

Software Architect — The Reality Check

This is where architecture meets code.

Primary work:

  • Translate architecture into implementation
  • Own technical quality and execution
  • Challenge designs based on reality
  • Ensure operability

What it’s not:

  • Redefining architecture because it’s inconvenient
  • Ignoring constraints set at higher levels
  • Acting only as a senior developer

How the Work Connects

  1. Enterprise (EA) defines direction
  2. Domain (DA) shapes, designs, and makes decisions
  3. Software Architect (SA) ensures it works in practice

The key is that decisions are made at the lowest responsible level.

If Enterprise work is not protected, it will collapse into Solution work.

Final Thought

Architecture breaks down when decisions are made at the wrong level:

  • If enterprise architects decide on Kafka, you lose flexibility.
  • If solution architects define enterprise principles, you lose coherence.

Kotusev’s point is simple: architecture is a system of practices and the value comes from keeping those practices separate—and connected.