TOGAF 10 Associate Masterclass #01 — Introduction to EA & TOGAF
Summary
This video introduces enterprise architecture (EA) and the TOGAF framework. EA is defined as aligning business strategy with technology across an organization, spanning business, data, application, and technology domains. It emphasizes that EA is broader than IT architecture. The video explains TOGAF's definition of 'enterprise' as any organization with common goals, including external partners. It details the benefits of EA, common drivers for adoption, and introduces TOGAF's core components: the Architecture Development Method (ADM), content framework, enterprise continuum, and governance. Key concepts like the four architecture domains (BDAT), abstraction levels, principles, building blocks, artifacts, and the importance of tailoring TOGAF are covered.
Key Insights
Enterprise architecture aligns business strategy and technology across an entire organization's structure.
Enterprise architecture is the practice of analyzing, designing, planning, and governing an enterprise's structure, so that its business strategy and its technology stay aligned even as everything changes around it. The TOGAF standard frames its purpose as optimizing fragmented legacy processes into an integrated environment responsive to change and supportive of business strategy.
EA is much broader than IT architecture, encompassing business, data, application, and technology.
Enterprise architecture is not just another name for IT architecture. It spans business, data, applications, and technology together. The statement 'EA is just IT architecture' is flatly false; EA is much broader.
An 'enterprise' in TOGAF is any organization with common goals, not just a single company.
TOGAF defines an enterprise as any collection of organizations that share a common set of goals. This can be a whole corporation, a division, a government agency, a department, or a chain of organizations linked by common ownership, partnership, alliance, consortium, or supply chain. Critically, it can include partners, suppliers, and customers, not just internal business units. The defining feature is common goals, not single company ownership.
Data and Application architecture domains together form the Information Systems Architecture, developed in Phase C.
Data architecture and Application architecture together form the Information Systems Architecture. Both are developed in Phase C of the ADM. Business architecture is developed in Phase B, and Technology architecture in Phase D.
The ADM is TOGAF's iterative process for developing architectures, not a rigid waterfall.
The Architecture Development Method (ADM) is TOGAF's process for developing architectures. It's an iterative cycle that establishes a framework, develops content, transitions to it, and governs realization. The ADM does not mandate a fixed sequence or a waterfall method; it's a reference model of what must be done, best understood as iterative and adaptable.
An Architecture Building Block (ABB) defines a required capability (the 'what').
An architecture building block (ABB) describes a required capability and shapes the specification for solution building blocks. It represents 'the what'.
A Solution Building Block (SBB) is an actual implementation choice (the 'with what').
A solution building block (SBB) is an actual implementation choice that realizes a required capability. It represents 'the with what'. ABBs shape SBBs.
Tailoring TOGAF is expected and necessary, not optional; it involves adopting, customizing, excluding, or creating elements.
TOGAF is a foundational framework that organizations are expected to tailor. This means deliberately adopting some elements, customizing others, excluding some entirely, and creating new ones as needed. Using it verbatim is incorrect; tailoring is encouraged.
Sections
Introduction to Enterprise Architecture (EA) and TOGAF
Enterprise architecture aligns business strategy and technology across an entire organization's structure.
Enterprise architecture is the practice of analyzing, designing, planning, and governing an enterprise's structure, so that its business strategy and its technology stay aligned even as everything changes around it. The TOGAF standard frames its purpose as optimizing fragmented legacy processes into an integrated environment responsive to change and supportive of business strategy.
EA is much broader than IT architecture, encompassing business, data, application, and technology.
Enterprise architecture is not just another name for IT architecture. It spans business, data, applications, and technology together. The statement 'EA is just IT architecture' is flatly false; EA is much broader.
An 'enterprise' in TOGAF is any organization with common goals, not just a single company.
TOGAF defines an enterprise as any collection of organizations that share a common set of goals. This can be a whole corporation, a division, a government agency, a department, or a chain of organizations linked by common ownership, partnership, alliance, consortium, or supply chain. Critically, it can include partners, suppliers, and customers, not just internal business units. The defining feature is common goals, not single company ownership.
Organizations invest in EA to manage complexity and balance transformation with operational efficiency.
Organizations need EA to manage complexity, especially when changes touch multiple interdependent systems. A good EA helps strike the right balance between transforming the business and keeping day-to-day operations efficient. It provides strategic context for digital capability evolution and aids in compliance with privacy legislation.
EA offers benefits like better strategic decisions, efficiency, and improved digital delivery.
Benefits of EA cluster into five groups: 1. Better strategic decisions, quicker response to change, agility. 2. More efficient operations, lower costs, shared capabilities. 3. Efficient digital delivery, better interoperability, improved security. 4. Better ROI, reduced complexity, flexibility. 5. Faster procurement due to coherent planning.
Common drivers for EA adoption include business initiatives, technology consolidation, M&A, and technical debt.
Common triggers for an EA effort are: business-driven initiatives (e.g., transformation, new revenue streams), technology-driven initiatives (e.g., system consolidation), mergers and acquisitions, and managing technical debt from rapid development. The underlying reason is always managing change across interdependent systems.
The TOGAF Framework
An architecture framework provides a reusable structure, method, and common language for building architectures.
A framework is a foundational structure for developing a broad range of architectures. A good one provides a method for describing baseline and target states, a set of building blocks and how they fit, and a way to plan evolution. It must be tailored to each organization, establishing common tools and vocabulary.
TOGAF's four pillars are its method (ADM), content framework, enterprise continuum, and governance guidance.
TOGAF provides four pillars: 1. A method (the Architecture Development Method or ADM), a repeatable process. 2. A content framework, a structural model for work products. 3. The enterprise continuum and repository, for classifying and reusing assets. 4. Capability and governance guidance, for establishing and managing an architecture practice.
TOGAF uses two definitions of architecture: ISO's fundamental properties and TOGAF's practical definition of components and principles.
TOGAF uses two complementary definitions of architecture: the ISO definition (fundamental concepts/properties, principles) and TOGAF's own practical definition (structure of components, interrelationships, principles). TOGAF embraces the ISO definition but uses its own more practical wording alongside it.
The four core architecture domains are Business, Data, Application, and Technology (BDAT).
The four architecture domains are: Business architecture (strategy, governance, processes), Data architecture (logical/physical data assets), Application architecture (applications and interactions), and Technology architecture (infrastructure, hardware, software).
Data and Application architecture domains together form the Information Systems Architecture, developed in Phase C.
Data architecture and Application architecture together form the Information Systems Architecture. Both are developed in Phase C of the ADM. Business architecture is developed in Phase B, and Technology architecture in Phase D.
Derived architecture domains, like security or digital, are created by combining views of the core BDAT domains.
By combining different views of the core BDAT domains, enterprises can define additional derived domains such as information architecture, risk and security architecture, and digital architecture. The four core domains are BDAT, and others are derived.
ADM, Abstraction Levels, Principles, and Building Blocks
The ADM is TOGAF's iterative process for developing architectures, not a rigid waterfall.
The Architecture Development Method (ADM) is TOGAF's process for developing architectures. It's an iterative cycle that establishes a framework, develops content, transitions to it, and governs realization. The ADM does not mandate a fixed sequence or a waterfall method; it's a reference model of what must be done, best understood as iterative and adaptable.
Architecture work occurs at four abstraction levels: contextual (why), conceptual (what), logical (how), physical (with what).
Architecture work happens at four levels of abstraction: Contextual (why - environment, scope, drivers, goals), Conceptual (what - desired needs, services, behavior), Logical (how - component types, implementation-independent), and Physical (with what - actual components chosen).
TOGAF principles are enduring rules guiding enterprise and architecture decisions.
Principles are general rules and guidelines intended to be enduring and seldom amended that guide how an organization fulfills its mission. Enterprise principles provide broad decision-making basis, while architecture principles govern the architecture work itself and must align with enterprise principles.
An architecture principle has four components: name, statement, rationale, and implications.
The four components of a TOGAF architecture principle template are: Name (memorable essence), Statement (succinct rule), Rationale (business benefits), and Implications (requirements, costs, tasks of adoption).
Good principles are understandable, robust, complete, consistent, and stable.
Five criteria distinguish a good set of principles: Understandable (easily grasped), Robust (precise for decisions), Complete (covers all situations), Consistent (no contradictions), and Stable (enduring, with an amendment process). Principles are developed by enterprise architects and approved by the architecture board.
A deliverable is a signed-off work product, an artifact is a catalog, matrix, or diagram, and a building block is a reusable component.
TOGAF's content framework classifies work products: A deliverable is a contractual, signed-off work product. An artifact describes a single aspect (catalog, matrix, or diagram). A building block is a potentially reusable component for delivering solutions.
An Architecture Building Block (ABB) defines a required capability (the 'what').
An architecture building block (ABB) describes a required capability and shapes the specification for solution building blocks. It represents 'the what'.
A Solution Building Block (SBB) is an actual implementation choice (the 'with what').
A solution building block (SBB) is an actual implementation choice that realizes a required capability. It represents 'the with what'. ABBs shape SBBs.
The enterprise continuum classifies reusable assets from generic (architecture continuum) to specific (solutions continuum).
The enterprise continuum classifies reusable assets in the repository from generic to specific. It has two parts: the architecture continuum (formal architectures, ABBs) and the solutions continuum (implementations, SBBs). Assets move from foundational to organization-specific.
The architecture repository stores and organizes ADM outputs at different abstraction levels.
The architecture repository is where ADM outputs are stored and organized, supported by the enterprise continuum. It houses components like the metamodel, landscape, standards library, and reference library.
A viewpoint defines conventions for a view, which represents architecture concerns of specific stakeholders.
A viewpoint defines conventions for creating a view. A view is a representation of the architecture from the perspective of a set of stakeholder concerns. The viewpoint is the template (definition), and the view is the result.
Interoperability (operational, information, technical) is progressively determined throughout the ADM.
Interoperability means the ability to share information and services, categorized as operational, information, and technical. It is not addressed in a single phase but is surfaced in the vision, refined through phases, and implemented later in the ADM.
Tailoring TOGAF is expected and necessary, not optional; it involves adopting, customizing, excluding, or creating elements.
TOGAF is a foundational framework that organizations are expected to tailor. This means deliberately adopting some elements, customizing others, excluding some entirely, and creating new ones as needed. Using it verbatim is incorrect; tailoring is encouraged.
The TOGAF standard is modular, divided into core documents and supported by the TOGAF Library and Series Guides.
The TOGAF standard (10th Edition) is split into six core documents (Intro/Concepts, ADM, ADM Techniques, Applying ADM, Content, Capability/Governance), supported by the TOGAF Library (reference material) and TOGAF Series Guides (how-to guidance). Its modular structure allows independent evolution of parts.
TOGAF originated from the US DoD's TAFIM, with Version 1 released in 1995 and evolving to the 10th Edition in 2022.
TOGAF was developed by The Open Group Architecture Forum. Version 1 was released in 1995, based on the US Department of Defense's Technical Architecture Framework for Information Management (TAFIM). It has since evolved through multiple versions to the 10th Edition in 2022.
Consolidated Vocabulary and Common Traps
Key TOGAF terms: enterprise, framework, ABB, SBB, deliverable, artifact, baseline, target.
Essential vocabulary to memorize: Enterprise (orgs with common goals), Architecture framework (foundational structure), ABB (required capability - what), SBB (implementation - with what), Deliverable (signed-off work product), Artifact (catalog, matrix, diagram), Baseline (as-is), Target (to-be).
Common exam traps: EA=IT architecture, enterprise=one company, ADM=waterfall, data=phase B, ABB=implementation.
Common traps to avoid: 1. EA is just IT architecture (false, it spans BDAT). 2. An enterprise is one company (false, common goals). 3. ADM must be waterfall (false, iterative). 4. Data architecture is phase B (false, Data/App are phase C). 5. ABB is the implementation (false, SBB is implemention, ABB is capability). Many traps over-narrow a broad framework.
Cheat sheet recap: BDAT domains, four abstraction levels, ABBs vs SBBs, work product types, artifact types, TOGAF docs, principle types, historical facts.
Key recall items: Architecture domains (BDAT), abstraction levels (contextual, conceptual, logical, physical), building blocks (ABB/SBB), content types (work product, deliverable, artifact, building block), artifact classifications (catalog, matrix, diagram), core TOGAF documents (6), principle domains (enterprise/architecture), historical facts (TAFIM, V1 1995).
Module Summary and Questions
EA aligns business strategy and technology across the enterprise, defined by TOGAF's meta-model.
Enterprise architecture aligns business strategy with technology across the whole enterprise and is not just IT. An enterprise is any set of organizations with common goals, and an architecture framework is a reusable, tailorable structure. TOGAF provides content, method, continuum, and governance.
TOGAF defines an enterprise by common goals, not single ownership, and BDAT are core domains, with Data/App in Phase C.
The definition of an enterprise is key. The four BDAT domains are core, with Data and Application architectures sharing Phase C. Key vocabulary includes abstraction levels, principles, and the ABB/SBB distinction. Tailoring is essential.
Question 1: TOGAF defines an enterprise as any collection of organizations that share common goals.
Correct Answer: B. An enterprise in TOGAF is defined as any collection of organizations that share a common set of goals. This definition is broad and can include partners, suppliers, and customers, not just internal business units.
Question 2: Data and Application architectures form the information systems architecture, developed in Phase C.
Correct Answer: B. Data architecture and Application architecture together constitute the information systems architecture and are both developed in Phase C of the ADM. Business architecture is Phase B, and Technology architecture is Phase D.
Question 3: ABB describes required capability ('what'), while SBB describes implementation choice ('with what').
Correct Answer: B. An ABB (Architecture Building Block) describes a required capability ('what' it needs to do), while an SBB (Solution Building Block) is an actual implementation choice that realizes that capability ('with what' it will be built).
Question 4: The four components of a TOGAF architecture principle are name, statement, rationale, and implications.
Correct Answer: A. The four components of a TOGAF architecture principle are Name, Statement, Rationale, and Implications. The other options list qualities of principles or unrelated concepts.
Question 5: Organizations are expected to customize (tailor) the TOGAF standard to their context.
Correct Answer: C. TOGAF is intended to be tailored. Organizations should adopt, customize, exclude, or create elements to fit their specific context, rather than using it strictly as written. This customization is expected.
Ask a Question
*Uses 1 Wisdom coin from your coin balance
