Fundamentals 11 min read

Understanding Business Services in TOGAF: Definitions, Identification, and Service Modeling

The article explains the concept of business services within the TOGAF framework, clarifies their definition and identification through examples from insurance and banking, and shows how they relate to SOA, ITIL, and enterprise architecture service models.

Architects Research Society
Architects Research Society
Architects Research Society
Understanding Business Services in TOGAF: Definitions, Identification, and Service Modeling

In the TOGAF 9.1 meta‑model, the central box labeled “Business Service” often raises the question of its exact meaning. The specification defines a business service as “a capability supported by an explicitly defined interface and explicitly governed by the organization.”

While business capabilities help determine which services are needed to achieve agility, the definition does not explain how to identify or size those services. In a Service‑Oriented Architecture (SOA) view, a service is a black‑box whose implementation is hidden behind a standard interface.

The TOGAF specification further describes a service as “a logical representation of a repeatable business activity that produces a specified output (e.g., credit check, weather data provision, drilling report consolidation)”. It is independent, can be composed of other business services, and appears as a “black box” to consumers.

Nevertheless, the exact nature and granularity of business services remain unclear. ArchiMate 2.1 adds that “business processes, functions or interactions may be used to realize business services”, but still does not answer what a business service truly is.

Examples illustrate the concept: a potential lead‑management system may expose services such as “Lead Identification” or “Prospect Identification”, which are accessed by sales staff without needing to know the underlying applications.

Business services are expressed as distinct “business behavior elements” performed by specific roles to support particular business goals. Starting from business processes, one can examine a landscape of core and non‑core functions at various abstraction levels (descriptive, analytical/operational, executable) and apply a top‑down approach to identify candidate business services.

Three concrete examples are provided:

Example 1 – Insurance

Business capability: Customer contract management

Business goal: Ensure high‑quality customer contracts

Business activity: Create customer contracts

Business function: Contract management

Business process: Contract management process

Business role: Contract specialist

Business service: Customer contract creation

All these concepts can be linked to a single TOGAF meta‑model element.

Example 2 – Insurance Claim

Business capability: Insurance claim management

Business goal: Comply with policy terms

Business activity: Accept insurance claim

Business function: Claim management

Business process: Claim management process

Business role: Insurance claim recipient

Business service: Insurance claim acceptance

Example 3 – Banking

Banking products: Current account, Savings account, Overdraft account, Credit‑card account

Business service: Cash withdrawal / deposit

Depending on the banking channel used, multiple applications or system components such as ATMs, kiosks, online banking, mobile banking, and branch banking may be involved.

From an enterprise‑architecture perspective, business services are delivered to customers and may support business processes directly or indirectly via IS services, SOA services, or ITIL services. TOGAF defines IS (Information System) services as “automated elements of business services” that can deliver or support one or more business services.

SOA services are software components that expose interfaces, while ITIL services represent a combination of people, processes, and technology that deliver value to customers. The article presents an extended TOGAF meta‑model that connects business services with IS services, SOA services, and ITIL services, illustrating dependencies among functions, processes, products, and various service layers.

The author also sketches possible service descriptions for the “Customer contract creation” service, including an ITIL‑style contract‑management service and a corresponding SOA service.

SOAEnterprise ArchitectureTOGAFITILBusiness Service
Architects Research Society
Written by

Architects Research Society

A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.