TOGAF Phase B: Business
Architecture
using TOGAF 9.1 & ArchiMate 3.0 artefacts
TOGAF® ArchiMate® are registered
trademarks of The Open Group.
Last updated 08/10/2017
01:39
A business architecture
defines business structures and behaviors and maps them
to business goals. In response to a Request for Architecture Work, the target
business architecture may focus on a particular value stream, business scenario
or process. Designing the target first (following the guidance in chapter 19)
narrows the focus of the baseline analysis. However enterprise architects also
need a cross-organisational view of the baseline business architecture, at
least a high level capability view.
The tradition is to analyse the baseline from current
structures to behaviors provided, and design the
target from required behaviors to the structures
needed to provide them.
|
Analyse the baseline |
Design the target |
|
-1- Form an organisation
view -2- Form a capability
view -3- Form a value stream
or process view -4- Form a people view -5- Form a service or
product view -6- Form an
information/data view -7- Form an applications
view |
-1- Define service or
product view -2- Define value stream
of process view -3- Define atomic
activities -4- Define people view -5- Define
information/data view -6- Define application
services (uses cases) |
The approach below divides business architecture into
seven views. Each view is described in terms of TOGAF 9.1 artefacts, with
suggested mappings to ArchiMate 3.0 diagrams.
Enterprise architects should
understand the baseline business. To complete all seven views and associated
artefacts could take a team of business analysts months or years. In practice,
most people use only a selection of the views and artefacts that follow. You
have to select which of them will help during whatever analysis and design is
relevant to request for architecture work.
Defined the business scope to be modelled
Enterprise architects very rarely
have the time and resources to model a whole business, or use all the products
that follow. Rather, they model only part of a business relevant to a request
for architecture work they have been given. So first, identify the organisation
units to be investigated
Define the level of detail or granularity to modelled
Define or illustrate the
atomic activity level - the level detail the analysis will reach. Some
recommend the atomic activity should be a one-person, one-place and one-time
(OPOPOT) activity. But enterprise-wide analysis must stop well short of that!
Define the views to be modelled
The seven business
architecture views below are different views of the same activities. For
example: a process sequences
activities over time. A role groups
activities performable by an actor with the ability to play that role. A capability or function groups activities
in some other way.
Find or form a view of the
existing management structure.
|
TOGAF
artefacts |
ArchiMate
viewpoints |
|
Organisation
Decomposition |
Organization |
|
Organisation/Actor
catalog |
|
The Organisation
Decomposition should be understood. The politics, problems and
possibilities of EA are much affected by it. So first, find or form an organisation
chart covering the area of interest. An organization unit should be a
self-contained unit of resources with measurable goals and objectives; and have
a manager.
An Organisation/Actor catalog might be completed if this knowledge will be
helpful. But it would be impractical to maintain an organisation/actor catalog in an EA repository.
How to insure the EA model against staff turn over and reorganisations that change the organisation structure? The convention is to form a logical organisation structure that categorises the activities of interest. This is independent of the management structure, though also sometimes aligned with it.
|
TOGAF
artefacts |
ArchiMate
viewpoints |
|
Functional
Decomposition diagram |
Capability
map |
|
Organisation/Function
matrix |
|
Draw a functional/capability
decomposition. This structure divides an enterprise’s capability into
subdivisions. Enterprise architects use this structure to engage business
managers and map other architecture elements to it. The level and rigor of
decomposition varies. A function/capability should be definable externally by
the services it provides, and internally by the activities required to deliver
those services.
Techniques
|
-1-
Find or buy a reference model that fits your business. Then tailor the
reference model to ensure it covers the activities you have identified.
Reference models include APQC PCF (for a commercial enterprise), BIAN (for a bank),
SCOR (for a supply chain business) and Proact (for
a retail business). -2-
Build a functional/capability decomposition by top
down decomposition. Successively decompose major capabilities or functional
areas Ensure that every activity can be placed under a node of the structure.
-3-
Build a functional/capability decomposition by
bottom up composition. List the activities in each organisation unit. Focus
on activities that are essential to provision of services, frequent, carried
out by many actors, and create or use business data. Cluster activities into
logical functions using some affinity criterion (data created, skills
required, or physical resources needed) Successively compose lower level
functions into higher level functions. -4-
Build a functional/capability decomposition from the
top-down and the bottom up. High level abstract models are never right first
time. Alternately elaborate and abstract to ensure that a higher level model
is well formed, that is: a manageable and accurate abstraction of lower levels, contains elements at a consistent level of
granularity, shows what is more important to the viewer and hides what is
less important to the viewer. You
may build more than one hierarchy if stakeholders want to see the business
activities classified in several ways. And thus create what some call a
multi-archy, a forest of hierarchical tree
structures. Choose one as primary hierarchy that speaks to most people, is
stable enough, and can be used catalog other
things. |
Map Functions to Organisation
Units in an Organisation/Function matrix, at whatever level of business
system decomposition is helpful.
Processes group activities
into temporal flows.
|
TOGAF
artefacts |
ArchiMate viewpoints |
|
Process
Flow diagram |
Business
Process Cooperation |
|
Process/Event/Control/Product
catalog |
|
|
Events
diagram |
|
|
Business
Use-case diagram |
Service
realization, Product |
Identify the activities relevant
to the endeavour. Draw one or more Process Flow diagrams to show how one
activity leads to another.
Techniques
|
Processes
(like functions) can be modelled at a high level and/or a low level. Each activity/step
in a higher level process may be elaborated in a lower level process flow
diagram. Check
activities can be assigned to business functions. Ideally, every activity in
a flow should be assignable to one node in a functional/capability decomposition
structure – even if you don’t document the structure to that level. You
can show business structure and behavior in one
diagram. Swim lanes show structure elements (usually Roles or Functions).
Arrows show and connect behavior elements (Events,
Triggers and Activities). Complete
correspondence is a theoretical possibility, but almost nobody gets complete
their models. The functional/capability decomposition usually stops at a high
(3rd or 4th) level, whereas some process models descend to a lower (5th or
6th) level. |
Other TOGAF artefacts you
might produce in this view include: A Process/Event/Control/ Product catalog to record the inputs and outputs of processes,
along with relevant rules. An Events diagram (e.g. A UML sequence
diagram) to focus attention on the events that trigger, or result from,
processes. A Business Use Case diagram to shows which external entities
(roles) engage with which processes within a business.
Individual human actors may
be recorded in the company directory or identity management system. But in an
enterprise architecture model, the people view is based on roles. Every human
actor can do more than any role they are asked to play. But what each
individual might do outside the definable system, in addition to a defined role
(or in conflict with it) is not documented by enterprise architects.
|
TOGAF
artefacts |
ArchiMate
viewpoints |
|
Role catalog |
|
|
Actor/Role
matrix |
Organization
– actors and roles |
|
Business
scenario |
Business
Process Cooperation |
You can list roles in Role
catalog along with the activities expected of
each role. A role is a group of activities that is performable by one or more
actors, by virtue of the abilities required.
You can map roles to
processes in the definition of a Business scenario (or value stream).
This technique is centered on a process that yields a
result of value to the business, along with the human and computer roles
involved in each activity.
Enterprise architects usually
models roles rather than actors, but there are occasions when individual actors
are named, especially where a role is performed by only one actor. You can map
actors to roles in an Actor/Role matrix.
A raison d’être of a business,
and every function within it, is to provide services or products. Looked at
from the outside, a business or function can be described in terms of the
services or products it offers.
|
TOGAF
artefacts |
ArchiMate
viewpoints |
|
Node Connectivity
diagram |
Organization
(Actor Cooperation in v2.1) Capability
map |
|
Business
Service/Information diagram |
Business
Process in v2.1 |
|
Business
Service/Function catalog |
|
|
Goal/objective/service
diagram |
Define business services
at whatever level of business system decomposition is helpful. Each service can
be defined in terms of a signature (name, trigger, inputs and outputs),
functional rules (pre and post conditions) and non-functional qualities
(response time, frequency availability, etc.)
Map Services to Functions (or
Organisation Units). A Node Connectivity Diagram describes flows of
materials and/or data between business nodes (functions or organisation units).
Technique
|
An
arrow indicating the direction of the flow can be annotated with data names
and other details. To draw a level 0 diagram, identify the customers, the
services they want; then identify the supplies required and the suppliers. To
form a node connectivity diagram, identify the nodes (organisation units or
functions. The define flows between nodes within the business, and to/from
external entities Link nodes by flow arrows, differentiating material and
information flows. Traditionally,
such a diagram is elaborated by top-down decomposition. Decompose level 0 into level 1 capabilities/functions, define inter-function
services and flows. Decompose level 1
capabilities/functions into level 2; define inter-function services
and flows, etc. But it is difficult to maintain more than 2 or 3 levels of
nesting. |
Other TOGAF artefacts you
might produce in this view include: A Business Service/Product catalog shows which processes are necessary to provide
which services or products. A Business Service/Function catalog
“can be used show a functional/capability
decomposition and identify capabilities of an organization” A Goal/Objective/Service
diagram can show which business services address which goals or objectives.
Map data entities to business
functions in data/entity business function matrix. This usually maps
activities to data entity types (e.g. Customer, Order, Product Type, Product Instance) that those activities create or use. Note
that I/O flows data are defined in service contracts and/or in what TOGAF calls
an “Interface Catalog”
Technique
|
You
can cluster activities (typically by data created) to identify cohesive
groups of data entities and of business functions. |
Other TOGAF artefacts you
might produce in this view include: A Process Flow Model which can
describe the information/data created and used by each activity, both within
the business and with entities outside the business. A Conceptual or
Business Data Model consolidates data definitions into a structure showing
data entities and relationships between them. An Information Exchange Matrix
identifies who exchanges what information with whom, why the information is
necessary, and in what manner. It documents the information exchange
requirements between three basic entities (activities, business nodes and their
elements, and information flow), and focuses on characteristics of the
information exchange, such as performance and security.
Relevant TOGAF artefacts
include: Application/Function Matrix , Application/Organization
Matrix , Role/Application Matrix and Application use case
diagram. The last of these relates business roles to IS services provided
by applications. Note that a company directory, identity management or access
control system may already record and relate organisation units to actors to
roles to applications An EA repository usually records roles rather than
actors.
Collect and study business drivers
(SWOT, PESTLE), aims (goals, objectives, requirements) and directives
(principles, policies and rules).
Study whatever baseline
business architecture has been documented (even if only a functional/capability
decomposition).
Highlight problem/opportunity
areas in what is often called a “heat map”.
Problems may include overlaps
between services provided by functions, gaps where the provided service is not
the truly required service, delays in handovers between activities.
Opportunities may include the
ability to increase parallel processing, or take advantage of new technologies.
Ross, Weill and Robertson
suggest: identify the processes that distinguish you competitively; envision
your customer’s experience as it ought to be; decide how you would like your
company to grow; then define services to be provided by the new business.
The approach to target
architecture (roughly speaking) reverses the approach for analysing the
baseline architecture. TOGAF’s business scenario technique can be extended a below.
-1- Define service or product
view
-2- Define value stream or
process view
-3- Define atomic activities
-4- Define role (human or
machine) view
-5- Define information/data
view
-6- Define application
services (uses cases)
Organisation
design?
Enterprise architects usually
maintain a logical Functional/Capability Decomposition structure. They use this
to the organise application and technology catalogs, and understand and explain the impact of changes.
An Organisation Decomposition
is a management hierarchy. The politics, problems and possibilities of EA are
affected by it. But it isn’t usually role of EA to shape the organisation
structure. That may be done by business managers, with the support of HR and
perhaps a “business change” team. The last handles issues to do with changes to
roles and organisation structure.
In a “Functional
Organisation” the Organisation decomposition matches the Functional/Capability
decomposition Employees are grouped in a hierarchy under headings such as
Marketing, Sales, Delivery, Accounting and IT. Each Functional department
manager controls a budget. Each employee has one clear reporting line upwards.
Cross-department projects are possible, but much communication in such a
project must pass through the department heads.
Other organisation structures
are possible. The management
hierarchy may be divided according to region, customer type, product type, or
project. Many enterprises have a
matrix management structure, instead of or as well as a traditional management
hierarchy. A matrix management structure may map Business Function against
Product, Project, Business Service, Customer Type or Region.
BROKE
LINK?http://www.managementtutor.com/difference-between/difference-between-functional-projectized-matrix-organization-structure.html