Avancier Methods

Business Architecture with TOGAF & ArchiMate artefacts

One of about 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 22/01/2017 13:44

 

Click here for illustrations of the diagrams mentioned below.

Approach

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.

Analyse the business architecture

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.

1 Form an organisation view of the business

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.

2 Form a capability view of the business

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.

3 Form a value stream or process view of the business

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.

4 Form a people view of the 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.

5 Form a service or product view of the business

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.

6 Form an Information/Data view of the business

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.

7 Form an application view of the business

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.

Design the target business architecture

 

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.

http://www.managementtutor.com/difference-between/difference-between-functional-projectized-matrix-organization-structure.html

Two pictures that may help