TOGAF core concepts - with refined definitions
Making the glossary more coherent and consistent

Graham Berrisford. Last updated 29/06/2017 23:28

 

This paper discusses the core concepts defined in chapter 3 of TOGAF 9.1.

It explains how to read the core concepts as adding up to a coherent and consistent whole.

It organises the concept definitions in a coherent structure, and adds a few missing ones.

The associated slide show explains the same in a more graphical way (recorded in a TOG webinar on the 14th of June 2017).

Specific rationales for particular change requests are explained in the slide show – not in this paper.

 

Contents         

Principles that underpin TOG standards in general and TOGAF in particular. 1

Problems and proposals regarding concept definitions. 3

Core concepts: BUILDING BLOCKS. 4

Core concepts: SERVICES and DATA.. 6

Other Core Concepts in TOGAF.. 7

References to supporting research and core meta models. 14

 

Principles that underpin TOG standards in general and TOGAF in particular

TOGAF says Enterprise Architecture is about systems.

“EA regards the enterprise as a system, or system of systems”

“Architecture descriptions are formal descriptions of a system.”

“Systems are built up from … building blocks [that] interoperate with other building blocks”

 

What is a system? General System Theory describes a system in terms of general concepts and principles.

“Systems concepts include: system-environment boundary, input, output, process, state….”   Principia Cybernetica

“The general notion in communication theory is that of information.” Bertalanffy

 

Enterprise architecture is concerned with:

·         Input flows: consumed from external entities

·         Output flows: provided to external entities (as a result of services offered).

·         Internal flows: that pass between subsystems (as a result of internal services requested or offered).

·         Information (state data) that must be remembered to process input flows and produce output flows.

 

Standards from The Open Group apply further general system theory principles.

There follow some small extracts from the longer paper EA as applied system theory.

 

Holism

Holism means studying how the parts (aka building blocks) of a system interoperate to the benefit of the whole.

This includes how processes connect building blocks so as to maintain the integrity of a system.

And what passes between building blocks by way of energy, materials or information.

 

EA was conceived in the 1980s in reaction to the proliferation of silo systems that duplicated each other and did not interoperate.

EA strives for systemic coherence, which implies:

·         System integration and standardisation

·         Integrity: data consistency, single version of the truth

·         Coordination: sharing of information

·         Rationalisation: parts should not duplicate, conflict or compete with each other.

 

The primacy of behaviour

This means focusing first not on building blocks (e.g. brain, heart, lungs and legs) but on regular processes (e.g. breathing, running) they cooperate in.

The Open Group promotes service-orientation – defining standards and systems in terms of service portfolios.

TOGAF abstracts Services from Building Blocks using the terms in this table.

Generic meta model

Generic entities

Business

Applications

Technology

Required behaviors

Services

Business Services

IS/Application Services

Platform/Technology Services

Structures

Building Blocks

Functions & Roles

Application Components

Technology Components

 

Thus, TOGAF starts not from the structures of a system but from the behaviors required of it.

It applies this principle first to human activity systems, then to applications, then to platform technologies.

Phases A and B start by defining the required business services, and the end-to-end business processes (aka scenarios or value streams) needed to provide them.

They also define flows of materials and information between the units of business (shown in a “node connectivity diagram”).

Phase C proceeds by defining what business processes need by way of information system/application services from business applications.

These application services (aka use cases or user stories) are partly or wholly digitised

Phase C also defines data created and used to perform business processes, and to provide application services.

 

Information flows

The Open Group’s vision is to “achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”

Its mission has been “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

TOGAF promotes these principles, along with MIT’s “business operating model” concept of process standardisation and process integration across the enterprise.

 

Abstraction of descriptions from realities

The Open Group’s principle is to specify systems by abstracting "open" and "vendor-neutral" specifications from particular implementations.

TOGAF applies this principle, first by service-oriented specification, and then by documenting the architecture of a system at two levels.

In each architecture domain, it abstracts logical specification from physical specification, using the terms in this table.

Generic meta model

Generic entities

Business

Applications

Technology

Required behaviors

Services

Business Services

IS/Application Services

Platform/Technology Services

Logical structures

Logical Building Blocks

Function & Roles

Logical Application Components

Logical Technology Components

Physical structures

Physical Building Blocks

Organisation Units & Actors

Physical Application Components

Physical Technology Components

 

This table shows how chapters 34 to 41 distinguish the two levels of specification using different terms.

ADM phase

34 Meta model

36 Deliverables

37 Building Block

39 Enterprise Continuum

41 Enterprise Repository

B, C and D

Logical components

Architecture Definition Document

Architecture BBs

Architecture Continuum

Architecture Repository.

E

Physical components

Architecture Roadmap

Solution BBs

Solutions Continuum

Solutions Repository.

 

Drawing the table above helps people to see that TOGAF draws a coherent and consistent division between the two levels of system specification.

Being an enterprise architecture framework, TOGAF focuses attention on the abstract level.

 

The next table identifies four varieties of abstraction employed in both TOGAF and ArchiMate standards.

Architecture domains

Architecture levels

Enterprise continuum

Delegation

Composition

Generalization

Idealization

Business

Applications & Data

Technologies

Enterprise/Strategy

Segment

Solution/Capability

Foundation

Common System

Industry

Organization

Requirements

Architecture continuum

Solution continuum

Deployed solutions

Service provision

Decomposition

Specialization

Realization

 

Beware that TOGAF uses the terms Solution and Capability differently in different places.

Problems and proposals regarding concept definitions

Enterprise and solution architects work in a vocabulary hell

In UML, Service and Interface are synonyms; Actor and Role are synonyms.

By contrast, TOGAF and ArchiMate distinguish Service from Interface, and Actor from Role.

 

How to help contributors ensure the coherence and consistency of TOGAF?

First there has to be agreement to the definitions of core and general terms and concepts.

And then, authors should align their terms and concepts with those definitions wherever possible, even if they use different words.

 

The baseline glossary

The TOGAF 9.1 definitions in chapter 3 are not as coherent and consistent with each other or TOG principles as they can be.

The definitions are not applied consistently in the text (e.g. “Building Block” became confused in migration from TOGAF 8 to 9.)

A few core entries are missing (e.g. “Service” is needed, being the essential generic companion to the generic “Building Block”.)

Some entries could be clearer and more definitive (e.g. “Constraint” has an obscure example and disregards the general examples that appear many times in the text.)

It has a handful of redundant entries (e.g. “Performance  Management” appears only once in the text, and with a different meaning.)

 

The danger is ever-increasing incoherence and inconsistency as each new contributor uses their own vocabulary and implicit meta model.

 

The proposal

The concepts defined in chapter 3 must add up to a coherent and consistent whole.

It helps to apply the CBD and SOA principles that underpin The Open Group standards in general and TOGAF in particular.

The proposal below:

·         Clusters related glossary entries under a dozen headings (this reveals inconsistencies and duplications).

·         Adds some missing entries; remove some redundant entries.

·         Edits the remaining 70 entries (though some are minor changes)

·         Defines entries so as disambiguate them.

·         Defines entries wrt TOGAF meta model entities and examples.

·         Defines entries without reference to specific TOGAF artifacts (so the glossary is independent of artifact choice).

·         Aligns a few entries more closely with ArchiMate.

Core concepts: BUILDING BLOCKS

Component-Based Design principles underpin business system definition in TOGAF.

“Systems are built up from … building blocks [that] interoperate with other building blocks”

“It is important that the interfaces to a building block are published and reasonably stable”

“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.)”

IOW, a system is a collection of interacting building blocks that perform processes so as to deliver services in response to discrete requests/triggers/input flows.

 

TOGAF’s Building Block chapter sets out the general Component-Based Design (CBD) principles that underpin TOGAF. 

Unfortunately, one sentence was inserted in the migration from TOGAF version 8 to 9

This one sentence mistakenly confused building block with meta model entity.

It undermined the rest of the building block chapter, and obscured the principles on which TOGAF is based.

So, it is important to disregard that sentence – number 2 in the list below.

 

1.      A building block is a package of functionality defined to meet the business needs across an organization.

2.      A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)

3.      A building block has a defined boundary and is generally recognizable as ‘‘a thing’’ by domain experts.

4.      A building block may interoperate with other, inter-dependent, building blocks.

5.      A good building block has the following characteristics:

6.      It considers implementation and usage, and evolves to exploit technology and standards.

7.      It may be assembled from other building blocks.

8.      It may be a subassembly of other building blocks.

9.      Ideally a building block is re-usable and replaceable, and well specified.

 

Edited: 21 Building Block

An encapsulated unit of business, application or technology capability.

A subsystem or component that is potentially re-usable.

It interacts with other building blocks by exchanging flows of materials and/or information, in the course of consuming and providing services.

It can be defined iteratively.

E.g. name a coarse-grained building block, lightly describe it, relate it to other building blocks in descriptive artifacts, identify coarse-grained services it provides, and perhaps specify its full service portfolio.

Then, decompose it into finer-grained building blocks and define each in the same manner, along with finer-grained services

 

Edited: 9 Architecture Building Block (ABB)

A relatively logical and vendor-neutral specification of a building block.

 

Edited: 66 Solution Building Block (SBB)

A relatively physical and vendor-specific specification of a building block, which realises a more logical building block specification.

 

Edited: 61 Role

A logical business architecture building block.

A description of the activities that can be assigned to an actor.

Accompanied by the abilities, knowledge, experience and resources that actor will need.

A role may be played by one or more actors.

 

Edited: 2 Actor

An individual that plays one or more roles.

An actor may be a named person (customer, supplier or employee), organization unit, or system.

An internal actor plays a role in a process inside a system.

An external actor interacts with a system by supplying input or receiving output.

 

Edited: 23 Business function/capability

A logical business architecture building block.

A logical organization unit; a discrete capability of a business.

A logically cohesive group of business services and activities (not a sequence).

High-level functions might include marketing, customer service, HR and finance.

A function hierarchy arranges higher and lower level functions in a structure with no duplicated elements.

The function hierarchy should be stable, and therefore useful as way to categorise other enterprise architecture entities, especially applications.

It may be mapped to units of the (usually more volatile) organization structure, sometimes one-to-one, sometimes in a more complex relationship.

The elementary functions may be organised sequentially in process flows.

 

Edited: 26 Capability

A business architecture building block.

It usually corresponds to a high-level Business Function (see examples above).

However, it may be further defined in terms of the goals it meets and the resources it needs, including and people and technologies.

 

Edited: 3 Application Component

An information systems building block.

A software system that provides Information System Services to support, enable or automate business activities.

A business application such as an accounting, payroll or CRM system.

It usually maintains a data component.

It is enabled by platform/technology services provided by technology components.

 

Addition: Data Component

An information systems building block.

A persistent data structure, composed of interrelated data entities, or the container that encapsulates it.

 

Addition: Technology Component

A technology building block.

A generic infrastructure technology that supports and enables application or data components (directly or indirectly) by providing platform/technology services.

 

Please now complete this short push-button survey on change requests:

·         BUILDING BLOCKS https://www.surveymonkey.co.uk/r/RSMZ55X

Core concepts: SERVICES and DATA

Building blocks may be related directly in diagrams (implying services requested and consumed).

The name of specific services are often suppressed from diagrams - as a level of detail too far.

Nevertheless, Service-Oriented Architecture principles underpin business system definition in TOGAF.

A system is a collection of interacting building blocks that perform processes in response to inputs that request services, which are grouped for access in interfaces

Again, TOGAF says:

“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.)”

 

TOGAF abstracts Services from Building Blocks using the terms in this table.

Generic meta model

Generic entities

Business

Applications

Technology

Required behaviors

Services

Business Services

IS/Application Services

Platform/Technology Services

Structures

Building Blocks

Functions & Roles

Application Components

Technology Components

 

Edited: 63 Service Orientation

Viewing a business or other system in terms of services provided and consumed.

Defining systems and building blocks by service portfolios.

Defining services in service contracts that define triggers, inputs and outputs but encapsulate processes and components needed.

Looking to reuse services in different processes.

Services may be distributed and invoked across a network via a façade or interface.

 

Redundant: Service Oriented Architecture (SOA)

The definition is questionable, and is not needed if Service Orientation is defined as above.

 

Addition: Service portfolio

A collection of services, potentially an interface definition.

It is used in TOGAF to define the requirement for a building block or system.
 

Addition: Service

A repeatable business activity; a discrete behavior that a building block may be requested or otherwise triggered to perform.

Examples in TOGAF include check customer credit, provide weather data and consolidate drilling reports.

It serves a client or customer by delivering an output or changing system state.

It can be defined in a logical service contract that defines input and output flows and/or state changes.

It encapsulates any building block that processes the input and output flows.

It may be one of several services in a service portfolio or service level agreement.

It may be invoked via an interface.

It can be coarse-grained (build a house) or fine-grained (retrieve an address).

 

Edited: 25 Business Service

A discrete behavior requestable from a business (recruit an employee, complete a project, fill a pothole).

It supports or enables activities outside the business function/capability under consideration.

It can be coarse-grained (build a house) or fine-grained (approve application).

It can be found in and invoked via an interface or a service level agreement.

 

Addition: Information System/Application Service

A discrete behavior requestable from an application (e.g. log in, book train seat, transfer money).

It supports and enables business roles and processes by capturing or providing data or automating a process.

It can be coarse-grained or fine-grained (cf. a use case or user story).

It can be found in and invoked via an interface.

 

Edited: 55 Platform/technology service

A discrete behavior requestable from a platform technology (e.g. start transaction, send email).

It supports and enables business applications.

It can be coarse-grained or fine-grained.

It can be found in and invoked via an interface.

 

Flows, Data and Information

 

Addition: Flow: a flow of goods, materials or data between source and destination building blocks.

It may be defined as an input or output flow in a service contract.

A data flow is a message or file that contains a data structure.

 

Addition: Data structure

A form in which facts, opinions or directions are encoded.

The format can be textual, numerical, narrative, graphical, cartographical or audio-visual.

 

Edited: 40 Information

(1) A synonym for data

(2) A meaning found in a data structure by a human or computer actor.

 

Edited: 44 Metadata

Data that describes the qualities of data structures and elements in them.

E.g. data types, confidentiality, integrity and availability characteristics.

 

Please now complete these two short push-button surveys on change requests:

·         SERVICES and DATA https://www.surveymonkey.co.uk/r/RSX6HC5

·         ARCHITECTURE DOMAINS https://www.surveymonkey.co.uk/r/RSMCVL8

Other Core Concepts in TOGAF

 

After reading this section please complete these short push-button surveys on change requests:

·         ARCHITECTURE and VIEWS https://www.surveymonkey.co.uk/r/RSQFQWN

·         ARCHITECTURE SCOPE and LEVELS https://www.surveymonkey.co.uk/r/RSRQWCC

·         ARCHITECTURE STATES  https://www.surveymonkey.co.uk/r/RST8CD6

·         ENTERPRISE CONTINUUM https://www.surveymonkey.co.uk/r/RSF55CL

·         FRAMEWORKS and METHODOLOGY https://www.surveymonkey.co.uk/r/RS3ZBFW

·         GOVERNANCE and PRINCIPLES https://www.surveymonkey.co.uk/r/RSBQ835        

·         MOTIVATIONS and CONSTRAINTS https://www.surveymonkey.co.uk/r/RSB3K9G

·         WORK PLANS https://www.surveymonkey.co.uk/r/RSPZXQY

·         ABSTRACTION and MODELS https://www.surveymonkey.co.uk/r/RSZ8ZKK

 

ARCHITECTURE and VIEWS

 

Edited: 8 Architecture

(1) An abstract description of the structures and behaviors of a system.

(2) A structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

.

Edited: 75 View

A part or slice of an architecture that addresses particular concerns

It can be visual, graphical or textual.

It can be an instance or example of a viewpoint, meaning it conforms to the definition of that viewpoint.

 

Edited: 76 Viewpoint

A type or template for views.

A viewpoint is defined by its name, why a view of that type is drawn (concerns addressed), who typically has those concerns (stakeholders) and how the view should be presented (a notation, template or form).

 

Edited: 72 Taxonomy of Architecture Views

A structure that classifies architecture viewpoints and/or views.

 

Edited: 15 Architecture Landscape

That part of the architecture repository that holds all levels and states of architecture definition.

 

Edited: 7 Architectural Style

A collection of principles and characteristics that steer or constrain how an architecture is formed

ARCHITECTURE DOMAINS

Architecture domains

Delegation

Business

Applications & Data

Technologies

Service provision

 

Edited: 12 Architecture Domain

An area or view of an enterprise architecture.

The primary domains (business, information systems and platform technologies) can be seen as a top-down structure in which each layer provides the services to the layer above.

The information system domain is divided into data and application domains.

 

Higher domain layers (subtypes of domain)

 

Edited: 22 Business Architecture

A description of the services that business building blocks provide to business customers and to each other - by sending and receiving materials and information.

It describes business services and processes, their assignments to logical functions/capabilities and roles, and the realization of those by organization units and actors.

It relates business elements to business goals and elements of other domains.

 

Edited: 32 Data Architecture

A description of data a business must remember to perform its processes, data structures contained in logical data components and the realization of those in physical data components (databases, document stores, etc.).

It relates data elements to elements of other domains.

 

Edited: 4 Application Architecture

A description of the services that applications provide to business roles and processes and to each other - by sending and receiving data flows.

It describes information system services, their assignment to logical application components and the realization of those by physical application components.

It relates application elements to elements of other domains.

 

Lower domain layers (subtypes of domain)

 

Edited: 6 Application Platform Interface (API)

The collection of platform services provided by technology components to all application components in the scope of the architecture.

It appears in the TRM graphic between the applications architecture domain and the technology architecture domain.

 

Edited: 73 Technology Architecture

A description of the services that technology components (hardware and software) provide to applications and to each other.

It describes platform/technology services, their assignment to logical technology components and the realization of those by physical technology components (such as database management, middleware, operating systems and networks).

It relates technology elements to elements of other domains.

 

Redundant: 5 Application Platform

The collection of technology components that make up a Technology Architecture.

 

Redundant: 54 Platform

Generally, the layer below the one of primary interest.

E.g. the major application(s) that provide the platform for some business activities.

More usually, a synonym of the Technology Architecture or Application Platform that provides the platform for business applications.

 

Edited: 41 Information Technology (IT)

(1) Technologies that process digital data (capture data, transport data, transform data, store data, secure data, present or report data).

(2) The label for a department that analyses and designs the use of IT, develops and maintains software that runs on IT, deploys and manages IT.

 

ARCHITECTURE SCOPE and LEVELS

Architecture levels

Composition

Enterprise/Strategy

Segment

Solution/Capability

Decomposition

 

Broader/higher level architecture levels

 

Edited: 34 Enterprise

The organization scope that enterprise architects are sponsored to address, covering all its missions and functions/capabilities and organization units.

It may be a whole business or a division of a business.

It may embrace partner organizations.

 

Edited: 70 Strategic Architecture

The widest, highest level of architecture description.

The baseline is a summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level view for direction setting.

The target is the longest term architecture vision.

 

Edited: 62 Segment Architecture

An architecture for one segment of an enterprise.

The segment could be a high-level business function/capability or organization unit.

A target segment architecture may relate to a substantial program or portfolio of projects.

 

Narrower/lower level architecture levels

 

Edited: 65 Solution Architecture

The architecture of a discrete solution, often related to how an application supports or enables business roles/processes.

Typically a project -level solution outline or high-level design. It shapes and steers detailed design and implementation tasks.

 

Redundant: 27 Capability Architecture

An architecture at the lowest level of detail, for one solution or solution aspect.

 

Redundant: 28 Capability Increment

An implementable portion of a capability or solution architecture that delivers some value on the path to realizing the whole capability.

ARCHITECTURE STATES – from baseline to target

 

Edited: 19 Baseline

A specification that has been formally reviewed and agreed upon.

It serves as the basis for further development or change.

It can be changed only through a formal change management process that involves change control and configuration management.

 

Edited: 74 Transition Architecture

An architecture at an intermediate state in an Architecture Roadmap.

There may be several transition states between the Baseline and Target Architecture states.

 

Edited: 17 Architecture Vision

A succinct description of a Target Architecture.

An aspirational vision that scopes, shapes and steers more detailed architecture definition.

It can describe its business value and the changes to the enterprise that will result from its successful implementation and deployment.

 

Edited: 71 Target Architecture

A description of an architecture at a future state.

An Architecture Roadmap may include several intermediate target states before the final target state.

 

Edited: 38 Gap

Generally, an element in one structure but not in another.

More particularly in TOGAF, an element that exists in one architecture state but not in another state.

Gap analysis between states reveals work package(s) to be planned.

 

ENTERPRISE CONTINUUM

TOGAF’s Enterprise Continuum is represented here as a matrix.

Generalisation

Idealisation

Foundation

(Universal)

Common Systems

(Fairly generic)

Industry

(Fairly specific)

Organisation

(Uniquely configured)

Requirements and Context

Architecture Continuum

Solution Continuum

Deployed solutions

 

Edited: 35 Enterprise Continuum

A classification scheme for architecture and related artifacts.

Bottom to top, the four levels represent abstraction by idealization from deployed solutions to requirements (and may be mapped to ADM phases).

Right to left, the four positions represent abstraction by generalization from Organization-Specific Architectures to generic Foundation Architectures.

 

Parts of the aggregate

 

Edited: 10 Architecture Continuum

The level of specification in the Enterprise Continuum that is logical or vendor-neutral.

It contains specifications of ABBs that are realised by more physical SBBs.

It classifies Architecture Repository artifacts into four classes that range from generic (foundation) to specific (organization).

The artifacts may appear also in Architecture Definition Documents.

 

Edited: 36 Foundation Architecture

A position in the Architecture Continuum that classifies the most universal or generic artifacts.

It includes descriptions of platform technology components and services.

Along with generic principles, standards and guidelines that provide a foundation for developing more specific architectures.

 

Edited: 67 Solutions Continuum

The level of specification in the Enterprise Continuum that physical or vendor-specific.

It contains specifications of SBBs that realise ABBs.

It classifies Solutions Repository artifacts into four classes ranging from generic (foundation) to specific (organization).

The artifacts may appear also Architecture Road Maps.

FRAMEWORKS and METHODOLOGY

 

Edited: 37 Framework

A structure containing processes, products/content and roles that organizes and sequences thinking, and ensures the completeness and consistency of the products.

 

13 Architecture Framework

A framework (see above) for developing, planning, implementing and sustaining an architecture.

 

Framework – work process view

 

Redundant: 47 Methodology

A collection of methods (processes and products) designed to address large and multi-faceted problems.

 

Edited: 46 Method

A repeatable process for solving a problem or creating a product.

 

Edited: 11 Architecture Development Method (ADM)

The core of TOGAF: a multi-phase but also iterative approach to develop and use an architecture definition to shape and govern implementation projects.

The ADM may be applied at different levels of abstraction, from enterprise/strategic architecture down to capability or solution architecture.

 

Framework – work products view

 

Edited: 58 Enterprise Repository

A system that stores the work products of enterprise and solution architecture.

In TOGAF, it is divided into Requirements, Architecture and Solution repositories.

 

Edited: 33 Deliverable

A work product that is contractually specified, then formally reviewed, agreed, and signed off by stakeholders.

Deliverables (usually documents) are the outputs of projects.

Deliverables may be archived at completion of a project.

Some architecture deliverables are instead retained in the Architecture Repository as a reference model, standard, or snapshot of an architecture at a point in time.

 

Edited: 18 Artifact

A work product that describes a view or aspect of an architecture.

It is usually a catalog of building blocks or services, or a matrix or diagram that relates them..
 

GOVERNANCE and PRINCIPLES

Architecture Governance

Architecture Practice

Principles

<publish>                        <used by>

Architecture board  <monitor and guide> Architects

Architectures

<create and use>        <realised by>

Architects  <observe and envisage>  Systems

 

Edited: 30 Governance

The practice of monitoring and directing (rather than managing) an organization and its work. The goal is to deliver desired outcomes and adhere to relevant principles, standards and regulations.

 

Edited: 24 Business Governance

The practice of monitoring and directing business activities. The goal is to deliver desired outcomes and adhere to relevant principles and regulations.

 

Edited: 14 Architecture Governance

The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards and road maps. There is governance of architecture development, architecture implementation (alongside system implementation) and architecture change (alongside operational change management).

 

Redundant: 52 Performance Management

The practice of monitoring and directing the enterprise architecture practice. The goal is to ensure effective performance and continuous improvement.

 Super and subtype concepts

 

Edited: 56 Principle

A qualitative statement of intent or best practice used to govern how things should be done and help in choosing between options.

Typically documented in terms of name, description, rationale and implications, including a measure of importance.

 

Edited: 16 Architecture Principle

A principle used to govern how architectures should be developed, and help in choosing between options.

 

Edited: 20 Boundaryless Information Flow

The guiding principle of The Open Group to provide "access to integrated information to support business process improvements".

In TOGAF, it implies designing the target architecture with attention to consolidation of data sources and/or integration of applications, and to data qualities including standard data types, confidentiality, integrity and  availability.
 

MOTIVATIONS & CONSTRAINTS

 

Aims

 

Edited: 50 Objective

A simple, measurable, actionable, realistic and timebound (SMART) target for an organization that will lead it towards a higher level goal, target or vision.

E.g. ‘‘Increase Capacity Utilization by 30% by the end of 2009 to enable the goal to increase market share’’.

 

Edited: 59 Requirement

A quantifiable or testable statement of need to be met by the system(s) that implement a defined architecture.

 

Stakeholders, concerns and constraints

 

Edited: 68 Stakeholder

An individual, team, organization or class thereof with interests in, or concerns relative to, the outcome of architecture definition.

Stakeholders may have different concerns and/or share concerns.

 

Edited: 29 Communications and Stakeholder Management

The practice of identifying and managing the concerns of stakeholders in architectural endeavours through communications with them.

 

Edited: 30 Concern

An interest that is important to one or more stakeholders in one or more systems, and determines the acceptability of those systems.

Concerns may pertain to any aspect of a system’s architecture, implementation or operation.

Concerns may include qualities like speed, throughput, reliability, security, distribution, and evolvability.

General concerns may be instantiated in measurable requirements for a particular system.

 

Edited: 42 Interoperability

A concern about how well systems and/or building blocks can work together by providing and consuming services or otherwise exchanging materials and/or information.

Super and subtype concepts

 

Edited: 31 Constraint

A category of concerns that limit the scope or nature of what can be designed, planned or delivered.

General constraints include time, budget, resources, regulations and standards.

Particular constraints might include, for example: data disintegrity constrains an organization’s ability to offer effective customer service.

 

Edited: 69 Standard

A specification of general attribute types and/or values to be applied in defining the elements of a specific architecture.

A Standards Information Base (SIB) is database of such standards, be they universal or organization-specific.

WORK PLANS

 

Edited: 77 Work Package

A set of actions designed to produce deliverables that meet business objectives (or are a necessary stepping stone to meeting those objectives).

A work package can be a program, a project or a part of a project.

 

Edited: 60 Roadmap

An abstract plan for change, often spanning several years.

(1) the road map for one building block shows how a particular business or technology portfolio item will change or be replaced over time.

(2) an Architecture Road Map collates all business and technology changes to be made in a program or project.

 

ABSTRACTION and MODELS

 

Abstraction (fundamental to architecture definition in TOGAF)

 

Addition: Abstract

The quality of a description or model that means it is less detailed and/or less specific and/or less physical/concrete than the thing described.

For example: ABBs are more abstract than SBBs, which are more abstract than Deployed Solutions.

Four abstraction varieties used in TOGAF (with ArchiMate symbols)

 

Edited: 1 Abstraction

The process of abstracting a model or description from a complex structure or behavior.

Abstraction (or reverse engineering) is a bottom up approach to describing a complex system.

By contrast, elaboration (or forward engineering) is a top-down approach to designing a complex system.

Successive abstraction creates descriptions at several levels of abstraction.

Each description should be consistent in its level of detail, and facilitate decision making and communication with stakeholders.

Abstraction by idealisation

 

Edited: 43 Logical

Denotes a description that is abstract by idealization, by suppression of physical details.

For example a logical data model, a use case description, an interface specification.

A vendor-neutral specification of a system or ABB.

 

Edited: 53 Physical

Denotes a description of a real-world entity, an individual entity or vendor-specific component type.

In an enterprise architecture, physical elements may still be abstracted from Solution Architecture, design, or implementation views.

 

Models

 

Edited: 48 Model

An abstract description of a reality that facilitates understanding of and reasoning about that reality.

In enterprise architecture, the reality being modelled is an enterprise’s business systems and their enabling information systems.

A model may be represented in views that each address particular concerns held by stakeholders.

 

Edited: 49 Modeling

The process of building models.

 

Edited: 45 Metamodel

(1) A model that describes the qualities of a model:

(2) The schema of an architecture repository that supports several discrete models or views.

 

Edited: 51 Patterns

A general model, a re-usable solution to a problem.

It may relate building blocks in a generalised structure.

Its definition includes when and why to use it, and what trade-offs to make in doing so.

 

Edited: 57 Reference Model (RM)

A general structure (like the TRM) or a design pattern (like the III-RM) that serves as a skeleton or template for a particular architecture or design.

References to supporting research and core meta models

Click here for introduction to General System Theory

Click here for discussion of TOGAF Building BlocksThanx.. helps my understanding of Building Blocks and the Content Meta model.”

Click here for revised TOGAF Business Architecture approach Inc. graphic showing how TOGAF 9.1 Business Architecture description artifacts relate meta model entities.

Click here for TOGAF Entities and Attributes
Click here for TOGAF to ArchiMate mapping table - and slide show