TOGAF®, introduced by The Open Group, 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:
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.
"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:
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.
The TOGAF content is divided into 7 parts:
The brief description for each of the seven parts are listed as following:
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:
Note That: Information Systems Architecture = Data Architecture + Application
The brief description for each of the seven parts are listed as following:
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.
In the architecture phase B, C and D of TOGAF, the same steps (step 1-8) have to be conducted
Each of the development phases in TOGAF, comes with four major sections to guide as described of phase A in the Figure below:
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:
This part describes the TOGAF Content Framework (New for TOGAF 9). It describes:
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:
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
Artifacts are used for work a product that describes an aspect of the architecture. Artifacts are classified as below:
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.
A Model for Structuring a Virtual Repository and Methods for Classifying Architecture and Solution Artifacts. It has the following changes in TOGAF 9:
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)
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.
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 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 definition of the Reference Models are substantially revised in TOGAF 9. There are two reference models are provides:
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:
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.
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
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.
