TOGAF – general patterns and principles – architectural design processes

 

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.

 

This is the second of four related papers at http://avancier.website.

Contents

Preface. 1

Patterns in TOGAF’s architectural specification. 2

The general process for formalisation or digitisation of capabilities. 3

The general process for rationalisation of a messy system estate. 3

The general process for designing and changing a business capability in a cycle of ADM... 3

What about data / information architecture?. 4

 

Preface

TOGAF and ArchiMate presume the design of a capability, function or system runs:

·         from abstract to concrete - logical specification before physical implementation

·         from external to internal – required services/products before internal processes and roles/actors/components

·         from behaviour to structure – sequences and process sequences before roles/actors/components.

 

And for enterprise architecture, they add another sequence: from business to technology - human actors before computer actors.

There can be reasons to deviate from these sequences in practice.

But methods for governing design and implementation against a specification usually start with these presumptions (which reflect General System Theory principles).

This paper introduces patterns TOGAF applies to specification documentation and to design processes.

Patterns in TOGAF’s architectural specification

EA is about business capabilities, about human and computer activity systems in which actors/components have the ability to achieve desired effects by playing roles in processes.

A required capability can be specified as group of required services (accessible via interfaces) to be delivered by actors/components able to perform the necessary processes.

 

Specification by encapsulation of capabilities, systems or components is a fundamental principle, predating SOA and OO design.
Service-oriented specification has been a principle of The Open Group since it was formed, and underpins TOGAF.

The table below applies a general pattern to architectural entities in the TOGAF meta model.

Passive Structure

External Behaviour

Internal Behaviour

Logical Active Structure

Physical Active Structure

Generalisation

Object

Service

Process

Logical Component

Physical Component

Business

Event, Product

Business Service

Process

Function

Organisation Unit

Role

Actor

Information System

Data Entity

Information Service

 

Logical App Component

Physical App Component

Technology

 

Platform Service

 

Logical Tech Component

Physical Tech Component

 

You can specify a Logical Component by naming it and specifying its Interface, which means listing the discrete Services it offers in its “service portfolio”.

·         A "Logical Technology Component" is specified by the "Platform Services" it offers.

·         A "Logical Application Component" is specified by the "Information System Services" it offers.

·         A business “Function” or “Role” can be specified by the "Business Services" it offers.

 

Read TOGAF – business capabilities and functions for more detail about relationships in the business architecture meta model.

 

Many people don’t seem to realise that TOGAF defines Services in the architecture requirements specification outside and before defining Processes and Components in the architecture definition document.

This reflects the natural design sequences mentioned in the preface above.

The design processes used in TOGAF are generalised below.

The general process for formalisation or digitisation of capabilities

This process can be generalised as:

 

Design the target

1.      Define required Services

2.      If need be, design Processes to deliver the required Services.

3.      Assign required Services and/or Process steps to logical Interfaces, Functions or Roles.

4.      Change, hire, buy or build physical Actors/Components to realise logical Interfaces and perform process steps.

The general process for rationalisation of a messy system estate

This process can be generalised as:

 

Analyse the baseline

1.      Catalogue baseline Actors/Components (org. units, functions, roles or actors).

2.      Abstract the discrete Services provided by those baseline Actors/Components.

3.      De-duplicate baseline-provided Services 

 

Design the target

5.      Define required Services

6.      If need be, design Processes to deliver the required Services.

7.      Assign required Services and/or Process steps to logical Interfaces, Functions or Roles.

8.      Change, hire, buy or build physical Actors/Components to realise logical Interfaces and perform process steps.

The general process for designing and changing a business capability in a cycle of ADM

The ADM interleaves three natural design sequences: external before internal, behaviour before structure, and business before IT.

 

Business architecture

·         Define new/changed business services required.

·         Define logical business processes and/or functions to provide required business services.

·         Define business roles to perform elementary business process steps and/or business functions.

·         Change, hire, buy or build organisation units to manage business roles (revise business organisation structure as need be).

 

Information system architecture

·         Define new/changed information system services (use cases) required.

·         Define I/O data flows (in service contracts or use case headers) and data stores.

·         If need be, define logical application processes (as in use case paths)

·         Change, hire, buy or build physical applications to support and enable logical use cases (revise business application portfolio as need be).

 

Technology architecture

·         Define new/changed platform services required (revise the TRM as need be).

·         Don’t define logical platform processes, since they are given by vendors behind APIs.

·         Hire or buy physical technologies to provide required APIs (revise technology component portfolio as need be).

What about data / information architecture?

Business systems can be seen as formalised social systems.

Businesses created and used data long before computers

In ancient Egypt, business data was written to and read from clay tablets.

Business communication requires formalization of data types used in messages and data stores.

 

In theory, data architecture is part of every other architecture domain

Since business capabilities were computerised there have been:

(1)   data flows between human roles (oral, on paper forms, in emails...).

(2)   data flows between human roles and business applications (HCI or UI).

(3)   data flows between business applications (point to point, or via middleware)

(4)   data flows between business applications and platform applications (notably databases)

(5)   data flows between platform applications.

 

Data or information?

The terms “data” and “information” are used loosely and interchangeably in many contexts.

Life is too short to debate the many different distinctions that people draw between these terms.

One tradition in EA frameworks is that information is data at the point of creation or use by humans (level 2 above).

Data is what appears only within the computer activity system (levels 3, 4 and 5 above).

It can be said that information is more than data; it is the application of a language (data types and grammar) to data by an actor who creates or uses that data.

Read Information Theory for more; but we’ll stick with “data” here.

 

In practice, data architecture is about handled by business applications

The focus of data architecture in EA is on business data that is digitised or digitisable (levels 2, 3 and 4 above.)

And so, data architecture is wrapped up with “application architecture” under “information systems architecture”.

Note: data is plural, and it should be applications rather than application.

 

Data flow or interface?

Data flows are called interfaces in what TOGAF calls an interface catalogue (at level 3 above).

But nowadays the term interface is more usually a list of services provided or required.

 

Defining data to support Information System Service definition

Information System Services may be defined in form of “use case descriptions”.
A use case description records a Process (main and exception paths) wrapped up inside a service contract.
You might simply name core use cases and map them to business Roles, Processes or Functions.
Suppose you need to specify the use case in detail, with inputs, outputs, pre and post condition?
Then you need to define a logical data model also, in order to define the business-specific terms and concepts used in service contract or use case description.

That logical data model may act as a specification for a physical data store.

 

Data flow or service?

Data flows are probably the most important entity not mentioned explicitly in the TOGAF meta model.

The meta model includes data components (data store structures) but not data flows.

It may be assumed input and output data flows are defined inside service contracts (for business, information system and platform services).

But do people want to create a service every time they want to define a data flow?

 

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0           18/08/2013 11:18

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see  http://creativecommons.org