The chief enterprise architect walks out of a vendor presentation holding a glossy deck titled "Your TOGAF Transformation Journey." A consultancy has just pitched Aldermont a two-year engagement to roll out a full formal architecture practice, complete with certifications, a documentation standard, and a review process for every project in the bank. It is thorough. It is expensive. And a quiet voice is asking whether the bank actually needs any of it, or whether it needs a much smaller thing done well.
This is the moment nearly every organization reaches once it decides it has an architecture problem. The instinct is to go shopping for a framework, as if picking TOGAF over Zachman were the decision that mattered. It almost never is. The decision that matters is a different one, and getting it wrong in either direction, too much process or too little, is expensive.
The question everyone asks first is the wrong one
"Which framework should we use?" feels like the right opening question because frameworks are the visible, brand-named things in this space. You can get certified in them. Vendors sell tools around them. It looks like the decision.
But a framework is a means, not an end. The previous posts in this series took apart the two biggest names, and the honest summary is that they do different jobs and mostly coexist rather than compete. TOGAF is a method for doing the work. Zachman is a schema for organizing the output. Reaching for "TOGAF versus Zachman" as if you must pick a side misunderstands both.
The core idea: The real decision is not which framework. It is how much architecture rigor your organization actually needs. Once you answer that honestly, the framework question mostly answers itself, and the answer is often "far less formal machinery than the vendor is selling."
So the useful move is to set the brand names aside for a moment and ask what forces should actually drive the amount of architecture rigor an organization takes on.
What actually determines how much rigor you need
The right level of architecture formality is not a matter of taste or maturity-model score. It is driven by concrete properties of the organization. A few matter more than the rest.
Regulatory exposure is the biggest single driver. A bank has to be able to show a regulator how data flows, where customer records live, and who can access them. That auditability is not optional, and it pushes strongly toward formal, documented architecture. A consumer app startup with no such obligations sits at the opposite end.
Scale and integration complexity come next. Aldermont's three cores and tangle of point-to-point integrations are exactly the condition formal architecture exists to manage. An organization running a handful of well-understood systems does not have the complexity that justifies heavy process; the process would cost more than the disorder it prevents.
Rate of change pulls the other way. An organization shipping product changes daily is poorly served by an architecture process that adds weeks of review to every decision. A bank replacing a core over four years can absorb, and benefits from, far more deliberation per decision.
Organizational size and longevity round it out. A large organization that will outlive the tenure of everyone currently working there needs its knowledge written down, because the people who hold it in their heads will leave. A small, stable team can carry more architecture as shared understanding rather than documents.
Aldermont sits far toward the heavyweight end on almost every axis: heavily regulated, large, complex, long-lived, and changing at the deliberate pace of a bank. That, not a preference for TOGAF, is why formal architecture is justified there. The same analysis run on a ten-person startup would land in a completely different place, and adopting the bank's process there would be malpractice.
The case for a formal framework, made fairly
It would be easy to caricature heavyweight frameworks as pure bureaucracy, but the case for them is real and worth stating at its strongest, because for organizations like Aldermont it is often correct.
A formal framework gives you a shared language. When architects, engineers, and business stakeholders all mean the same thing by "capability" or "target architecture," communication across a large organization gets dramatically cheaper. It gives you repeatability: a defined method means the quality of an architecture effort does not depend entirely on whether you happened to assign your one brilliant architect. It gives you auditability, which for a regulated bank is not a nice-to-have but a legal necessity. And it gives you continuity: when the people leave, the documented architecture stays, and the organization does not have to rediscover its own systems.
These benefits scale with the organization. The larger, more regulated, and more complex you are, the more each one is worth, and the more a formal framework earns the overhead it imposes. For a bank consolidating three cores under regulatory scrutiny, the deck the consultancy pitched is not obviously wrong. The question is only whether the bank needs all of it, or a tailored subset.
The case against adopting one wholesale
The opposing case is equally real, and it is where most organizations actually go wrong, because the failure is quieter and easier to rationalize.
The dominant failure mode is cargo-cult architecture: adopting the ceremony of a framework, the documents, the review boards, the certifications, without the judgment that makes it worthwhile. The organization ends up producing artifacts to satisfy the process rather than to make better decisions. This is the exact behavior that earned enterprise architecture its ivory-tower reputation. The documents get made, filed, and never read, and the real decisions get made in hallways anyway.
Heavyweight process also imposes a real speed cost. Every review gate, every required artifact, adds latency. In an organization that needs to move fast, that latency is not free discipline; it is lost opportunity, and it drives teams to route around the architecture function entirely, which is worse than having none.
And frameworks carry a seduction of completeness. Because a framework like TOGAF describes an exhaustive process, there is a pull to do all of it, whether or not each part earns its keep. The framework's own answer is tailoring, but tailoring well is a skill, and organizations that reach for a framework precisely because they lack architecture maturity are the least equipped to tailor it wisely. They tend to implement it whole, and drown.
The middle path — just enough architecture
Between "adopt the full framework" and "do no architecture at all" sits the answer most organizations should actually choose. The idea, sometimes called just enough architecture, is to borrow the specific pieces of formal frameworks that address your real problems, and deliberately leave the rest.
This is entirely legitimate, and the frameworks themselves invite it. TOGAF explicitly expects tailoring. Zachman is a lens you can apply lightly or heavily. FEAF, the US federal government's framework built around a consolidated set of reference models, is specialized for federal agencies, yet commercial organizations routinely lift just its reference models as a starting point and ignore the rest. None of these frameworks demands all-or-nothing adoption; treating them as if they do is a choice, and usually a bad one.
Just enough architecture means asking, for each piece of machinery, whether it solves a problem you actually have. A baseline-target-gap analysis for the core consolidation? Clearly worth it for Aldermont. A canonical data model and a named system of record? Essential, given the three-definitions problem. A full thirty-six-cell Zachman grid maintained for every system in the bank? Almost certainly not; the maintenance cost would swamp the value. The skill is in the selection.
Note that the middle box is the correct answer for most organizations, not all. For a heavily regulated bank, "just enough" may itself be quite substantial, closer to the full framework than a startup's version would be. The point is not that light is always right. It is that the amount should be chosen deliberately against the forces that actually apply, rather than defaulted to whatever the vendor sells or whatever the loudest engineer resists.
A practical way to decide
Stripped down, the decision is a short sequence of honest questions, asked in order.
Start with the forces, not the frameworks. How regulated, large, complex, long-lived, and fast-moving is the organization, really? That fixes roughly where on the spectrum you belong. Then identify the specific problems architecture is meant to solve here: for Aldermont, an unowned customer definition, integration sprawl, and a core migration under audit. Then, and only then, select the pieces of formal practice that address those specific problems, drawing from whichever framework describes them best. TOGAF's ADM for the migration program, a canonical model and system-of-record discipline for the data problem, a targeted review board for the integration sprawl. Finally, write down what you chose not to adopt, so the omissions are deliberate rather than accidental.
What you end up with will not match any framework's name cleanly, and that is the sign you did it right. Organizations that can say "we use TOGAF" with a straight face are rarer than the certification numbers suggest. What most well-run architecture practices actually do is exactly this: borrow deliberately, tailor heavily, and keep only what earns its place.
Summary
The framework question that organizations open with, TOGAF or Zachman or FEAF, is the wrong question. Those are not really competitors, and the choice between brand names is not what determines success. The decision that matters is how much architecture rigor the organization genuinely needs, and that is set by concrete forces: regulatory exposure, scale, integration complexity, size, longevity, and rate of change.
Formal frameworks earn their overhead for large, regulated, complex organizations, where shared language, repeatability, auditability, and continuity are worth real money. They become dead weight for small, fast, unregulated ones, where the ceremony outpaces the value and teams route around it. Most organizations belong in the middle, practicing just enough architecture: borrowing the specific pieces that solve real problems and consciously discarding the rest. For Aldermont, that middle is substantial, because a bank consolidating three cores under a regulator's eye genuinely needs the rigor. For the startup down the road, it is almost nothing. The framework was never the point. Matching the weight of your architecture to the weight of your actual problems is. With that settled, the rest of this series turns from frameworks to the concrete artifacts that do the work, starting with the single most useful one: the capability map.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.