Enterprise Architecture Foundation, TOGAF 10 Standard Course Notes

I’m taking the Enterprise Architecture Foundation (10) with TOGAF course on Udemy (no referral link 🙂).

Because I study most efficiently when I take notes and actively interact with the course material, I decided to put my notes here.

These notes are an extra to go with the course. They don’t replace it, and they don’t cover everything the course mentions.

But if you’re planning to take the same exam, they might come in handy.

Good luck!

Edit: published November 5, notes until the section related to the ADM

Introduction to Enterprise Architecture

Enterprise: any collection of organisations with common goals In EA, enterprise can be applied to entire enterprise or to 1 or ore specific areas of interest within the enterprise

Enterprise can also include partners, suppliers etc. Crosses multiple systems or groups

The enterprise is whatever you need it to be, the whole org, a section, a division, etc

What is an architecture?

Architecture is the fundamental concepts or properties of a system in its environment embodied in its elements, relationships and in the principles of its design and evolution ISO 42010: 2011

TOGAF adds the structure of components, the interrelationships, principles, and guidelines governing the design and evolution over time You can read more in the TOGAF Standard, 10th edition, highly recommended you read this.

Interaction business activities and information tech, like applications and data

Architecture domains

Business Architecture:

Business strategy, key business processes
Visualized by: biz capability maps, value stream maps, org maps

Data Architecture:

Structure of org’s logical and other data assets, and data mgmt resources
Visualized by: data dissemination diagram, data entity/biz function matrix

Application Architecture:

Blueprint for individual applications to be deployed, their interactions and relationships to core biz processes of the org
Visualized by: application portfolio catalog, app communication diagrams, app/org matrix

Technology Architecture:

Digital arch + logical soft- and harware infra capabilities and standards to support the biz
Visualized by: Tech portfolio catalog, Platform decomposition diagram

Last 3 = IT architecture

Architecture states

Architecture is never finished, so there are 5 states

Baseline: current state, AS IS

Resting: state where enterprise receives activity if all change activity is suspended (subordinate role)

Transition: In direction of Target, already provides benefits. When the target archi is too big, too expensive, you divide it up in intermediate steps

Candidate: future state, not approved by stakeholders

Target: Future state, approved by stakeholders, TO BE

There’s always a baseline, but not necessarily any other

How to scope

There are four dimensions to limit scope

Breadth/Enterprise: You narrow scope, by limiting to orgs, BUs, departments or processes.

Depth/Level of Detail: how in depth to go?

Domain: What domain should be looked at?

Time Period/Planning horizon: What time period is needed? Doable? Enough resources?

Scope is mostly limited by people, finance, objectives, organisational authority of the EA team

Levels of landscape

Strategic Archi: direction setting at executive level

Segment Archi: supports direction setting and dev of archi roadmaps at a program or portfolio level

Capability Archi: Supports dev of effective archi roadmaps realizing capability increments

Several capability architectures with a higher level of detail and shorter time horizon can detail a segment architecture, for example.

Archi Partitioning

Divide big complicated EA into subset.

Each team carrying out archi activity within their partition.

Apply partitioning until each architecture has 1 owning team

Make sure the partitioning model reflect the enterprise’s operating model

Benefits

Conflict management
Allow parallelization
Reuse architecture segments
Manageable complexity and governance

Archi Abstraction levels

Technique to divide problem area into smaller problem areas that are easier to solve

Why/Contextual: Why is it needed. Understand environment (scope, motivation, goals, objectives)

What/Conceptual: What functionality and other requirements need to be met by architecture? Understand the problem. Requirements and service models e.g. biz, app, tech services

How/Logical: How do we structure the functionality. Identify implementation-independent components to achieve the services, e.g. bizz, data, app, tech components

With what/Physical: With what assets shall we implement this structure. Find alternatives for allocation and implementation of physical components to meet logical components

Levels of archi landscape and the architecture abstraction levels are totally different! You can describe each level of architecture landscape with one or more architectures on a certain abstraction level.

Building Blocks

BB: package or functionality to meet biz needs across org.

Recognizable as a “thing” by domain experts

Has normally a type that corresponds to the Enterprise Metamodel (actor, biz service, application, data entity, etc)

Defined at various levels of detail, depending on objectives of EA

Can lead to improvements in legacy system integration, interoperability and flexibility in creation of new systems and applications

Up to org to decide what arrangement of BBs work best

Characteristics

Considers implementation & Usage, evolves to exploit technology and standards

Re-usable, replaceable, well specified

May be assembled from and subassembly of other BB

May interoperate with other, interdependent BBs based on published and stable interface

Defined boundaries and specification which are loosely coupled to its implementation

Potentially re-usable component, meets biz needs, defined at various levels of details

ABBs (architecture) vs SBBs (solution)

ABB: Architectural components, shape specification, describe required capability, logical or supplier independent: e.g. Tracking

SBB: Realize the required capability, physical or implementation specific (YAML solution, Tracking SDK)

The TOGAF standard

EA framework to develop any kind of archi in any context

Best practice framework by community

Enabled org to operate in an efficient & effective way using a proven and recognized set of best practices to address business & tech trends

Enables orgs to build workable and economic solutions

Adds value, standardizes, de-risks archi dev

Results in EA that’s consistent, reflects needs of stakeholders, employs best practice, considers current and future needs

May adopt, replace elements from other frameworks, and vice versa

Should be tailored and integrated into the processes and org structures

Can be standalone

Structure

Fundamental content is covered by 6 docs

1 is Core concepts 2, 3, 4 are ADM: developing an EA, techniques to apply TOGAF and ADM, adapting to ADM 5 is Architecture content: deliverables, how to classify, store, and re-use them 6 is EA capability and governance: orgs, processes, roles, responsibilities to establish and operate EA

TOGAF library: additional guidance material to support TOGAF approach. Guidelines, templates, patterns, etc

EA purpose and benefits

Purpose

Manage complexity, risk and support change
Optimizes processes into integrated environment that is responsive to change and supportive of the delivery of the biz strat and mission
Achieves balance between biz transformation and operational efficiency
Allow BU to innovate for biz goals and competitive advantage
Enables integrated strat with synergies across enterprise and beyond
Governs change activity to realize expected value
Describes current and future state AND gap of an enterprise
Document processes around personal data easy to understand
Addresses end state, preference trade-offs and value realization for big and little q’s

EA to align biz and IT

Benefits

Better ROI & reduced risk
More effective and efficient digital transformation and operations
More effective strategic decision-making by C-level execs
More effective and efficient biz operations
Faster, simpler, cheaper procurement
Balance across conflicting demands

The ADM

Core of the TOGAF standard. Tested and repeatable process to develop architectures

Iterative cycle of continuous realization that allows enterprises to transform in a controlled manner

The ADM is the heart of TOGAF: a method for developing an enterprise architecture, phase by phase, around a central requirements store. Each circle below is a phase.

The steps are recommendations, not set in stone, don’t use if not relevant

It’s NOT a waterfall method, does not mandate specific sequence

Merely reference model