Business functions and processes (coordinating structure and behavior views)

One of about 300 papers at http://avancier.website .Last updated 29/01/2017 19:25

This paper explains some basic principles used in the modelling of human and computer activity systems

References are to TOGAF 9.1, UML 2.4.1 and VDML 1.0.

Business systems

General system theory emerged out of thinking by sociologists, biologists and psychologists.

It was noticed that different disciplines have similar ideas about system structure and behavior.

· Behaviors run over time - from start to end, or cyclically.

· The active structures that perform those behaviors - locatable in space.

General system theory distinguishes structures from behaviors, as shown in this table.

Domain	Behavioral concepts	Active structure concepts
Biology	Breathing, running, sweating	Hearts, lungs, blood vessels
Sociology	Acting, communicating	Actors
Software	Processes or operations	Components, modules, classes, objects
UML (p 694)	The behavior (of a role or interacting roles) over time Sequences of actions, interactions, life histories or actors	The structure of a system irrespective of time Relationships between roles that perform behaviors
TOGAF 9.1	Services that consume and produce materials and information. Processes need to deliver the services	The network of interoperating building blocks. Building blocks interact as providers and receivers of services

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

Behavior view of a business

TOGAF’s business architecture outputs include:

· “Business services: the services that the enterprise and each enterprise unit provides to its customers, both internally and externally”

· “Business processes, including measures and deliverables”

Services

A service is discretely requestable behavior that transforms input materials or information into outputs of value to a recipient.

TOGAF encapsulates structural building blocks by defining the services they are required to provide.

“For each building block, build up a service description portfolio as a set of non-conflicting services.”

“A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.)”

Processes

A process is a sequence or flow of activities leading to the delivery one or more business services.

TOGAF uses the term scenario for end-to-end processes involving human and computer actors.

Each step in a scenario may be divided into shorter process steps, and so on.

Process decomposition usually stops at the level where one action cam be performed by one actor playing one role.

Structure view of a business

TOGAF’s business architecture outputs include:

· “Correlation of organization units [cf. physical components] and functions [cf. logical components]”

· “Business functions: a detailed, recursive step involving successive decomposition of major functional areas into sub-functions”

· “Business roles, including development and modification of skills requirements”

Physical business structure

An organization unit is a unit in the management structure able to fulfil one or more logical functions

Structured analysis of an existing organization structure may proceed thus.

1. Draw an organisation chart showing the structure of organisation units (with human actors at the bottom).

2. Replace the human actors by the atomic business activities performed in each unit.

3. List and de-duplicate the atomic business activities

4. Group atomic business activities into logical functions using some cohesion criterion, such as skills and/or resources.

5. Successively group narrower functions into broader functions until you have built a complete hierarchical structure.

The result is what may be called a “functional organisation structure”, but it is purely logical.

Logical business structure - Functional decomposition diagram

A function is logical grouping of activities, performable by one or more organization units.

“The purpose of the Functional Decomposition diagram is to show on a single page the capabilities of an organization that are relevant to the consideration of an architecture.

By examining the capabilities of an organization from a functional perspective, it is possible to quickly develop models of what the organization does without being dragged into extended debate on how the organization does it.

Once a basic Functional Decomposition diagram has been developed, it becomes possible to layer heat-maps on top of this diagram to show scope and decisions.

For example, the capabilities to be implemented in different phases of a change program.” TOGAF 9.1

Everything VDML says of a capability map can be said of a functional decomposition hierarchy.

· It arranges business functions/capabilities (needed to deliver results the business desires) in a hierarchical structure.

· It structures what the business does, in progressively more detail at each level of the hierarchy.

· It enables people to start with a broad discussion and then dive into more detail where needed.

· It is defined using function/capability names that help to establish a common vocabulary across the business.

· It is analyzed to identify functions/capabilities that require improvement - often coloured coded on a diagram as a “heat” map.

· It is more stable than the business processes and organisation’s management structure.

· It gives the architects a logical business structure, to which other architectural entities can be mapped.

VDML goes on to say: “There does not appear to be a generally accepted specification of additional detail to a capability map model”.

Which suggests the authors are ignorant of the “functional decomposition” and “structured analysis” techniques mentioned in TOGAF.

Read TOGAF and VDML terminologies for more on VDML.

Coordinating structure and behavior views of a business

TOGAF has no explicit concept of an atomic action or activity – only higher level activity groups such as functions and processes.

However, its concepts can be defined in terms of such activities.

	Behavioral or dynamic view	Structural or static view
UML (p 694)	The behavior (of a role or interacting roles) over time Sequences of actions, interactions, life histories of actors	The structure of a system irrespective of time. Relationships between roles that perform behaviors
TOGAF 9.1	Service: A unit of behavior that transforms input materials or information into outputs of value to a recipient Process: A sequential flow of activities leading to the delivery one or more business services.	Function: A logical grouping of activities, performable by one or more organization units	Logical Building Blocks
TOGAF 9.1		Organization unit: A unit in the management structure able to fulfil one or more logical functions	Physical Building Blocks

Business functions and processes (and roles) group human/business activities in different ways for different purposes.

It is important to understand these views can be coordinated by the appearance of the same atomic actions in each.

A principle of structured analysis is that we can draw one structural and many behavioral views of the same atomic activities.

The primary structural view is called the functional decomposition hierarchy (aka capability map).

The many behavioral views are called process models (aka scenarios, value streams).

The atomic action in a process model is traditionally known as a one-person one-place one time (OPOPOT) activity.

It is always possible to place each OPOPOT activity under a function at the bottom of a functional decomposition hierarchy.

This table shows how atomic actions coordinate the structural and behavioral views

Structure nodes Bevaviors	Function A	Function B	Function B
Process A	Activity ->	Activity ->	Activity
Process B		Activity -> Activity
Process C	Activity		<- Activity

In practice, the functional decomposition may be incomplete in its breadth and/or depth.

The functional decomposition depth usually stops short of the atomic activities in the processes.

Still, the structured analysis principle remains valid and necessary if the structural and behavioral views and to be coordinated.