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

Graham Berrisford. Last updated 22/07/2017 19:02

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 14^th of June 2017).

Specific rationales for particular change requests are explained in the slide show and on-line questionnaires – not in this paper.

Contents

Problems and proposals. 1

System theory concepts and principles that underpin TOG standards in general and TOGAF in particular. 2

Core concepts: BUILDING BLOCKS. 5

Core concepts: SERVICES and DATA.. 7

Other Core Concepts in TOGAF. 8

References to supporting research and core meta models. 16

Problems and proposals

Enterprise and solution architects work in a vocabulary hell

In UML, Service and Interface are synonyms; and 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.

Proposals

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 proposals below are intended to:

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

· Add some missing entries; remove some redundant entries.

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

· Define entries so as disambiguate them.

· Define entries wrt TOGAF meta model entities and examples.

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

· Align a few entries more closely with ArchiMate.

Before proposing new definitions for TOGAF’s core concepts, the next section outlines some general principles.

System theory concepts and principles that underpin TOG standards in general and TOGAF in particular

The term “system” appears 1,357 times in TOGAF 9.1, including:

· “EA structures the business planning into an integrated framework that 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”

This table compares core concepts in TOGAF with core concepts in General System Theory.

Concepts in General System Theory	Core concepts in TOGAF’s meta model
A bounded structure of	A bounded organisation of
actors/organs that interact by playing	building blocks that interact by playing
roles in	roles in
behaviors to meet	processes to meet
goals, by maintaining the system’s	goals/objectives by maintaining the system’s
state and exchanging	data entities (information state) and providing
inputs/outputs with each other and with	input/output services to each other and to
entities outside the boundary, using	entities playing roles, using
system resources.	platform technology components.

Holistic view: a description of how parts relate, interact or cooperate in a whole.

TOGAF takes a holistic view; it looks to integrate business systems to the benefit of the wider enterprise.

TOGAF version 8 (the "Enterprise Edition") borrowed a great deal from the US government’s Federal EA Framework (1999)

FEAF declared its aims as: “common data and business processes”, “information sharing” and “new and improved processes”.

TOGAF also promotes the “business operating model” principle (from “EA as Strategy”, 2006) of standardising and integrating processes across the enterprise.

“Operating model” for core business processes
High integration	Coordinated	Unified
Low integration	Diversified	Replicated
	Low standardisation	High standardisation

Organicism: the idea that systems are describable at multiple hierarchical levels.

EA frameworks like TOGAF define an enterprise as a recursively decomposed structure of business functions/capabilities.

They use this logical structure as their touchstone, rather than the organisation’s management structure, which is relatively volatile.

They also treat the architecture domains (business, applications, platform technologies) as a client-server system hierarchy.

System interface: a description of inputs and output that cross the system boundary.

The Open Group’s mission is: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

To this end, The Open Group promotes service-oriented specification – defining standards and systems as service portfolios.

TOGAF 8 extended the service-oriented specification approach already used in TOGAF 1 to 7.

"TOGAF Version 8… uses the same underlying method for developing IT architectures that was evolved [in] TOGAF up to and including Version 7.

That method was to define a system or component, an architecture domain or layer, logically, by the services it provides.

Version 8 applies that… method to the other domains of an overall Enterprise Architecture - the Business Architecture, Data Architecture, and Application Architecture, as well” http://www.opengroup.org/architecture/togaf7/index7.htm

TOGAF 9 introduced a content framework and meta model based on this service-oriented approach.

The table below shows the terms TOGAF uses when abstracting Services from Building Blocks.

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

Information: a meaning created or found by an actor in any physical form that acts as a signal.

TOGAF focuses primarily on business operations that create or use information.

"EA as Strategy” (by Ross, Weill and Robertson) says the “foundation for execution” includes well-managed information systems.

Why? Because you can't integrate business processes without passing business data between roles and activities.

And you can't standardise business processes unless the actors in those processes are monitored and/or directed by information systems.

Information flow (aka message): physically, a signal passed from sender to receiver, logically, a communication.

Information state (aka memory): the values of descriptive variables held in a memory or database of some kind.

Information quality: an attribute of information flow or state, such as speed, throughput, availability, security, monetary value.

For decades, authors have put the quality and use of business information at the heart of EA.

· "Today’s CEOs know that the effective management and exploitation of information… is a key factor to business success.” (TOGAF 9.1, 2009 reference)

The higher purpose has always been to optimise and improve business processes.

· “An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference)

· "Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).

Information feedback loop: the circular fashion in which input flows influence future output flows and vice-versa.

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

Their mission is: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”

Clearly, TOGAF is concerned that business information feedback loops are efficient and effective.

Event: a discrete input that triggers a process that changes a system’s state, depending on the current state.

Process: one or more state changes over time, or the logic that determines which state changes lead to which other state changes.

TOGAF presumes processes can be “digitized” and described in flow charts.

TOGAF applies “the primacy of behaviour” principle, first to human activity systems, then to applications, then to platform technologies.

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

· (It also defines flows of materials and information between business units in a “node connectivity diagram”).

· Phase C starts by defining information system/application services that business processes require from business application components.

· (It also defines data created and used by business processes, using applications.)

· Phase D starts by defining platform/technology services that business applications require from technology components.

TOGAF employs modelling techniques that exemplify GST concepts.

· Structured analysis is used to model structural and behavioral views of a business.

· An elementary business function/process is an action – the atomic unit of behaviour.

· A functional decomposition hierarchy is structural view of those actions (more stable than the organisation’s management structure).

· A business process model is behavioural (sequential) view of the same actions.

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	Enterprise repository
Required behaviors	Services	Business Services	IS/Application Services	Platform/Technology Services	Requirements repository
Logical structures	Logical Building Blocks	Function & Roles	Logical Application Components	Logical Technology Components	Architecture repository
Physical structures	Physical Building Blocks	Organisation Units & Actors	Physical Application Components	Physical Technology Components	Solutions repository

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.

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 the section below 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.

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

Architecture board <monitor and guide> Architects

Architectures

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 Blocks “Thanx.. 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