What is TOGAF?
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.
What is Architecture in the Context of TOGAF?
"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:
- Architecture Development Method
- ADM Guidelines and Techniques
- Architecture Content Framework
- Enterprise Continuum & Tools
- TOGAF® Reference Models
- Architecture Capability Framework
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:
- 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
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
In the architecture phase B, C and D of TOGAF, the same steps (step 1-8) have to be conducted
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
- 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
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
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
- Building Blocks
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
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.
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.
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.