Business
and Data Architecture (after TOGAF)
Copyright 2017 Graham Berrisford.
One of about 300 papers at http://avancier.website. 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.
Contents
The importance of
business architecture to EA
TOGAF’s
business architecture guidance and techniques
TOGAF
data architecture in a nutshell
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 Architecture |
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 Architecture |
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. |
|
Technology Architecture |
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 |
Capability |
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.
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://avancier.website.
All free-to-read materials at http://avancier.website 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 avancier.website in whichever social media you use.