Overview#
This content relates to the TOGAF Standard. The following represent a set of notes I created while originally studying the TOGAF Standard. They are not intended to be an exhaustive summary, but an overview of some of the main points.
The Open Group Architecture Framework (TOGAF) is a framework for the development and management of enterprise architectures. (See Purpose for some rationale as to why this is important)
It is a best practice framework that provides a structured approach for Enterprise Architecture:
- It provides an Enterprise Architecture Framework to develop any kind of architecture in any context
- The framework has been developed a collaborative effort through a community.
- It describes a standard cycle of change used to plan, develop, implement, govern and change an architecture. This is described further in adm.
- Describes the building blocks within an enterprise that can be used to fulfil business capabilities and deliver services.
Consider the definition of Enterprise Architecture, It is made up of 2 separate words to distinguish the different roles of the architect.
Definition of Enterprise#
An Enterprise is any collection of organisations that have a common goal.
- This could be a whole Enterprise or one or more specific areas or business units.
- The Architecture could span multiple Enterprises
- It is considered to be a System
- The Enterprise scope may include suppliers, partners and customers
- An Enterprise may develop and maintain serveral different and independent Enterprise Architectures (see also Partitioning)
Definition of Architecture#
The TOGAF Standard enhances the ISO/IEC/IEEE 42010:2011 terminology
- The fundamental concepts or properties of a
system in its environment embodied in its elements,
relationships and in the principles of its design &
evolution.
(Source: ISO/IEC/IEEE 42010: 2011)
- The structure of components, their
interrelationships & the principles and guidelines
governing their design & evolution over time.
(Source: The Open Group TOGAF® Standard —
Introduction and Core Concepts)
Architecture Domains#
The TOGAF standard divides an Enterprise Architecture into 4 Different domains:
- Business Architecture - Defines the key business strategy, governance, organisation and key business processes
- Data Architecture - Describes the structure of an organisation’s conceptual, logical & physical data assets, data management resources
- Application Architecture - Provides a blueprint for the individual applications to be deployed, their interactions and their relationships to the core business processes of the organisation.
- Technology Architecture - Describes the digital architecture and logical software and hardware components and capabilities and standards that are required to support the deployment of business, data and application services.
Tailoring#
The generic TOGAF framework can be tailored and integrated with other frameworks.
I find the documentation and approach to this to be not well defined and the approach to tailoring is left to the practitioner. This leads to different view and can be seen as a way of covering up the prescriptive nature of TOGAF and trying to avoid the fact that it can be onerous to adopt.
The different levels of an architecture within the TOGAF standard
The states of an architecture
Overview This page describes the TOGAF content framework and its key components.
Key Components This is the key categorisation for the Architecture Content that is produced.
It structures the artifacts and work products to be developed and described in an Architecture.
There is a relationship between the content framework and the ADM phases.
There are multiple different frameworks for describing architecture content - TOGAF, Zachman, DoDAF and NAF, to name a few.
...
Overview The meta model defines the entities within an organisation and the relationships between them.
TOGAF provides templates for documents but does not constrain the notation used for the models and artifacts. This could be defined as part of the preliminary phase of the architecture
Examles are ArchiMate, Business Process Model and Notation (BPMN), and Unified Modeling Language (UML).
Enterprise Continuum Provides structure and categorisation of assets held within the Enterprise Repositories.
Sets a broader context to the re-use of the artifacts Explains how generic solutions can be leveraged and specialised so that they can be re-used to support the architecture requirements of an individual organisation Comprises of 2 distinct continuums - Architecture and Solution Provides a view or perspective of the models, patterns, viewpoints, building blocks and other artifacts stored in the repository This includes Internal architecture and solution artifacts that have been delivered from previous work and are available for re-use. It may also extend to include external architecture and solution artifacts taken from industry reference models or patterns (e.g. AWS Reference Architecture and Well-Architected framework)
Architecture Scope Dimensions 4 dimensions define the limit and the scope of an architecture:
Enterprise Detail Domain Period Breadth Depth BDAT Planning Horizon - What is the full extent of the enterprise? - What level of detail will the architecture cover? - What domains will the architecture cover? - What time period for the architecture vision? - How much will the architecture cover? - How much architecture is enough? - Business - Can we cover the period to a required level of detail? - Organisations - What is the boundary between solution and delivery? - Data - Do we have enough information? - Business Units - Application - Do we have enough resources to complete the architecture? - Departments - Technology - Processes
TOGAF provides a framework for continuous change that links strategic direction and business value.
Manages complexity, risks and supports change. Optimises processes into an integrated environment that is responsive to change and is supportive of the delivery of the business strategy and mission. Provides enterprises a strategic context for the evolution and reach of digital capability in response to the changing needs of the business environment. Achieves a balance between business transformation and operational efficiency. Enables business units to innovate for business goals and competitive advantage. Enables an integrated strategy with synergies across the enterprise and beyond Governs, directs and controls, the change activity to realise the expected value. Describes the current and future state of an enterprise as well as the gaps Documents processes around data that can be easily understood and managed Provides an approach to reach the target state that performs trade-offs and value realisation for decisions.
The TOGAF Standard - Structure and Documents
Overview The Architecture Repository is a central repository for all architecture artifacts and work products. It stores different classes of architectural output at different levels.
Part of the Enterprise Repository of artifacts.
This is often implement by modelling software (e.g. BizzDesign), analytic tools, file repositories or document/content management systems.
Architecture Landscape The architectural representation of assets deployed within the enterprise at a particular point in time - This will reflect the baseline, transition(s) and target states often at multiple levels of detail.
...
Building Blocks Overview These are potentially re-usable components that can be used to deliver an Architecture. TOGAF will group these into the abstract Logical - Application Building Blocks and the Physical Building Blocks - Solution Building Blocks (SBB). Without being too prescriptive, a building block should meet the following criteria:
Is a package of functionality defined to meet a business need or capability. It should be recognisable as a discrete thing. Should normally correspond to one of the types defined in the Enterprise Metamodel - Actor, Business Service, Application or Data Entity. Can be defined at various levels of detail depending on the objective of the Architecture and also the Phase. There is a general benefit of composing functionality through building blocks in that it should improve integration and interoperability through defined interfaces and contracts. It may also improve reusability and flexibility through the creation of new re-usable applictions or components. ...