EA Frameworks

## What an EA framework is An enterprise architecture (EA) framework is a structured set of conventions for describing how an organization's strategy, business capabilities, data, applications, and technology infrastructure relate to one another: - **viewpoints** - standard categories of information; - **deliverables** - standard document/artifact types; - shared terminology, and often a repeatable process. It exists to solve a specific organizational problem: large enterprises accumulate architecture knowledge in the heads of individual architects and in ad hoc diagrams that use inconsistent notation, cover different scopes, and go stale the moment their author moves teams. A framework turns that tacit, personal knowledge into an **explicit, comparable, and governable** body of work. ## How it works in practice Concretely, the mechanism is this: adopting a framework means an organization picks (or tailors) a taxonomy of 'what gets documented' and 'how.' For example, a framework might dictate that: - every business capability has an owner; - every application has a lifecycle status; - every data entity has a system of record; - and that these are captured in artifacts of standardized types - capability maps, application portfolios, data flow diagrams - stored in a shared repository. Architects across different domains (business, data, application, technology) populate this repository following the same rules, so a business-capability model built by one team can be cross-referenced against an application inventory built by another without a translation step. Governance boards then use these artifacts as the basis for decisions: - is this new system duplicating an existing capability; - does this initiative violate a target-state principle; - what is the impact of decommissioning a given application. ## The three failures it mitigates Why it exists, and the problem solved: without a shared framework, three failures recur at scale. 1. The first is **incomparability** - one team's 'logical data model' and another's 'conceptual data model' mean different things, so artifacts can't be merged or compared. 2. The second is **invisibility of duplication and gaps** - without a common capability taxonomy, it's hard to notice that three business units each built their own customer-lookup service, or that no one owns fraud-detection capability at all. 3. The third is **loss of institutional memory** - when the one architect who understood a system leaves, undocumented tribal knowledge leaves with them. A framework mitigates all three by forcing consistency in how knowledge is captured, independent of who captures it. ## What it costs Trade-offs: the cost of a framework is process overhead and a real risk of bureaucracy. Populating and maintaining artifacts to a framework's standard takes real architect time that competes with delivery work; a heavyweight framework applied to a fast-moving startup or a small division can generate paperwork nobody reads that goes stale faster than it's produced, becoming **compliance theater** rather than a decision-support tool. Conversely, an organization with no framework at all under-invests in consistency and pays for it later, in duplicated systems, integration surprises during M&A, and audits that can't answer basic questions like 'what personal data do we hold and where.' The right amount of framework rigor scales with: - organizational **size**; - **regulatory exposure**; - how distributed the architecture **decision-making** is. A five-team startup and a multinational bank need very different weights of process even though both benefit from some shared vocabulary. ## Failure modes in production Failure modes in production: 1. The most common failure is **'framework as ritual'** - artifacts get produced to satisfy a governance gate (an architecture review board sign-off) but are never used to make an actual decision, and nobody updates them once the review passes, so within a year the repository is a graveyard of stale diagrams that people distrust and stop consulting, which then justifies further disuse. 2. A second failure is picking a framework whose **scope mismatches the actual problem**: adopting a heavyweight, standards-body-driven framework because it's well known, when the organization's real pain point is a narrow application-rationalization exercise that a lightweight capability map would have solved in a fraction of the time. 3. A third is treating the framework's **artifacts as the deliverable** rather than the decisions they should enable - success gets measured by 'number of diagrams produced' instead of 'number of duplicate systems eliminated' or 'time to answer a data-lineage question.' ## The named frameworks A concrete example of each: | Framework | What it provides | Typical home | |---|---|---| | **TOGAF** | is the most widely adopted general-purpose framework, providing a process plus a content metamodel and reference models | common in large private-sector enterprises undertaking transformation programs | | **The Zachman Framework** | by contrast, a pure classification taxonomy with no built-in process | often used alongside a process framework like TOGAF to check completeness of coverage | | **FEAF** and **DoDAF** | US federal-government-specific frameworks mandated by law/policy | civilian agencies and defense programs respectively, each tuned to their sector's mission and reporting obligations | A commercial enterprise typically has no reason to adopt DoDAF; a defense contractor delivering systems to the Department of Defense typically has no choice.