TOGAF uses of abstraction

One of more than 200 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 24/12/2016 19:07

And one of several papers on the home page about the basic terms and concepts used in architecture frameworks.

·         Enterprise and Solution  >  Socio-cultural EA  >  EA and Strategy

·         Building Blocks, Interfaces and Services  >  TOGAF-ArchiMate alignment

·         Architecture and Design  >  TOGAF uses of abstraction

·         Architecture and System  >  TOGAF metaphysics

 

You might find it helpful to read the TOGAF-ArchiMate alignment slide show before this paper, or after it.

 

The Architecture and Design paper outlined six ways to abstract an architecture from more detailed design.

This paper identifies where these abstraction varieties are used in TOGAF.

The table below is drawn from the TOGAF-ArchiMate alignment slide show.

EA domains

EA levels

Enterprise Continuum scales

Delegator

Composition

Generalisation

Idealisation

Business

Information Systems

Technologies

Enterprise/Strategy

Segment

Capability

Foundation

Common System

Industry

Organisation

Requirements

Architecture continuum

Solution continuum

Deployed solutions

Servant

Decomposition

Specialisation

Realisation

Abstraction by composition

The Open Group’s Architecture Framework (TOGAF) is a management framework for work to change business systems.

It is focused on the architectural definition of business systems – not necessarily enterprise level or enterprise wide.

It is generalised sufficiently that it may be used at different levels of scope or composition.

It suggests architecture definition may be done at three levels of scope and detail.

And implies a one-to-many composition relationship between a higher and lower level in this structure.

 

Composition

Enterprise/Strategy

Segment

Capability (increment)

Decomposition

Abstraction by encapsulation of system behaviour, structure and data

The Open Group use this idea in defining open standards.

They define the open standard for the operating system called UnixTM by defining the discrete services required of it.

 

TOGAF defines systems, “building blocks” and “components” by defining the services required of them.

The table below is a simplified version of what you can find in the TOGAF-ArchiMate alignment slide show.

 

TOGAF

Required behaviours

Building Blocks

External view

Services

Internal view

Roles/Components

 

Services typically consume some input data and produce some output data.

Business systems store some of the input data for future use.

Business system architects must address the location(s), confidentiality, integrity and availability of stored data.

Abstraction by separation of parallel views

Architects commonly define parallel views of a system, each view omitting details found in the other views.

TOGAF proposes building a library of “viewpoints”, defining how and why to draw different views for different stakeholders

Abstraction by delegation from clients to servers

Architects often simplify a complex system by organising it into a hierarchy of client and server layers.

Clients abstract from servers by delegation - by requesting services without knowledge of the servers’ internal structure or workings.

This idea is used in network architectures, software architectures and business architectures.

ArchiMate presents the primary enterprise architecture domains as client-server layers.

Delegator

Business

Applications

Technologies

Servant

 

The table below is a simplified version of what you can find in the TOGAF-ArchiMate alignment slide show.

ArchiMate

Behaviour elements

Active structure elements

TOGAF

Service portfolios

Architecture building blocks

Solution building blocks

Business

Business Services

Functions, Roles

Organisation Units, Actors

Applications

IS or Application Services

Logical Application Components, Interfaces

Physical Application Components

Technologies

Platform or Technology Services

Logical Technology Components, Interfaces

Physical Technology Components

Abstraction by generalisation and idealisation

TOGAF expects architects to comply with generic reference models, design patterns, principles and standards.

And to look for what is general to an industry (say telecoms), general to a function (say accounting) and common to all (say, email).

TOGAF’s “enterprise continuum” classifies system elements using both generalisation and idealisation.

Generalisation

Idealisation

Foundation

Common System

Industry

Organisation

Requirements

Architecture continuum

Solution continuum

Deployed solutions

Specialisation

Realisation

 

TOGAF plots 3 degrees of idealisation (bottom to top) from deployed solutions against 3 degrees of generalisation (right to left) from a specific enterprise’s organisation.

 

Generalisation

Foundation

Common system

Industry

Organisation

Specialisation

 

Idealisation

Idealisation

 

Requirements

 

 

Requirements Repository

Logical

Architecture Building Blocks

Vendor-neutral / standard

 

 

Vendor-neutral / unique

Architecture Repository

Physical

Solution Building Blocks

Vendor-specific / standard

 

 

Vendor-specific / unique

Solutions Repository

Real

Operational Building Blocks

 

 

Deployed solutions

 

Realisation

 

 

 

Realisation

 

Generalisation

Foundation

Common system

Industry

Organisation

Specialisation

 

In TOGAF, architecture building blocks are documented descriptions of system elements that support or enable the provision of business services.

Rather than contrast architecture with design, TOGAF draws a dividing line between architectures and “solutions”.

It proposes architectures are abstracted idealisation from “solutions” in very particular way.

 

Architects in phases A to D define architecture building blocks in a vendor-independent way.

That doesn’t mean they ignore vendors or the technologies they sell.

It means only that they strive to document and maintain vendor-neutral specifications of required systems and components.

In phases E to G, they select or define vendor-specific solution building blocks to implement the logical architecture building blocks.

 

This way of distinguishing the terms “architecture” and “solution” seems peculiar to TOGAF.

Outside of TOGAF, it is common to define an architecture that is vendor specific.

For more on the term “solution architecture”, read the companion “Enterprise versus Solution Architecture” paper.

 

This last section of this paper distinguishes vendor-independent from technology independent.

Can an architecture be technology independent?

Some say an architecture should be technology-independent. What does that mean? And is it true?

 

An architecture is an abstract design of a new thing, or description of an existing thing.

The most definitive version of an architecture is to be found in approved documentation.

 

A technology is a machine or device manufactured to assist or enable an activity.

An information technology is a technology made to assist or enable a data processing activity.

 

Business roles and processes have always been shaped by the information technologies available.

Since the start of the “information age”, business roles and processes have depended on digital information technologies.

 

Enterprise and solutions architects have to understand what technologies can do for business actors.

At the same time, they want to minimise the technical detail in architecture documentation presented to clients.

Some say architecture definitions should be idealised or logical in the sense of being technology independent.

The fact is, every professional architect has to understand the capabilities and capacities of technologies their architecture depends on.

If they don't, and things go wrong, they should be sued for lack of due diligence.

(In the absence of litigious clients, amateur architects can get away with murder.)

 

The graphic below may be misread to imply a business architecture is independent of infrastructure technology.

Clients delegate to servers, but also depend on them.

You cannot design a client layer with no understanding of what its server layer(s) can do.

Cient-server hierarchy

Architecture domain layers

Client layer

Business architecture

Business roles, processes and services

Server and Client layer

Information system architecture

Business applications and services

Server layer

Infrastructure technology architecture

Platform technologies and services

 

A business architect has to make presumptions about what technologies do to support and enable business roles, processes and services

Modern business processes depend on the use of client devices, data servers, local and/or global networks.

Customer behavior is affected by whether the enterprise can roll back a failed business transaction using transaction manager.

 

In short, most if not all enterprise architecture definition depends on some or other information technology.

 

For more: on abstraction of description from reality, architectures from systems, read “Architecture versus system”:

On the distinction between enterprise and solution architecture”, read “Enterprise and Solution”.