Avancier
Methods
Business Architecture with TOGAF & ArchiMate
artefacts
One of about 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 21/05/2017 22:27
Click here for illustrations of the diagrams mentioned below.
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 narrows the focus of the baseline analysis needed.
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 to 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 or 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 logical structure in the form of 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 by
combining top-down and bottom up approaches. High
level abstract models are never right first time. Alternately
elaborate and abstract to ensure that a higher level model is well formed. It
should be manageable and accurate abstraction of lower levels, containing
elements at a consistent level of granularity, It
should 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. 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 organise the
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.