Enterprise Architecture

Enterprise architects use Porter's value chain to map out every business activity, from making the product to selling it, and check which IT systems support the activities that make money versus the ones that just keep things running.

The model says a company has four building blocks: business strategy, IT strategy, how the business runs day-to-day, and how IT runs day-to-day. 'Strategic fit' checks that strategy matches daily operations on each side; 'functional integration' checks that the business side and IT side match each other. Usually business strategy drives everything, but sometimes new tech should shape business strategy instead.

Demand management decides which requests for IT work get approved and in what order; supply management decides how IT actually delivers that approved work. If a company is great at delivering work but bad at deciding what to accept, IT ends up efficiently building a pile of things nobody prioritized well, or business units just go around IT entirely.

A business capability is a 'what the business does' (like 'manage orders' or 'onboard customers'), not how it does it. On the heat map, colors like red/yellow/green flag things like poor system support, high cost, or strategic importance, so leaders can see at a glance where to spend money first.

For years, companies spent huge amounts on computers but overall economic productivity numbers barely moved — that mismatch was the 'IT productivity paradox.' Even today, tracing one specific IT project to a specific business result is hard because benefits show up late, get mixed with other changes, and are often invisible to the metrics you're using.

A capability is 'what' a business can do (e.g., 'Manage Customer Orders') - stable and abstract. A process is 'how' it's done, step by step, and changes more often.

You go capability by capability and record which software systems support it, usually with a score for how well. This reveals systems that do the same job twice (waste) and capabilities with no system support at all (gaps).

You start with a handful of big-picture abilities the business needs (L1, like 'Sales'), then break each into more specific abilities (L2, L3) until each item is concrete enough to map to real work and systems, but not so detailed it becomes a task list.

You color each capability red, yellow, or green based on two things: how important it is to the business, and how good the technology behind it currently is. Important capabilities with bad technology get funded first.

Nobody owns updating it after the workshop ends, so it drifts out of sync with reality. Fix it by making updates a required step whenever something relevant changes, like adding a new app, instead of relying on a big periodic refresh.

An EA framework is a shared template and rulebook for describing how a company's business, data, applications, and technology fit together, so different teams draw the same kind of 'map' instead of everyone inventing their own.

TOGAF is a step-by-step process for building an architecture and governing change; Zachman is a checklist grid for making sure nothing important got left undocumented. They solve different problems, so many teams use both.

Look at how much pain the company is already in from not having one - duplicated systems, messy acquisitions, no one owning decisions - then start with the smallest set of shared rules that fixes that specific pain, and grow the framework only as the pain (or the company) grows.

The document was written for architects, not executives - too much technical detail, not enough plain statement of 'here's the risk, here's what it costs to fix, here's the decision we need from you.' Fix it by adding a short executive-level summary matched to what that audience actually needs to decide.

FEAF helps US federal agencies organize IT spending and services around citizen-facing performance goals; DoDAF helps the military describe complex weapons/command systems that must interoperate under strict mission and security rules. Both are built for government reporting laws that private companies don't have to follow.

A reference architecture is a reusable blueprint - a pre-thought-out set of building blocks and how they fit together - built by an industry group or vendor from many companies' experience. Adopting one (like BIAN for banks) saves time, avoids reinventing common problems, and makes it easier to talk to other banks, regulators, and vendors using shared terms.

A landing zone is the pre-built, secure foundation a cloud workload gets deployed into - accounts, networking, identity, logging, and guardrails already set up - so teams don't each reinvent security and structure from zero.

You don't build everything the standard defines. You compare the standard's building blocks against what your business actually does, pick the ones that match, merge or skip the ones that don't apply, and write down where and why you differ - then use that trimmed-down map as your real target.

Forcing everything to match the standard exactly - even where the company's real business doesn't work that way - creates clunky software that's hard to change, because you're bending your actual business logic to fit someone else's generic model instead of the other way around.

Treat the adopted architecture like a living product, not a one-time diagram. Someone owns it, changes get reviewed and versioned, and you regularly check whether what teams actually built still matches what was agreed - fixing drift before it piles up.

A group of senior architects that checks a project's design against company rules before it can move forward, and either approves it, asks for changes, or grants an exception.

The team formally asks for permission to break the rule, explains the risk, gets a time limit and an owner assigned to fix it later, and the request is tracked so it isn't forgotten.

Architecture checks should happen at key funding/decision points in a project's lifecycle - early enough to catch problems before money is spent building the wrong thing, but late enough that there's an actual design to review.

It's a percentage showing how well a project follows the architecture rules, based on how many principles it meets versus breaks - but it can lie if it treats a minor rule and a critical security rule as equally important.

Automate the easy, objective rule checks so they run constantly without needing people, save human review time for the genuinely hard judgment calls, and keep revisiting the rules themselves so they don't go stale.

Gap analysis compares what you have now (baseline architecture) with what you want (target architecture) to find missing, changed, or removed pieces — those differences become the work items on the roadmap.

Jumping straight to the end-state is risky because it's slow, all-or-nothing, and hard to fund — transition architectures are safe stopping points along the way, and you add more of them the longer or riskier the journey is.

You map out what each piece of work needs to be finished before it can start — like the identity platform needing to exist before other systems can use it — draw that as a dependency graph, and let the graph, not people's preferences, decide the order.

No — executives need a simple picture of business outcomes and timing, while delivery teams need the technical detail of what to build and in what order. Same underlying plan, different level of zoom and different language.

Running two systems in parallel for a long time means double the cost, double the bugs, and data can quietly drift out of sync between them — you mitigate by keeping the overlap as short as possible and constantly verifying the two sides agree.

TOGAF ADM is a repeating cycle, not a one-and-done checklist — you go around the phases again as things change. Requirements sit in the middle because every phase feeds requirements and consumes them, not just the first phase.

In each phase (B, C, D) you describe where you are now (baseline), where you want to be (target), and list the differences (gaps). Phase E then turns those gap lists into a plan for closing them.

The Preliminary Phase sets up the org's general capability and rules for doing architecture, done once and reused; Phase A defines the scope, stakeholders, and vision for one specific architecture effort using that capability. One is setup, the other is a per-project kickoff.

Phase G checks that projects being built actually follow the approved architecture, like a code review against a spec. Phase H watches the outside world for changes that mean the architecture itself needs updating, like noticing your spec is now outdated. One polices delivery; the other watches for drift in reality.

Phase E figures out WHAT to build (grouping gaps into projects, build-vs-buy) and roughly HOW (transition steps). Phase F figures out WHEN and in what ORDER, based on cost, risk, and business priority. Merging them tends to produce a plan with no real prioritization behind it.

One axis lists six questions people ask about a system (what, how, where, who, when, why). The other axis lists six viewpoints, from a big-picture business view down to a working system. Each cell is one specific artifact type.

Zachman is just a filing system for architecture documents - it says what boxes exist, not what order to fill them in or how. A methodology, like TOGAF's ADM, tells you the actual steps and process to follow.

The six questions are what, how, where, who, when, why - covering data, process, location, people, timing, and reasons. Zachman wants one diagram per question, not one messy diagram trying to show everything at once, because mixing them hides gaps and makes each piece harder to change independently.

At the top, 'What' data is just a list of important business things, like 'Customer' or 'Order.' Lower down it becomes a detailed database table with exact columns, data types, and constraints that a machine can actually run.

Trying to fill in every single box before doing any real work usually takes forever, costs a lot, and produces documents nobody reads. Zachman works better as a checklist you consult when you need it, not a giant homework assignment you must finish first.

Business layer = what the company does for customers (processes, services). Application layer = the software that supports those processes. Technology layer = the infrastructure (servers, networks) that runs the software. Higher layers use services from the layer below.

Active structure = the 'doers' (people, systems). Behavior = the 'doing' (processes, functions, actions). Passive structure = the 'stuff acted upon' (data, documents). An application component is active structure, an application function is behavior, and a data object is passive structure.

A single diagram with everything in it overwhelms every audience. A viewpoint is a filtered slice of the full model showing only the elements and relationships relevant to one audience's concerns - like showing execs a simple business-capability picture and showing infra teams a detailed network diagram, both pulled from the same underlying model.

'Realization' means one thing implements a more abstract thing (like a component realizing a service). 'Serving' means one thing provides value or support to another that uses it (like a service serving a process). Mixing them up makes the model say the wrong thing about how pieces actually relate.

Motivation elements capture WHY the architecture looks the way it does (stakeholder concerns, goals, requirements). Implementation & Migration elements capture HOW you get from the current state to a future state (work packages, plateaus, gaps). Together they connect 'why we're changing' to 'the concrete steps of the change'.

APM is keeping a living list of every application a company runs — what it does, who owns it, what it costs, and how risky it is — so leaders can decide what to keep, fix, or retire.

TIME sorts each app into one of four buckets based on how well it works technically and how much the business needs it: keep as-is (Tolerate), grow it (Invest), replace it (Migrate), or shut it down (Eliminate).

You rate each app on how well it meets business needs and how healthy its technology is, using weighted criteria and more than one reviewer, then use the scores to compare apps fairly — but scores are easy to fake if the app's own team is the one scoring it.

Compare what each app actually does, who uses it, and what it costs; merge the truly overlapping ones onto one shared platform to save license and maintenance cost — but only if they really do the same job and forcing everyone onto one tool won't break something a specific team genuinely needs.

Big companies often have great-looking inventory tools full of stale or made-up data because updating them is nobody's real job; fixing it means tying updates to things people already have to do — like budget approval or a security review — and making the data verifiable rather than self-reported.

A tech radar sorts technologies by trust: Assess = worth reading about, Trial = try it on a real but low-risk project, Adopt = safe default choice, Hold = don't start new work with it. Technologies move outward to inward as teams gather real evidence.

A standards catalog with allow/deny lists is a strict rulebook: things on the allow list can be used, things on the deny list can't, often enforced by tooling. A tech radar is softer — it shows maturity and trend, guiding choice without hard-blocking most of it. Orgs usually use the radar to decide what belongs on the strict list.

Announce the deprecation early with a clear reason and a replacement, mark the old version as deprecated (warnings, docs) while still supporting it for a while, set a firm but generous sunset date, help teams migrate (tooling, guides, office hours), and only remove or break it after most teams have moved and the deadline has passed — extending only for genuinely blocked cases.

Before starting a trial, agree on a deadline and clear pass/fail signals — like production stability for a set period, a cap on incidents, and team feedback above a bar. If those aren't met by the deadline, the trial ends and the technology moves back out (to Assess or Hold) instead of just lingering.

Advisory means the radar is guidance teams can ignore under pressure; enforcement means automated checks block non-compliant choices. Enforcement gives consistency but slows teams down and can block legitimate exceptions; advisory is flexible but easy to ignore. Choose advisory when the org is small, risk is low, or the technology landscape is still being explored.

Centralized: one team makes all architecture decisions. Federated: a central team sets standards, local architects apply them per team. Decentralized: each team decides its own architecture with no central control. They trade consistency for speed and autonomy.

Enterprise Architects set org-wide strategy and standards across many systems; Solution Architects design one specific solution within those standards. In RACI, the EA is usually Consulted (or Accountable for compliance), the Solution Architect is Responsible/Accountable for the actual design.

Embedded architects sit full-time inside one delivery team and share its daily work; pooled architects sit in a central group and get pulled into projects part-time or for reviews. Embedding buys context and speed; pooling buys consistency and flexible allocation.

An ARB is a small standing group of senior architects (and sometimes security/ops reps) that meets regularly. Teams bring significant design decisions to it at defined checkpoints, like before major projects start or before big changes ship.

As teams multiply, the central standards group can't keep up, escalation stops happening, and teams quietly go their own way again. Watch for a shrinking share of decisions actually reaching the center and standards documents nobody follows anymore.

BDAT = Business, Data, Application, Technology. Business is how the company works (processes, org). Data is what information exists and what it means. Application is the software that manages it. Technology is the hardware/infrastructure it all runs on.

Usually business needs come first, then what data is needed, then what software manages it, then what hardware/platform runs it. Picking the technology before deciding on business and data needs often means building the wrong thing or locking into limits that don't fit later.

Start by mapping which business processes are actually merging, then trace what data those processes touch, then which apps manage that data, then what technology those apps run on. Don't model the whole company - only model the parts the merger actually touches, and widen the scope only if you find hidden connections.

Because the meaning of information, like what a "Customer" is, needs to stay consistent across many different apps that use it. If each app defines it its own way, you end up with conflicting, duplicated data that nobody can fully trust.

Models go stale because nobody keeps updating them as small everyday changes happen, and no process forces changes to be reflected. Whether to fix them depends on whether people actually rely on them to make real decisions - if not, maintaining them is wasted effort.