TOGAF Phase B Business Architecture: Business Service Models

In the first part of Phase B, we established the Business Capability Model and mapped the key processes that deliver those capabilities. This second part goes deeper into how the business is actually structured to deliver its work, through business services, functions, actors, and roles.

Understanding these elements is what separates a surface-level Business Architecture from one that truly illuminates organizational complexity. It is also where the link between Phase B and Phase C (Information Systems Architecture) becomes visible: business services define what information systems must support.

Recap: Where We Are in Phase B

To briefly set context: Phase B develops the Business Architecture. In Part 1, we defined business capabilities, built the capability map, modeled business processes and performed a gap analysis between the baseline and target.

This post continues from that foundation and covers:

Business functions and how they differ from capabilities and processes
Business services: the externally observable outcomes the business delivers
Actors and roles: who delivers those services
Business interaction models: how organizational units collaborate
Information needs from the business perspective, which feeds directly into Phase C

Business Functions

A business function is a unit of business capability that groups related activities together. Functions are often aligned with organizational departments or specialist teams.

The distinction between a function and a capability can seem subtle, but it is important:

A capability is what the organization can do (independent of who does it)
A function is how a specific part of the organization is organized to perform related tasks

For example, an organization might have a "Credit Risk Assessment" capability. The function that delivers this is the "Credit Risk Team", which performs related activities like reviewing applications, running credit bureau queries, applying credit policy rules, and escalating borderline cases for senior review.

Functions are useful in Business Architecture because they connect capabilities to the organizational structures that deliver them. When an organization restructures, functions change. When capabilities need to improve, architects know which function to focus on.

Business Functions in the Baseline

Documenting baseline business functions reveals misalignments that are often invisible until they are drawn out:

Functions that are duplicated across organizational units
Capabilities that have no clear ownership (performed informally across multiple teams)
Functions whose boundaries cut across business capabilities in ways that create process inefficiencies

Business Services

A business service represents a defined unit of business functionality that is exposed to and consumed by other parts of the organization or by external parties. Business services are the externally visible outputs of a business function.

This concept is important for two reasons. First, it creates a stable contract between different parts of the organization. Regardless of how Service A internally reorganizes or automates its work, the service it exposes to Service B remains consistent.

Second, business services are what information systems must eventually support. When Phase C designs the Application Architecture, the applications must be capable of delivering the identified business services. This creates a direct traceability chain from business need to technology solution.

Characteristics of a Well-Defined Business Service

Defined name: Clear, business-language name such as "Customer Credit Check Service" or "Account Opening Service"
Consumer: Who uses this service (internal teams, external customers, partner organizations)
Provider: Which function or organizational unit delivers this service
Inputs: What information or triggers are required for the service to begin
Outputs: What the consumer receives when the service completes
Service levels: Expected response times, availability, and quality standards
Supported capabilities: Which capabilities this service delivers

Business Services Enable SOA Alignment

Business Services in TOGAF closely align with the concept of services in Service-Oriented Architecture (SOA). Organizations that define business services clearly in Phase B produce much better-aligned Application Architectures in Phase C, because application services can be designed to map directly to business services.

Actors and Roles

Actors and roles describe the human and organizational participants in business processes and service delivery.

Actor

An actor is an individual person, system, or organization that initiates or interacts with activities in the architecture. Actors are real-world entities that trigger processes or consume services.

Examples of actors:

A customer applying for a mortgage (external actor)
A branch manager approving a transaction limit override (internal actor)
A regulatory body submitting a data request (external actor)
An automated batch processing system submitting nightly reports (system actor)

Role

A role is a defined set of responsibilities associated with participation in a business process or the delivery of a service. Roles are more useful than named individuals in architecture, because they remain stable as people change.

Documenting roles in Phase B helps with:

Identifying skills gaps when the target architecture requires new responsibilities
Understanding accountability for specific capabilities
Establishing who has decision authority at each step of key processes
Planning organizational change management alongside technology change

RACI Matrices

A RACI (Responsible, Accountable, Consulted, Informed) matrix is a common tool for documenting role relationships in Business Architecture. It maps each business activity or service to the roles that must be involved and in what capacity.

Business Interaction Models

Business Interaction Models show how different organizational units collaborate within and across business functions. They go beyond simple process flow diagrams to capture:

Which units are providers and which are consumers of specific services
The nature of interactions (automated data exchange, human collaboration, formal reporting)
Latency and frequency characteristics of key interactions
Dependencies between units that create risk if one unit's performance degrades

Interaction models are particularly valuable in large organizations where the Business Architecture spans multiple divisions or legal entities. They make visible the organizational seams where coordination failures commonly occur.

Organizational Structure in Phase B

Phase B also documents the organizational structure and how it aligns with the capability model and service delivery framework.

Organizational structure artifacts in Phase B include:

Organization charts: Line relationships, reporting structures, and spans of control
Capability-to-team mapping: Which organizational units are responsible for which capabilities
Location models: Where functions and services are performed geographically (relevant for globally distributed organizations or regulatory constraints on data location)

This organizational context feeds into the Target Architecture planning. If the target state requires a new capability or shifts the ownership of an existing one, Phase B gives explicit visibility of the organizational change implications.

Connecting Phase B to Phase C

One of the most important roles of Phase B's service and function models is to set clear requirements for Phase C's Information Systems Architecture.

The connection works in three steps:

Phase B defines the business services the organization must deliver
Each business service has defined information inputs and outputs
Phase C designs the data and application architecture to store, process, and expose exactly that information in a way that enables each service

Without well-defined business services from Phase B, Phase C architects are forced to guess what the business actually needs. This guesswork is where expensive rework originates.

Document Business Services Before Designing Applications

Architects who define business services in Phase B and then use them as requirements for Phase C application design consistently produce more coherent, lower-rework architectures than those who design applications based on technical assumptions alone.

The Phase B Catalogue, Matrix, and Diagram Outputs

TOGAF's Architecture Content Framework specifies what Phase B should produce in formal terms. The main categories of output are:

Catalogs

Organization/Actor Catalog: All actors and roles
Business Service/Function Catalog: All services and functions with their properties
Location Catalog: Where functions and services operate geographically

Matrices

Actor/Role Matrix: Mapping actors to the roles they play
Business Interaction Matrix: Mapping which units interact with which

Diagrams

Business Footprint Diagram: High-level view of drivers, goals, and functions
Business Service/Information Diagram: Services and the information they consume and produce
Functional Decomposition Diagram: Hierarchical breakdown of functions
Goal/Objective/Service Diagram: Tracing services back to business objectives
Business Use-Case Diagram: Key interactions between actors and business services

Real-World Example: Government Benefits Agency

A government benefits agency undertaking a digital service transformation has the following Phase B service model work:

Business services identified: Benefits Eligibility Assessment, Payment Processing, Appeals Handling, Correspondence Management, and Fraud Detection
Actors: Citizens (external), Caseworkers, Team Managers, the Appeals Tribunal (external), and Audit Teams
Interaction model finding: Correspondence Management currently requires manual handoffs from four different teams with no shared record. This creates delays and duplicate communications
Target service model: A unified Citizen Communication Service exposed to all internal teams via a shared application, with automated tracking and a single citizen interaction history
Phase C implication: The Application Architecture must include a Case Management platform and a Customer Communications Hub with API integration to all caseworker-facing applications

Summary

Phase B Part 2 completes the Business Architecture by adding:

Business functions: How organizational units group related activities
Business services: The defined outcomes the organization delivers internally and externally
Actors and roles: Who participates in delivering those services
Interaction models: How different parts of the organization collaborate

Together with Part 1's capability and process models, this gives a complete picture of the business that Phase C can translate directly into information systems requirements.

In the next post, we move into Phase C, starting with Phase C: Application Architecture — designing the portfolio of applications that will enable the business services identified in Phase B.

For the full series context, visit What is TOGAF 9.2? or browse the complete TOGAF 9.2 Masterclass posts on Topictrick.