Understanding TOGAF - Enterprise and Solution architecture...

Avancier

Understanding TOGAF About Functions and Capabilities

More about the structured approach to business architecture

that underpins TOGAF and its artefacts

You may show this slide show without the written permission of the copyright holder,

provided you also show you are opening it from the relevant avancier.website page.

Copyright Avancier Limited 2007 - 2016

Avancier The TOGAF content framework is not currently consistent

Principles: If an

association appears in

an artifact, it is a

candidate for the meta

model.

If an association does

not appear in an

artifact, it is a candidate

for removal.

Copyright Avancier Limited 2012

Role catalogue

Business Function/

Service catalogue

Org/Function matrix

Actor/Role matrix

Organization/Actor catalogue

Organisation decomposition

Business Service/

Product catalogue

Process/Event/Control

/Product catalogue Data Entity/Business

Function matrix Process flow diagram

Business Scenario

(Surely to Role, not Actor?)

Functional decomposition


/Product catalogue


/Product catalogue

The important Function <is bounded by> Service association does not feature in the SOA chapter.

The important Process <realises> Service association is not represented in an Artefact.

The Org/Function matrix (important to structured analysis) is mentioned in the text, and reflected in the meta model, but does not appear in an Artefact.

The meta model lacks the Data Entity-Function association represented in an Artefact.

The meta model lacks the Service-Product association represented in an Artefact.

Actors and Organisation Units are distinct entities in the meta model, yet Actors are defined as including Organisation Units.

Actors being individuals, several associations to Org Unit or Actor would be better to Function or Role.

Avancier How TOGAF’s artifacts document a Business Architecture


Role catalogue

Driver/goal/objective catalogue

Business Function/

Service catalogue

Org. Function matrix

Business Interaction matrix

Actor/Role matrix


Organization/Actor catalogue


Principles catalogue

Business Service/

Product catalogue


/Product catalogue

Data Entity/Business

Function matrix

Data Entity catalogue

Process flow diagram

Role

Org Unit

Function

Actor

Data Entity

Goal Principle !

Driver

Business

Service

Requirement

Process

IS (App)

Service

Atomic Business Activity

http://www.google.co.uk/url?sa=i&rct=j&q=ship+wheel+pic&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwimsvql5cLJAhUJ2BoKHSq-CZ8QjRwIBw&url=https://www.pinterest.com/explore/ship-wheel/&psig=AFQjCNE7nKa7Oxwtob2aj0JLpP_BtgfkjQ&ust=1449338631464201

Avancier TOGAF suggests 3 approaches to Business Architecture

“The level and rigor of decomposition needed

varies from enterprise to enterprise”


Structured Analysis

“Identifies the key business Functions

within the scope of the architecture, and

maps those Functions onto the

Org units within the business.”

Process Modelling

Define high-level Processes/Scenarios

Decompose Processes to activities

Map activities to Roles & Functions

Use-case Analysis

Identifies where Roles use Applications in

performing Process steps, and defines the

required IS (App) Services

Role

Org Unit

Function

Actor

Data Entity

Goal Principle !

Driver

Business

Service

Requirement

Process

IS (App)

Service


http://www.google.co.uk/url?sa=i&rct=j&q=ship+wheel+pic&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwimsvql5cLJAhUJ2BoKHSq-CZ8QjRwIBw&url=https://www.pinterest.com/explore/ship-wheel/&psig=AFQjCNE7nKa7Oxwtob2aj0JLpP_BtgfkjQ&ust=1449338631464201

Avancier TOGAF Principles

► Principles that underpin Structured Analysis, TOGAF and its artefacts,

and relate Functions to Capabilities

1. Functions are independent of Organisation structure (8.4.1, 8.5).

2. Functions impose a structure on Activities sequenceable in Processes

(34.2.1).

3. Functions/Capabilities are defined by Services provided (35.6.3)

4. Functions are used to describe Capabilities (34.2.1).


Avancier 1) Functions are independent of Organisation structure

► Structured Analysis

■ “Identifies the key business Functions within the scope of the architecture,

and maps those Functions onto the Org units within the business.” (8.4.1)

► Business architecture outputs include

■ “Correlation of Organization and Functions — relate business Functions to

Organizational units in the form of a matrix report.” (8.5)

► Organization Unit:

■ “A self-contained unit of resources with goals, objectives, and measures.”

(34.2.1)

► 1 Function/Capability may be mapped to 1 Org Unit, several Org Units,

or parts of several.

► Those Org Units inherit some or all of any target qualities given to

Functions/Capabilities.


Avancier

2) Functions impose a structure on Activities sequenceable in Processes

Atomic activities in Business Processes

May be placed at the bottom of the Functional Decomposition


ArchiSurance: Function Hierarchy / Capability Map

Customer Relations

Open

Policy

Record

Claim

Email

Approval

Handle Claim Process

Record

Claim

Assess

Claim Pay Claim

Email

Approval

Claim Handling

Assess

Claim

Finance

Pay

Claim

Bank

Premium

Product Management

Policy

Definition

Legal

Compliance

Maintain

client

records

A strict (non-redundant) hierarchy.

Function Process

Atomic Activity

Avancier Theory and practice


Process flow

diagram

In theory, every atomic activity in a Process can be placed at the bottom of a

Functional decomposition hierarchy (34.2.1).

In practice

► The Function hierarchy usually stops at a high (3rd or 4th) level

► Some Process models descend to a lower (5th or 6th) level.

Function Process

Atomic Activity

Functional

decomposition

Avancier 3) Functions/Capabilities are defined by Services provided

► “The purpose of the Business Service/Function catalog is to

provide a Functional decomposition…[It] can be used to identify

Capabilities of an Organization…. “(35.6.3)

► Business architecture outputs (8.5) include

■ “Business Functions — a detailed, recursive step involving successive

decomposition of major Functional areas into sub-Functions.”

■ “Correlation of Organization and Functions — relate business

Functions to Organizational units in the form of a matrix report.”


Org Unit

Function

Business

Service

Process

Atomic Activity


Business Function/

Service catalogue

Correlation of Organization

and Functions in a matrix

Avancier Capabilities as Functions

► Function describes units of business Capability at all levels of

granularity (TOGAF 34.2.1)

► Capabilities are typically expressed in general and high-level terms

and typically require a combination of Organization, people,

Processes, and technology to achieve. For example, marketing,

customer contact, or outbound telemarketing. [cf. Function Names]

(TOGAF 3.26)

► This Functional decomposition can be used to identify new

Capabilities required to support business change.

► The purpose of the Functional Decomposition diagram is to show

on a single page the Capabilities of an Organization…. (TOGAF

35.6.3)

► Implication: Functions have all the attributes Capabilities have -

including target qualities


Avancier Capability-Based Planning

► Chapter 32 on Capability-Based Planning has 10 (ten!) references

to Capabilities being cross-organisational.

► It not about improving an Organisation Unit

► It is about improving a named Function (say, HR) regardless of

where it is carried out in the Organisation

► Both Structured Analysis and CBP encourage architects to

■ discuss Functions/Capabilities independently of Org Units.

■ examine business objectives, services and processes before

mapping those to Organisation Units.


“Function describes units of business Capability

at all levels of granularity” TOGAF 34.2.1

Actor (human)

Organisation Unit Function

Role

Capability View Organisation View

Role catalogue

Org/Function

matrix

Actor/Role

matrix

Organization/Actor

catalogue

Organisation decomposition Functional decomposition

Avancier Hmm…

► EA is about human and computer activity systems in which

Actors/components achieve desired effects by playing Roles in Processes.

► A required Capability (say Sales, or Disaster Recovery) can be specified

as a group of

■ required products or Services resulting from Processes performed by

■ Actors/components

► A required Function (say Sales, or Disaster Recovery) can be specified as

a group of

■ required products or Services resulting from Processes performed by

■ Actors/components


Avancier Capability = Function + Target Qualities + Resources Needed

► A Capability is a view rooted in a Function (at whatever level of granularity is

chosen)

It can encompass

as many of the

remaining entities

as you choose


Capability

Entry

Point

Role

Org Unit

Function

Actor

Data Entity

Business

Service

Requirement

Process

IS (App)

Service


Technol’gy

Applicat’n

Avancier So, Capability = Function ++

► In business architecture documentation

► Capability (say Marketing) =

► Function (Marketing) + quality targets + resources needed


Avancier Reader’s challenge 1: What makes Disaster Handling a Capability?

► An enterprise may not formalise disaster handling

■ It may rely on the ad hoc responses of intelligent human Actors when a disaster

happens.

■ It may do little or nothing other than encourage Actors to think about disasters and what

they can do about them.

► Or, it may set out to develop a disaster handling Capability

► Which is to formalise and systemise

■ Nominate a DR Function

■ Define what kinds of disaster are to be anticipated

■ Define targets for recovery from those disasters

■ Define Roles and Processes needed to achieve DR

■ Acquire resources (Actors, components etc.) needed perform DR Roles and Processes

■ Testing

■ Etc.


Avancier Reader’s challenge 2: What makes Innovation a Capability?

► You may perceive an enterprise as being innovative

► But so far, innovations have been down to human inspiration and

motivation to follow them up.

► How to develop a tangible innovation “Capability”?

► The EA concept of Capability implies a degree of systemisation ■ Nominate an innovation Function

■ Define where innovation is sought

■ Define targets for innovation success (e.g. income from new products)

■ Define Roles (if not Processes) needed to achieve innovation

■ Acquire resources (Actors) needed perform the Roles and Processes

■ Etc.


Avancier Capability = Function + Target Qualities + Resources Needed

► Variations of "Capability" appear in “Capability maturity models” and

“Capability based planning”, and in TOGAF (with various meanings)

► DoDAF is built around Capability-based planning. It does not have the

concept of a business Function, because Capability takes its place.

► Some Capabilities may correspond to a Function in a primary business-as-

usual Functional decomposition hierarchy (usually but not inevitably a high-

level Function).

► Other Capabilities (e.g. “Disaster Handling”) might not appear in the

primary Function hierarchy. But you can define other Function hierarchies.

► And you can define a Function independently of any hierarchical

decomposition structure, as a free-standing structural component, a

grouping of any activities you choose.

► So, whether your Capability is named in a Function hierarchy or not, it is

always representable as a Function + target qualities + resources needed.


Avancier

Avancier Methods Abstracting a meta from EA artefacts

Based on the structured approach to business architecture

that underpins TOGAF and its artefacts

You may show this slide show without the written permission of the copyright holder,

provided you also show you are opening it from the relevant avancier.website page.


Avancier

Business Service

Process

Product Event

Actor (human)

Organisation Unit Function

Role

How TOGAF documents a business activity system

If an association does not appear in an artifact, remove it (or else find an artefact).


Data Entity

IS (App) Service

Application

Technology

Service View Data/Info View

Capability View

Process View

IS/IT View

People View

Organisation View

Role catalogue

Driver/goal/objective catalogue

Business Function/Service catalogue Org/Function

matrix

Actor/Role

matrix

Functional decomposition Organization/Actor

catalogue



Business Service/

Product catalogue


/Product catalogue


Function matrix

Process flow

diagram

Architecture Requirements Spec

Business

Scenario Atomic Activity


E.g. which TOGAF products

record these two associations?

Avancier Skills Framework for the Information Age suggests 7 views of EA

► The Views can be centred on the Atomic Business Activities


Business

Environment

Apps &

Technology

Data

Organisation view Process view

Data/Info view

People view

Service view

Technology view

External environs

Role

Org Unit

Function

Actor

Data Entity

Business

Service

Requirement

Process

IS (App)

Service


Technol’gy

Applicat’n

Avancier

Information

Systems

Business

Designing activity systems

► Define required Services, and Processes to deliver them

► Assign activities in Processes to Functions and Roles

► Find Org units and Actors to perform the activities when required


Passive

structure

acted on

Required

behaviour elements

triggered by events, produce results

Process

Process Flow

diagram

Business

Service

Business

Activity

Physical active

structure elements

perform activities

Actor

Org Unit

Organisation

Structure

Logical active

structure elements

group activity types

Function

Role

Functional

Decomposition

Role catalogue

Assigned to Realised by

Entity

Artifact

Business/Function

Service cat.

IS (App)

Service Data Entity

Data Entity/

Business

Function matrix

IS Service

catalogue

Application

Application

Portfolio Cat

Application

Interface

Application

Portfolio Cat

Use Case

diagram

Actor/Role

matrix

Org /Function

matrix

Avancier Design sequences used in EA

Function: externally, a group of service types; internally, a group of activity types

Role: externally, a group of service types; internally, a group of activity types


Business

Business

Process

Business

Service

Required

Behaviour

Logical

Structure

Function

Role

Assigned to “Physical”

Structure

Actor

Org Unit

Realised by

Data

Technology

Applications

Platform

Service

IS (App)

Service

Platform

Application

Application

Data Store

Platform

Interface

Application

Interface

Data Model Location

Nothing is really

physical in EA, but

when implemented,

a physical element

must be

addressable

Avancier Core artifacts: describe architectural entities and relations between them


2 Context / Precursors

Driver/Goal/Objectives cat.


Stakeholder catalogue Requirements catalogue Business Scenario diagram Solution Vision diagram

4 Business Architecture Business Function/Service catalogue

Functional Decomposition diagram

Organisation/Function matrix

Organization/Actor structure Actor/Role matrix Process catalogue

Process Map diagram

Process Flow diagram

Role/Information Service catalogue

5 Data Architecture

Data Entity catalogue Data Entity/Business Function matrix Data Store catalogue

Logical Data Model diagram Data Dissemination diagram

CRUD diagram

7 Applications Architecture Information Services catalogue

Application Portfolio catalogue

Data Flow catalogue

Application/Data Entity matrix Application/Function matrix Application Communication diagram Application Use Case diagram

Application Platform Service catalogue

9 Infrastructure (Tech) Architecture

Technical Reference Model

Technology Standards catalogue Technology Portfolio catalogue

Application Technologies diagram

Deployment diagram

Networked Computing Hardware diagram

Communications Engineering diagram

10 Migration Planning

RAID catalogue

Value/Cost/Risk Grid

Migration Path

Road Map

Avancier

Applications

Infrastructure

Technology

Data / Information

Business

Actor

Function

Process Role

Org Unit Business

Service

Info. Service

Platform

Application

Application

Interface

Platform

Interface

Application

Platform

Service

Data Store Data Entity

Driver/goal/objective

catalogue Business Function/Service

catalogue

Organisation/Function matrix

Actor/Role matrix


diagram

Organisation/Actor structure


Process catalogue


Function matrix

Data Entity catalogue

Process Map diagram

Data Dissemination matrix

Logical Data Model

Requirements catalogue

Info Services catalogue

Abstracting a meta model from the artifacts


Requirement

Objective

Goal Principle

Aim

Application Platform Service catalogue

Data Flow catalogue Application/Data Entity matrix Application/Function matrix Application Communication diagram

Process Flow diagram

Use Case diagram

Application Portfolio catalogue

Technology Portfolio catalogue

Data Store catalogue

Technical Reference Model

Role /Info Service catalogue

I/O Data Flows

Avancier AM meta model

► As complete as

seems reasonable


Infrastructure

Motivation

Data / Information

Applications

Business

Actor

Function

Process

Output

Rule

Role

Input

Org Unit Business

Service

IS (App)

Service

Platform

Application

Application

Interface

Platform

Interface

Application

Platform

Service

Data Store Data Entity

Requirement

Objective

Goal Principle

Concern

Stakeholder

Location

Driver Mission Vision

Policy

Rule

Directive Aim

Force

Node

Assigned to Realised by

Avancier


Methods and resources at http://avancier.website

► Avancier Methods are

useful with all architecture

frameworks that share

similar ends and means

Avancier Methods

BCS E&SA reference model

TOGAF

The Open Group

IBM’s view EA

EA as Strategy”

MIT

CSC’s domains of change (POLDAT)

ArchiMate

Language Framework

Date post:	01-May-2018
Category:	Documents
Upload:	phamquynh
View:	272 times
Download:	5 times

Understanding TOGAF - Enterprise and Solution architecture...

Documents