As shared previously, I recently started the Enterprise Architecture certificate course at the University of Toronto's School of Continuing Studies, alongside preparing for certifications like AWS Solutions Architect and TOGAF. In my first article, I covered Zachman's rows in detail, which our instructor deep-dived into during lecture one.
This week, lecture two picked up with Zachman's columns, and then opened up to several other frameworks (TOGAF, FEAF, Gartner) along with a handful of related methodologies, all in brief.
That is a lot of new vocabulary for one session. Rather than memorize each name in isolation, I built a mind map, organizing everything top-down so I know where I stand when I have to drive an EA discussion. Some of these frameworks will be taught later in the course, and I will share more as that happens.
I am writing this for myself and share for anyone who is also making the same transition from developer to architect. If that's you too, I hope this saves you some of the sorting-out what I had to do. Note: everything here is still at the "in brief" stage.
What is Enterprise Architecture (EA)?
↓
What frameworks exist?
↓
How do we describe architecture?
↓
How does an architect think?
↓
What questions should I ask?
(0) Core Concepts
What is Enterprise Architecture?
Enterprise Architecture (EA) is a comprehensive framework and organizing logic that aligns an organization's business strategy, operations, and IT infrastructure. It serves as a conceptual blueprint to guide proactive change and achieve desired business outcomes.
Why does it matter?
EA matters because it:
- Aligns IT with business strategy to drive the organization's overarching vision
- Translates strategy into execution through actionable roadmaps
- Cuts costs and complexity by removing redundant systems and promoting asset reuse
- Boosts agility and innovation so the enterprise can adapt quickly to market disruption
What is the core relationship EA manages?
Business ↔ Technology
What is the standard EA sequence?
Strategy → Capability → Process/Value Stream → Solution → Implementation
(1) Core EA Frameworks
Zachman
- Key point: A taxonomy, not a process — classifies what to describe.
- Characteristic: 6×6 matrix (Who/What/Where/When/Why/How × Planner/Owner/Designer/Builder/Implementer). Answers no cell for you, it just labels the cells.
- Links: Getting Started with ISO/IEC/IEEE 42010 (ties Zachman's cells to viewpoints/concerns) · your article on Zachman's rows
TOGAF
- Key point: A repeatable process for producing architecture.
- Characteristic: Driven by the ADM (Architecture Development Method), an iterative cycle through business, data, application and technology architecture phases.
- Links: TOGAF Architectural Artifacts (worked viewpoint/view example)
Federal Enterprise Architecture Framework (FEAF)
- Key point: A government-oriented reference-model framework for cross-agency alignment. A more comprehensive methodology combines the core strengths of taxonomy (like Zachman), and process (like TOGAF)
- Characteristic: Built on the Collaborative Planning Methodology (CPM) and Consolidated Reference Models (CRM), giving US federal agencies a common language for IT investment.
- Links: FEAF overview – LeanIX
Gartner
- Key point: A pragmatic, advisory practice, not a fixed artifact set.
- Characteristic: Iterative and business-outcome-driven; architects act as brokers of trade-offs rather than producers of a mandated deliverable set.
- Links: Gartner EA as a practice model
(2) Conceptual Model of Architecture Description
ISO/IEC/IEEE 42010 (formerly IEEE 1471)
- Defines the conceptual basis for describing architecture: the common terms and how they relate.
- Frameworks that claim conformance to 42010 must be consistent with this model. Frameworks such as TOGAF explicitly use meta-models.
Core idea: the map is not the territory. An architecture description is a representation of an architecture, not the architecture itself.
The standard vocabulary for describing architecture (also called the "meta-model")
| Layer | What it is | Example: online banking system |
| M0 Real world | System, architecture, stakeholder, concern | The bank's actual system. Stakeholders: CFO, security officer. Concerns: cost, data protection |
| M1 Models | Architecture description, views, models (the "map") | A cost view and a security view, each with its diagrams |
| M2 Conventions | Viewpoint, model kind (the "legend") | "Security viewpoint": what to show (threats, controls) and how to draw it |
| M3 Rules for conventions | Makes sure M2 (the viewpoint) is correct and complete | Checks that "security viewpoint" properly specifies its name, stakeholders, concerns, and conventions, regardless of what it's about |
More info: IEEE 1471
Key relationships to remember
- A stakeholder has concerns.
- A viewpoint frames concerns, and a view applies a viewpoint to your system.
- Every view exists to answer a concern.
Easy confusion to avoid: a view is a specific picture of the system, and a viewpoint is the set of rules for drawing that kind of picture.
(3) Design Thinking
Empathize → Define → Ideate → Prototype → Test
- Empathize → understand stakeholders' goals and pain points
- Define → frame the real problem from what you learned
- Ideate → generate a wide range of possible solutions
- Prototype → build a rough, testable version of an idea
- Test → get real feedback, then loop back
These five steps are not intended to be applied in a linear manner.
Feedback loops (this is why it's non-linear):
- Test → Empathize: "Learn about users through testing"
- Empathize → Define: "Empathy helps define problems"
- Test → Ideate/Prototype: "Tests create new ideas for projects"
- Prototype → Ideate: "Prototype sparks a new idea"
- Test → Define: "Tests reveal insights that redefine the problem"
These five steps are not intended to be applied in a linear manner.
(4) Key Questions
Instead of memorising definitions, remember the questions an architect should ask:
What are we trying to achieve? (Strategy)
→ The business goal or outcome driving the whole discussion. If this isn't clear, nothing below it matters.What business capability do we need? (Capability)
→ The "what the business must be able to do" to reach that goal, independent of how it's built.What processes support it? (Process / Value Stream)
→ The sequence of activities that deliver the capability, and who's involved in each step.What information/data is involved? (Data)
→ What needs to be captured, stored, shared, or protected for the process to run.What applications support it? (Application)
→ The software/systems that execute the process and manage the data.What technology enables it? (Technology)
→ The infrastructure, platforms, and tools the applications run on.Who owns what? (Ownership)
→ Which stakeholder is accountable for each capability, process, system, or decision — asked at every layer above, not just once.What constraints and dependencies exist? (Constraints)
→ Budget, regulation, legacy systems, timelines, or other systems this depends on — also checked at every layer.Honestly, I can't wait to get into the details in the next few lectures, especially TOGAF's ADM and the rest of that 42010 stuff I only skimmed here. I will keep sharing as I go, so more mind maps coming your way. Stick around for the next one!
