How do the scope and purpose of TOGAF and the Zachman Framework differ, and why might an organization use both together rather than choosing one exclusively?

## Two things at different layers of abstraction TOGAF and Zachman sit at different layers of abstraction even though people often lump them together as 'the two big EA frameworks.' **TOGAF's core deliverable** is a documented method for taking an organization from an as-is state to a to-be architecture, including how to: - secure sponsorship; - run the engagement in iterations; - set up governance so approved principles are actually enforced against new projects. **Zachman contributes none of that process**; instead, it is a categorization scheme that says: for any system or enterprise, there are several distinct stakeholder perspectives (from someone planning at a strategic level down to someone actually building the thing) and several distinct types of question each perspective needs answered (structural, behavioral, locational, and so on). Every intersection of a perspective and a question type is a distinct kind of model, and Zachman's contribution is naming and separating these so they don't get conflated - so a diagram meant to describe a business owner's view of a process doesn't accidentally get treated as a detailed builder's specification. ## Why each one exists Why it exists: the two frameworks emerged to solve different failure modes. - **TOGAF exists** because architecture engagements without a repeatable method tend to be run ad hoc, project by project, with governance applied inconsistently - one initiative gets rigorous review, another skates through, and there's no consistent way to hand off an engagement between architects. - **Zachman exists** because, independent of process, organizations that don't separate perspectives conflate strategic and detailed models, ending up with either models too abstract to build from or so detailed they can't be discussed with executives. Neither framework alone solves the other's problem: a rigorous TOGAF engagement run without checking artifact completeness can still leave gaps (every application documented from a builder's perspective but never rolled up to an owner's business-value view), while using Zachman's taxonomy alone tells you what's missing but gives no guidance on sequence of work, stakeholder engagement, or governance cadence needed to fill the gaps. ## Trade-offs of each choice Trade-offs: | Choice | Trade-off | |---|---| | **Using TOGAF alone** | risks producing a well-run engagement whose output is nonetheless incomplete or perspective-skewed, because the flexibility about exactly which artifacts to produce at each step means teams can under-invest in stakeholder perspectives that aren't squeaky wheels (business-owner views often lose out to technical builder views because technical staff dominate architecture teams) | | **Using Zachman alone** | gives a rigorous completeness map but zero guidance on how to actually run a transformation program, secure funding, or govern change - an organization could have a perfectly complete inventory and still fail to deliver any architectural change because there's no process wrapped around it | | **Combining them** | costs more coordination: someone has to map TOGAF's artifact types onto Zachman's cells, which is not a natural one-to-one mapping and requires judgment, and maintaining two frameworks' vocabulary in parallel adds cognitive overhead for the team | ## Failure modes 1. A common production failure is treating Zachman **as if it were a process framework** - assigning teams to 'complete the grid' as a sequential project plan, misapplying a static taxonomy as if it prescribed a workflow, leading to confusion about what to do first. 2. Another is running TOGAF's engagement rigorously but **skipping any completeness check**, so the resulting target-state architecture looks thorough to the team that produced it but is missing entire perspectives - commonly the compliance/regulatory perspective, which technical teams routinely underweight until an audit surfaces the gap. 3. A third failure is using the pairing as a **bureaucratic gate**: requiring every project to produce artifacts for every content type mapped against every applicable cell, regardless of the project's actual risk or size, which reintroduces the ritual-compliance problem at a multiplied scale. ## The two together in one program Concrete example: a bank running a core-banking-system replacement program might use TOGAF's engagement structure to sequence the program: - secure architecture governance board sign-off; - define target-state principles; - plan the migration in tranches. It periodically checks its artifact set against a Zachman-style perspective/question matrix, to confirm that the regulatory-reporting question has been answered from both the business-owner perspective (what reports are legally required) and the builder perspective (which data feeds populate them) - catching, for example, a gap where the technical team built the data feeds but no one had validated them against actual regulatory requirements until the completeness check flagged the missing owner-perspective artifact.