What TOGAF says about architecture as description

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 them helpful, please spread the word and link to the site in whichever social media you use.

 

This is one of a pair of papers:

·         How TOGAF define Enterprise Architecture

·         What TOGAF says about architecture as description

 

Abstract: In TOGAF, architecture is defined as description; note especially the definitions edited from chapter 3 below.

Chapter 1 says

TOGAF is a framework — a detailed method and a set of supporting tools — for developing an EA.

It may be used freely by any organization wishing to develop an EA for use within that organization.

The TOGAF Architecture Development Method (ADM)… a step-by-step approach to developing an EA.

 

The enterprise already exists, it operates as a system of systems.

So to develop an EA it is to develop descriptions of those systems and coordinate them.

 

An EA… providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

 

The EA is the description that enables strategists and planners to understand the operational systems and helps them to plan changes.

 

What specifically would prompt me to develop an EA?

… preparation for business transformation needs or for radical infrastructure changes…

The role of the architect is to address their concerns by:

·         Identifying and refining the requirements that the stakeholders have.

·         Developing views of the architecture that show how the concerns and requirements are going to be addressed.

·         Showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders.

 

Organizations that design and implement EAs using TOGAF are assured of a design and a procurement specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with reduced risk.

 

The EA is equated here with a design and procurement specification.

Chapter 2 says

TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an EA.

 

Note that to “maintenance of the EA” means “maintenance of architecture descriptions in step with operational systems”.

 

The Business Architecture defines the business strategy, governance, organization, and key business processes.

The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.

The Application Architecture provides a blueprint

The Technology Architecture describes the logical software and hardware capabilities.

 

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures.

Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.

 

Note that to “managing change to the architecture” is about managing changes to architecture descriptions in step with operational systems.

 

A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

Building blocks can relate to ‘‘architectures’’ or ‘‘solutions’’.

 

Note that architecture building blocks are not solution building blocks, and architectures are not solutions

 

The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

Two of the key elements of any EA framework are:

·         A definition of the deliverables that the architecting activity should produce

·         A description of the method by which this should be done.

With some exceptions, the majority of EA frameworks focus on the first of these — the specific set of deliverables —

and are relatively silent about the methods to be used to generate them (intentionally so, in some cases).

Chapter 3 says

Note that many of the core concepts defined in chapter three equate architecture with description.

 

·         Architecture: 1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation...

·         Architecture Landscape: The architectural representation of assets in use, or planned, by the enterprise at particular points in time.

·         Architecture Framework: A conceptual structure used to develop, implement, and sustain an architecture [that is, an architecture description].

 

·         Enterprise: The highest level (typically) of description of an organization and typically covers all missions and functions.

·         Strategic Architecture: A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and … long-term view for direction setting.

·         Segment Architecture: A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.

·         Solution Architecture: A description of a discrete and focused business operation or activity and how IS/IT supports that operation, typically applies to a single project or project release...

 

·         Application Architecture: A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.

·         Architecture Vision: A succinct description of the Target Architecture..

·         Capability Architecture: A highly detailed description of the architectural approach to realize a particular solution or solution aspect...

·         Target Architecture: The description of a future state of the architecture being developed for an organization.

Chapter 4 says

Within larger organizations, the practice of EA requires a number of individuals and teams that work together on many architectures.

Although each architecture will address a specific problem, in an ideal situation architectures can be considered as a group in order to develop an overall integrated view of how the enterprise is changing.

 

TOGAF features an extended set of concepts and guidelines to support the establishment of an integrated hierarchy of architectures being developed by teams that operate within an overarching architectural governance model.

In particular, the following concepts are introduced:

 

Partitioning: In order to develop architectures that have manageable levels of cost and complexity, it is necessary to partition the enterprise into specific architectures.

TOGAF discusses the concept of partitioning and provides a variety of techniques and considerations on how to partition the various architectures within an enterprise.

 

TOGAF provides a logical information model for an Architecture Repository, which can be used as an integrated store for all outputs created by executing the ADM.

Previous versions of TOGAF focused on providing a consistent process for developing architectures.

TOGAF 9 includes a greatly enhanced consideration of architectural work products to ensure that a consistent process is used to produce consistent outputs.

 

The Architecture Content Framework provides a detailed model of the outputs to be created by the ADM.

Additionally, the Enterprise Continuum, Architecture Partitioning, and Architecture Repository sections provide detailed guidance on how architectural deliverables can be scoped, governed, and integrated.

 

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0              29/01/2015 20:57

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” 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