Framework Models
Why frameworks exist
Frameworks give EA a common metamodel, a set of viewpoints, and a process so that architectures are comparable and reusable. Candidates should recognize the major families and what each is for, without memorizing proprietary detail.
Families to recognize
- Zachman: a classification (ontology) organized as a matrix of perspectives (planner, owner, designer, builder, subcontractor) against interrogatives (what, how, where, who, when, why). It is descriptive, not prescriptive - it tells you what to document, not the order.
- TOGAF-style ADM: a cyclic, phase-based method (preliminary, architecture vision, business/data/application/technology architectures, opportunities and solutions, migration planning, implementation governance, change management). Requirements management sits at the center.
- Federal/segment frameworks (e.g., FEAF, DoDAF/MODAF views): organized around reference models and viewpoints for government/defense segments.
- Spewak/EAP: a planning-oriented approach linking business planning to implementation.
Traps
Stems often ask which framework is "prescriptive" (ADM-type methods) versus "descriptive/classifying" (Zachman). Another trap is assuming a framework mandates a sequence - Zachman does not. Also, frameworks are tailorable; claiming one is mandatory is usually wrong.
Rule of thumb
Ask "is this framework a taxonomy or a process?" Taxonomy → Zachman. Iterative process with phases → ADM-style. Reference-model catalog for a segment → FEAF/DoDAF. Match the framework's intent to the question's need.