Planning for Architecture Development and Use
Planning the work
Architecture development must be scoped, resourced, and sequenced against business drivers. Key concepts: architecture vision (the target and rationale), scope and boundaries, stakeholder map, architecture principles, maturity assessment, and roadmap/migration planning. Also know architecture capability - the organization's ability to do EA (skills, governance, tools, processes).
Development and use
Planning distinguishes architecture development (creating descriptions) from architecture use (informing decisions, projects, and change). Emphasize requirements management as continuous, not a one-time phase. Recognize tailoring - adapting the framework to organizational context - and architecture maturity models for incremental improvement.
Traps
Questions often imply that planning is complete once a target is defined; in reality scope, stakeholders, and principles must be set first. Another trap is confusing a roadmap (sequenced transition states) with a project plan (tasks and schedules). Also, requirements are not frozen at the start - they evolve and must be managed throughout.
Worked example
A firm wants to "do EA" but has no mandate. The best first move is to establish scope, business drivers, and a stakeholder map, plus a lightweight architecture capability (governance and principles), before producing detailed models. Producing models without sponsorship or scope is a classic failure.
Rule of thumb
Plan in this order: drivers → scope/boundaries → stakeholders/concerns → principles → target vision → roadmap. If an answer skips to modeling before scope and sponsorship, it is usually wrong.
Architecture Modeling
Purpose of models
Models make the architecture understandable and analyzable. A model represents selected aspects of a system; a diagram visualizes part of a model. Models must be consistent with the metamodel and appropriate to the stakeholder's concern.
Modeling concepts
Know abstraction levels (conceptual, logical, physical), modeling languages/notations (e.g., UML, BPMN, ArchiMate-style), and viewpoint-appropriate modeling. Understand traceability (linking requirements to elements), model integrity/consistency, and reuse of reference models and patterns. Recognize architecture building blocks as modeled reusable elements and the role of repositories in storing and governing models.
Traps
Don't treat a diagram as the model. Don't assume more detail is better - detail must match the audience and purpose. Watch for questions that confuse logical (what) with physical (how/where). Another trap is assuming one notation fits all viewpoints; different concerns may need different languages, which must still integrate via a common metamodel.
Worked example
A business stakeholder needs to understand a capability gap; a developer needs interface detail. The correct approach: model the capability at a conceptual level for the business view, and model interfaces at a logical/physical level for the technical view, keeping both traceable to the same metamodel elements.
Rule of thumb
Match model abstraction and notation to stakeholder concern; keep all models traceable to the metamodel. If an answer says "use the most detailed model for everyone," reject it.
Architecture Analysis and Integration
Analyzing architectures
Analysis evaluates an architecture against goals: gap analysis (baseline vs. target), impact analysis (consequences of change), conformance/compliance checks, and trade-off analysis. Know architecture assessment techniques and the use of metrics to judge fitness. Analysis informs decisions; it does not replace governance.
Integration
Integration connects architecture domains (business, data, application, technology) and connects architecture to portfolios, projects, and operations. Concepts: interoperability, integration of reference models, portfolio alignment, and traceability across domains. Understand that integration requires a shared metamodel and consistent terminology.
Traps
Don't confuse gap analysis (what's missing to reach target) with impact analysis (what changes if we act). Don't assume conformance equals quality - an architecture can conform yet miss goals. Another trap is treating integration as purely technical; business/data/application/technology integration is also organizational.
Worked example
A new regulation requires a data change. Gap analysis identifies the missing target capability; impact analysis identifies affected applications, interfaces, and projects; conformance review checks the solution against principles; the architecture board decides. Each step answers a distinct question - questions often blend them.
Rule of thumb
Ask "what question is this analysis answering?" Gap = distance to target; impact = consequences of change; conformance = adherence to standards; trade-off = choosing among options. Match the named analysis to its question.