Business and Data Architecture (after TOGAF)

Copyright 2017 Graham Berrisford.

One of about 300 papers at Last updated 29/01/2017 19:24


This paper discusses the place of business architecture in enterprise architecture (EA).

It refers also to data architecture, since EA is about business processes that create and use data.


The importance of business architecture to EA.. 1

TOGAF’s business architecture guidance and techniques. 2

TOGAF data architecture in a nutshell 4

Remarks and further reading. 5


The importance of business architecture to EA

Business architecture is essential to EA.

"A knowledge of the business architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.)."


Enterprise architecture (EA) optimises and extends business activities that create and use data.

Enterprise architects respond to business plans, align changes with them, and sometimes influence them

They draw up high-level designs and plans for changes to the three architecture domains in the table below.


Business Planning

Business mission, vision, drivers, strategies and goals.

Mergers, acquisitions, divestments and internal organisation restructurings.

Enterprise Architecture 

(Business Systems Planning)



Business functions/capabilities, roles, processes/value streams and their interrelationships.

The services they provide to each and to entities in the business environment.

Information System


Applications and their interrelationships

The services applications provide to each other and to business activities.

Data stores and data flows, the data structures they contain and the qualities of that data.



Platform technologies and their interrelationships

The services technologies provide to each other and to business applications.


Enterprise architects take a cross-organisational and strategic perspective of the three architecture domains.

They govern lower level solution, software and technical architects working on specific programmes and projects.


Business architecture in Business Planning

"in some cases...the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.

In other cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support.

This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A." TOGAF 9.1


Business architecture in EA (ADM phase B)

"The business scenario technique... or any other method that illuminates the key business requirements and indicates the implied technical requirements for IT architecture, may be used." TOGAF 9.1


EA regards the enterprise as a system.

This table defines some general system theory concepts and illustrates their application in business architecture approaches.

It distinguishes structures from behaviors, and abstract structures from concrete ones.

System theory

Business architecture in BIZBOK®

Business architecture in TOGAF®

Abstract structure node

groups required behaviors/actions


Function, Role

Concrete structure node

is assigned to perform behaviors/actions

Organization unit, Actor

Abstract behavior

sequences required behaviors/actions

Value stream: steps in value creation/delivery

Scenario, Process: steps in service creation/delivery

Abstract action

is an atomic behavior

Process step

Abstract system structure

the network in which nodes interact

Capability/Outcome Network:

Flows between Capabilities.

Node Connectivity Diagram:

Flows between Nodes


There are other system theory concepts: notably passive structures and concrete behaviors.

And if you are wondering what concrete behaviors are – they are realisations of abstract behaviors in performances, executions, or occurrences.

TOGAF’s business architecture guidance and techniques

TOGAF includes more guidance for business architecture any other architecture domain.

More meta model entities for business architecture than for any other architecture domain.

And more artefacts for business architecture than for any other architecture domain.


TOGAF provides a management framework for business process modelling and business architecture techniques.

It devotes a whole chapter to business scenario analysis – more than it does for any other technique.


TOGAF has one phase (B) dedicated to business architecture.

It assumes knowledge of the following business architecture techniques and products.

“The level and rigor of decomposition needed varies from enterprise to enterprise”


"Business scenario analysis" (cf. value stream analysis)

In essence: this involves designing a business process along with the human and computer roles and resources required for it.

"the ADM has its own method for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements...

 “This process and may be used iteratively, at different levels of detail in the hierarchical decomposition of the business architecture."

(See further reading below.)


"Structured analysis" (cf. capability-based planning)

In essence: Define the organisation structure. Define the logical functional structure. Map functions to organizational units. Map functions to processes.

One scopes a business function/capability by the services it offers and the processes steps it performs, and maps it to organisation units and roles.

These are natural outputs not only of a "structured analysis" exercise, but also “capability-based planning”.

(See further reading below.)

"Business process modelling"

In essence: Identify processes needed to supply business services. Decompose process into steps (activities). Map activities to functions. Identify services and resources needed by activities.

"Process Flow diagrams show sequential flow of control between activities and may utilize swim lane techniques to represent ownership and realization of process steps."
Swim lanes may be used to show organisation units, roles, business functions or applications.

You should always define the data created and needed by business process steps

And since defining data flows is part of business process modelling, data definition begins in phase B.

 (See further reading below.)

"Use case analysis" (cf. Information System Services)

In essence: Define the uses that actors playing roles make of an information system, and identify lower level automated services needed to complete a use case.
Use cases connect business architecture to Information Systems Architecture.

"the application that supports a process step may be shown as a swim lane."

The connection between process step and application represents one or more use cases.

Defining the use cases or information system services is an application scoping decision.

(See further reading below.)


TOGAF is concerned with the effective integration of human and computer activity systems.

And less with the most human aspects of an organisation: building facilities, management reporting structures, benefits packages, etc

Responsibility for designing the latter may lie with a parallel “business change" team, HR, business managers, etc.

TOGAF data architecture in a nutshell

Data architecture is partly about data at rest.

Data stores and their contents are modelled as data components and data entities.


A data component contains data accessible by one or more applications.

Logical data components are data structures that architects presume will be encapsulated in data stores.

Physical data components are data structures encapsulated by particular data technologies (transactional, data warehouse, big data…).


A data entity is a smaller data structure representing something of interest in the business domain.

It might be small or large; it might correspond to a database table, an aggregate data view, or a fact table.

Once documented, it can be associated with data components that contain it.

Also, with roles and applications that create or use it; and particular application/IS services that capture, return, move, modify or archive it


Data architecture is also about data in motion.

Data flows appear in application/IS service contracts as inputs and outputs, and may be documented in an interface catalog.

A data flow definition may be related to data entity definitions.


Data in the applications domain

TOGAF focuses mostly on digital business data created and used with the help of business applications.

The data is received and produced in various I/O data formats, moved by remote invocations and messaging systems, and stored in databases.


Most applications store some data for some time.

Usually, caches and databases that are wholly encapsulated by applications need not be modelled separately.

The data elements of most interest to enterprise architects are:

·         Loosely-coupled data stores, which are accessible by more than one application.

·         Data flows that are consumed and produced by application/IS services.


All applications used by human (and perhaps machine) actors playing business roles in the business domain of interest are “application components”..

That includes business intelligence and data analytics applications

Also “big data” applications, some of which process real-time input streams and may output results to a GUI.

So, application/IS services include the running of batch and real-time data stream processes.


Data outside the application domain

Data appears in the others architecture domains

There is non-digital (e.g. paper) business data in the human domain.

You should always define the data created and needed by business process steps

And since defining data flows is part of business process modelling, data definition begins in phase B.

And if your non-digital data is subject to regulation, you should tailor your ADM to emphasise this.


TOGAF does not focus on data as seen in IT operations.

It says little about server and network monitoring data, run-time configuration data, SANs, availability and disaster recovery.

Remarks and further reading

TOGAF is a management framework for architects and high-level analysis and design activities.

It does not explain its artifacts, let alone processes to produce them.

It users are supposed to be architects who already know how to


Avancier Methods include advice on business architecture processes and products

You can find them on the Products and Techniques page at htttp://



All free-to-read materials at are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to in whichever social media you use.