TOGAF®, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency. It is an enterprise architecture standard, ensuring consistent standards, methods, and communication among enterprise architecture professionals, so that we can conduct our enterprise architecture work in a better way, including:
• An iterative process model supported by best practices
• A re-usable set of existing architecture assets
• Methods and tools for the planning, development, implementation, and maintenance of an enterprise architecture
TOGAF Development Overview
First published in 1995, TOGAF was based on the US Department of Defense Technical Architecture Framework for Information Management (TAFIM). From this foundation, The Open Group Architecture Forum has developed successive versions of TOGAF at regular intervals.
*from ArchiTACTS http://architacts.com/WP/?page_id=11753
What is Architecture in the Context of TOGAF?
ISO/IEC 42010:20071 defines “architecture” as:
“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
TOGAF embraces and extends this definition. In TOGAF, “architecture” has two meanings depending upon the context:
- A formal description of a system, or a detailed plan of the system at a component level to guide its implementation
- The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
What is Enterprise Architecture?
Enterprise architecture (EA) is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business process, Data & information, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes, which include the effort to understand the strategic intent of a business and then have everything from business processes, to supporting technology, to partner relationships, to infrastructure of all sorts, to hiring and training, and anything else important work in alignment to achieve better business performance.
Structure of the TOGAF
The TOGAF content is divided into 7 parts:
- Introduction
- Architecture Development Method
- ADM Guidelines and Techniques
- Architecture Content Framework
- Enterprise Continuum & Tools
- TOGAF Reference Models
- Architecture Capability Framework
The brief description for each of the seven parts are listed as following:
Part I – Introduction
As show in the table, this part provides a high-level introduction to the key concepts of enterprise architecture and, in particular, to the TOGAF approach. Now let’s explore the core concepts for each of these parts:
Core Concepts
Types of Architecture
- Business Architecture – The business strategy, governance, organization, and key business processes.
- Data Architecture – The structure of an organization’s logical and physical data assets and data management resources.
- Application Architecture – A blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
- Architecture Technology Architecture – The logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
Note That: Information Systems Architecture = Data Architecture + Application
- Part II – the Architecture Development Method (ADM) is Central Part of TOGAF
- Part VII – The Architecture Capability operates the ADM.
- Part III – The ADM is supported by a number of Guidelines and Techniques
- Part IV – Contents such as: Deliverables, artifacts and building blocks are produced and stored in the Architecture Repository
- Part V – they are classified according to the Enterprise Continuum
- Part VI – The repository is initially populated with the TOGAF Reference Models
Part II: Architecture Development Method
This is the famous circle called the Architecture Development Methods (ADM). Each phase contain set of steps one has to undertake. It provides a tested and repeatable process for developing architectures.
- Preliminary Phase
- Phase A: Architecture Vision
- Phase B: Business Architecture
- Phase C: Information Systems Architectures Phase D: Technology Architecture
- Phase E: Opportunities & Solutions
- Phase F: Migration Planning
- Phase G: Implementation Governance
- Phase H: Architecture Change Management
- Requirements Management
Note That:
In the architecture phase B, C and D of TOGAF, the same steps (step 1-8) have to be conducted
ADM Narratives
Each of the development phases in TOGAF, comes with four major sections to guide as described of phase A in the Figure below:
Part III: ADM Guidelines & Techniques
A set of guidelines and techniques to support the application of the ADM. The guidelines help to adapt the ADM to deal with different scenarios, including different process styles (e.g. the use of iteration) and also specific requirements (e.g. security). The techniques support specific tasks within the ADM (e.g. defining principles, business scenarios, gap analysis, migration planning, risk management, etc). These are the topics covered in ADM Guidelines & Techniques:
- Iteration in ADM
- Architecture Landscape
- Security Architecture
- SOA
- Architecture Principles
- Stakeholder Management
- Architecture Patterns
- Business Scenarios and Business Goals
- Gap Analysis
- Migration Planning Techniques
- Interoperability Requirements
- Business Transformation Readiness Assessment
- Risk Management
- Capability-based Planning
Part IV: Architecture Content Framework
This part describes the TOGAF Content Framework (New for TOGAF 9). It describes:
- A significant addition to TOGAF
- It provides a detailed model of architectural work products
- It drives for greater consistency in the outputs of TOGAF
Content Metamodel
The content framework provides a structured model of building block types, relationships and attributes which can be used informally, or as the basis for configuration of an Enterprise Architecture modelling tool. Through, building blocks continue to be the basic elements of the architecture within TOGAF, the content framework features a core and extension concept, with optional building block types, in order to support lightweight and detailed architectures. It has the following benefits added to TOGAF:
- It provides a comprehensive checklist of architecture outputs.
- It promotes better integration of work products if adopted across an enterprise
- It provides a detailed open standard for how architectures should be described
Deliverables, Artifacts and Building Blocks
Deliverables is used for work products that are required to be produced and will be formally reviewed, agreed and signed off by the stakeholders. The output of the projects are usually under the deliverables category and are in documentation form which will be archived at the completion of the project or moved to Architecture Repository as a reference model, standard or snapshot of the architecture Landscape.
Architecture Content Framework uses three different categories to categorize the type of output developed during ADM process. The three different TOGAF Architecture Content Framework categories are
- Deliverables
- Artifacts
- Building Blocks
Artifacts
Artifacts are used for work a product that describes an aspect of the architecture. Artifacts are classified as below:
- Catalog – Used to show a list of things
- Matrices – Used to show relationships between things
- Diagrams – Pictures of things
Building Blocks
A building block is package of functionality defined to meet the business needs across an organization. Building blocks are often used in different levels. We can use it to represent conceptual business capabilities such as, customer relation management (CRM) in early analysis. We can also refine the conceptual capability into functionalities such as, customer master data and then further detailing it into: manager appointment, manage customer contacts etc.
Part V: Enterprise Continuum & Tools
A Model for Structuring a Virtual Repository and Methods for Classifying Architecture and Solution Artifacts. It has the following changes in TOGAF 9:
- Substantially revised
- The reference models are moved to Part VI
- New content added on Architecture Partitioning and the Architecture Repository
- The Standard Information Base (SIB) is removed
Enterprise Continuum vs Solution Continuum
In the upper part of Figure, it describe the logical picture of the architecture (Architecture Continuum) and in the lower port, it mentions the physical realization of the architecture (Solutions Continuum)
Generic vs Specific Architecture
Also the Diagram is structured from the left “more generic” architecture, to the right “more specific” architecture, that allows us refine our architecture from “logical” to “physical”, and from more generic to more specific as we progress from the problem initially, and to the solution eventually.
Partitioning
Architecture Partitioning allows for management of costs and complexity by dividing up the Enterprise and assigning appropriate roles and responsibilities to each partition. This Figure demonstrates the need of a meta-architecture in federated organizations that provides an integration framework for the individual architects of the different business units.
Architecture Repository
Architecture Repository is a logical place to organize reference material and results of architecture work. Some or all of it may be archived in physical repository tool such as VP’s documentation cabinet. It is also a conceptual model which defines what kind of things are stored. The major components within an Architecture Repository are as follows:
- The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
- The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
- The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives.
- The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
- The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
- The Governance Log provides a record of governance activity across the enterprise.
Part VI: Reference Models
The definition of the Reference Models are substantially revised in TOGAF 9. There are two reference models are provides:
- Technical Reference Model (TRM) – A Foundation Architecture which serves as a model and a taxonomy of generic platform services.
- Integrated Information Infrastructure Model (III-RM) – A model for business application and infrastructure application
Relating Reference Models to Architecture Continuum
Architecture Continuum is composed of four states. The underlying process is to discover architectural requirements, analyze and understand architectures that are already in place in the organization, from foundation architectures (i.e. TRM), through common systems architectures III-RM), industry standard architectures, (i.e. SOA), and to an organization’s own architecture. The Figure below is an illustration of an architectural process based on four states:
- Foundation architectures (TRM)
- Common system architectures (III-RM)
- Industry architectures
- Organization architectures
Architectural changes made to states at the left will migrate to states at the right. The left-to-right direction implies a logical progression in organizing an enterprise architecture implementation.
Part VII: Architecture Capability Framework
This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise. It is a new part in TOGAF 9 and derived based on the 8.1.1 Resource Base
Structure of Architecture Capability
An enterprise architecture development involve the generation of business capability, planning and managing architecture in the organization on all levels through different development phases. The enterprise needs to identify of the governance bodies which is responsible to make architecture decisions as shown on the top of the Figure below.
In the middle of the right-hand side, TOGAF specifies the architecture pool of skills which records the definition of the maturity of the organization and its improvement. Therefore, it contains the architecture professionals’ skills, knowledge and professional development strategies. These knowledge enables the definition of the roles and responsibilities for the architecture work, in other words, who is responsible for what?
On the right of the skilled pool, the Project/Portfolio Governance send contracts of architecture work to the Project/Portfolio, which should in sync with priority and focus of the business operations.
Deliverables, Artifacts, logs or policy papers can be drawn from the enterprise continuum and architecture repository
The general idea is to evolve the capability of the organization to develop architecture which will result of increasing business capability.
Architecture Board – The Board oversees implementation of the governance strategy, which comprises of representative stakeholders responsible for review and maintenance of architecture
Architecture Compliant – A key relationship between the architecture and the implementation lies in the definitions of the terms compliant for ensuring the compliance of individual projects with the enterprise architecture.
Architecture Contracts – Joint agreements between development partners and sponsors on the deliverables, qualify and fitness-for-purpose of an architecture
Architecture Maturity models – they are employed as a means for businesses to evaluate their current position, and therefore, better understand when it’s the right time to move forward and how to do so
Architecture Skills frameworks – provide a view of the competency levels required for specific roles.
References:
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish