Role Concepts in EAM

What kind of roles are there in Enterprise Architecture Management?
By Yann Vandercoilden (Yann Vandercoilden | LinkedIn) |
Tags:
Categories:

Role Concepts in EAM

Why Roles in EAM?

Enterprise Architecture Management (EAM) operates within the tension between strategy, organization, IT systems, and operational processes. Without clearly defined roles, there is a risk that architecture work remains purely documentary or is carried out in an uncoordinated manner by various parties.

Roles in EAM therefore fulfill several central functions:

1. Clarifying Responsibilities
Architecture decisions affect many areas of a company. Roles ensure clarity on who prepares, makes, or is accountable for decisions.

2. Structuring Perspectives
EAM examines organizations from different viewpoints (Business, Data, Applications, Technology). Roles help anchor these perspectives organizationally.

3. Enabling Communication
Architecture is a translation space between business and IT. Roles define who speaks which language and represents which interests.

4. Ensuring Governance
Architecture guidelines only take effect if someone is responsible for their enforcement – for example, through architecture boards or review processes.

In short:
Roles form the organizational foundation so that architecture is not only modeled but also lived and managed.

How Do Established Frameworks Handle This?

TOGAF

The TOGAF framework defines a series of roles around architecture work, particularly in the context of the Architecture Development Method (ADM).

Architecture roles and relationships after TOGAF Taken from TOGAF Architecture Roles and Skills (User account needed).

TOGAF defines following architecture roles:

  • Enterprise Architect – Overall responsibility for the company’s architecture

  • Segment Architect – Responsibility for specific architecture domains (Business, Data, Application, Technology)

  • Solution Architect – Architecture of a concrete project or system

  • Chief Architect – Governance and decision-making body for architecture matters

TOGAF views roles primarily from a governance and process perspective.
They are closely linked to the phases of the ADM and architecture governance.

However, the roles are deliberately formulated generically and must be adapted by each organization to its own structure.

Zachman Framework

The Zachman Framework takes a different approach. It defines no explicit roles, but instead structures architecture artifacts along two dimensions:

The structure of Zachman

Taken from About the Zachman Framework.

  • Questions (What, How, Where, Who, When, Why)

  • Perspectives (Planner, Owner, Designer, Builder, Subcontractor, Functioning System)

However, the rows of the framework can be interpreted as implicit role perspectives:

Perspective Typical Role
Planner Strategy / Corporate Management
Owner Business Managers
Designer Enterprise or Solution Architect
Builder Developer / Implementation
Subcontractor Technical Specialists

The contribution of the Zachman Framework lies less in concrete role titles, but rather in the realization:

Architecture emerges from different perspectives and questions.

Thus, Zachman provides a good foundation for systematically deriving roles from fundamental architecture questions.

Roles in Relation to the EVA Principle

The EVA principle (Input – Processing – Output) can be used as a simple thinking structure to organize responsibilities in the architecture context.

Translated to architecture questions, six basic perspectives can be distinguished:

  • What – Objects and information

  • How – Processes and functions

  • With What – Tools and technologies

  • Why – Goals and motivation

  • When – Temporal structure and planning

  • Who – Organization and responsibilities

These questions help define roles not just by hierarchy or subject domain, but by their functional responsibility within the architecture space.

In Connection with the Basic Questions

Roles/Responsibilities for “WHAT”

The question of “What” refers to the central information objects of an organization.

Typical responsibilities:

  • Definition of central information objects

  • Data models and information structures

  • Data quality and data ownership

Typical roles:

  • Data Architect

  • Information Architect

  • Data Owner

  • Data Steward

These roles ensure that data structures are consistent and understandable across the organization.

Roles/Responsibilities for “HOW”

“How” describes the processes and functions with which an organization delivers its services.

Typical responsibilities:

  • Modeling of business processes

  • Definition of capabilities

  • Coordination between business and IT

Typical roles:

  • Business Architect

  • Process Owner

  • Capability Manager

These roles ensure that business processes and IT systems are aligned with each other.

Roles/Responsibilities for “WITH WHAT”

The question “With What” concerns the technological means for implementing processes.

Typical responsibilities:

  • Technology standards

  • Platform architectures

  • Infrastructure strategies

Typical roles:

  • Technology Architect

  • Infrastructure Architect

  • Platform Architect

They define the technical framework within which solutions are created.

In Connection with the Basic Questions

Roles/Responsibilities for “WHY”

“Why” connects architecture with the strategic orientation of the company.

Typical responsibilities:

  • Derivation of architecture principles

  • Strategic target images

  • Transformation roadmaps

Typical roles:

  • Enterprise Architect

  • Strategy Architect

  • Transformation Lead

These roles ensure that architecture decisions are strategically justified.

Roles/Responsibilities for “WHEN”

“When” concerns the temporal coordination of architecture changes.

Typical responsibilities:

  • Transformation planning

  • Roadmaps

  • Release and program planning

Typical roles:

  • Portfolio Manager

  • Program Manager

  • Transformation Manager

They ensure that architecture is not only designed but also implemented in a timely manner.

Roles/Responsibilities for “WHO”

The question “Who” concerns the organizational anchoring of architecture work.

Typical responsibilities:

  • Governance structures

  • Roles and responsibilities

  • Decision-making processes

Typical roles:

  • Architecture Board

  • Domain Leads

  • Architecture Governance Lead

These roles ensure that architecture decisions are institutionally anchored.

Scaling the Role Concept

Not every organization needs the same roles.
The number and specialization of roles depend heavily on the size and complexity of the organization.

The DPBoK (Digital Practitioner Body of Knowledge) describes four context levels, based on which roles can be meaningfully scaled.

Context I: Individual / Founder

In very small organizations, a single person often assumes multiple roles simultaneously.

Typical situation:

  • Founder = Strategy, Architecture, and Implementation

  • Low formal separation of roles

Characteristics:

  • Implicit architecture

  • Quick decisions

  • Minimal governance

Architecture work here is rather intuitive.

Context II: Team

As size increases, first functional roles emerge.

Typical roles:

  • Product Owner

  • Lead Developer

  • Solution Architect

Architecture often arises within a team and is strongly shaped by concrete products.

Context III: Team of Teams

From this stage onward, coordinating architecture roles emerge.

Typical roles:

  • Enterprise Architect

  • Domain Architect

  • Architecture Board

Central tasks:

  • Coordination between teams

  • Common architecture principles

  • Platform and data standards

Architecture is here for the first time coordinated across the enterprise.

Context IV: Established Company

In established organizations, architecture becomes its own organizational function.

Typical structures:

  • Architecture Office

  • Enterprise Architecture Practice

  • Architecture Governance

Characteristics include:

  • Clearly defined roles

  • Formal governance

  • Long-term transformation planning

Here, architecture becomes a central instrument of corporate management.

Conclusion

Roles in Enterprise Architecture Management can be defined in different ways. While frameworks like TOGAF propose concrete roles, the Zachman Framework primarily highlights different perspectives on architecture.

A systematic derivation of roles succeeds when architecture is structured along fundamental questions – for example, via the six perspectives:

  • What

  • How

  • With What

  • Why

  • When

  • Who

These questions make visible which responsibilities actually exist in the architecture space.

Which roles are actually established, however, depends heavily on the organizational context. Using the scaling levels of DPBoK, it is possible to trace how architecture roles can grow from a single person to an institutionalized architecture organization.

This makes it clear:
EAM roles are not a rigid set of titles, but a scalable organizational concept for architecture responsibility.