5 exercises — choose the best-structured answer. Focus on TOGAF in practice, capability modelling, integration architecture, governance, and business-technology alignment.
Structure for enterprise architect interview answers
Tip 1: Ground frameworks in practice: When asked about TOGAF, name what you actually apply (capability models, ADM phases, architecture principles) — not just that you know the framework exists
Tip 2: Separate architecture from implementation: EAs define patterns and constraints; project teams implement. Your language should reflect boundary awareness
Tip 3: Show business-technology bridging: the EA's value is translating business capability gaps into technology decisions — name the capability model explicitly
Tip 4: Address governance pragmatically: name the difference between governance that enables (guardrails) and governance that blocks (bureaucracy)
0 / 5 completed
1 / 5
The interviewer asks: "How do you use TOGAF in practice? What parts do you actually apply day-to-day, and what parts do you find less useful?" Which answer demonstrates real-world experience with the framework?
Option D is strongest: it identifies the four parts of TOGAF with genuine practical value (architecture principles with concrete example, capability modelling with definition, Phase A scoping, architecture decisions log), explains what it leaves out and why (content metamodel overhead not cost-effective except in regulated environments), and names the most important TOGAF contribution (shared vocabulary + capability-gap question). Options A and C describe TOGAF accurately but don't demonstrate the discriminating judgment that separates experienced practitioners from framework-reciters. TOGAF in practice: architecture principles (8–12 tailored) + capability model (business capabilities → technology enablers) + Phase A (Architecture Vision scoping) + decisions log. Leave aside: full content metamodel unless audit required.
2 / 5
The interviewer asks: "How would you rationalise a portfolio of 50 overlapping internal applications across a large enterprise?" Which answer best demonstrates a structured rationalisation approach?
Option B is strongest: it defines a five-stage process (inventory, fit/value assessment, consolidation candidates, stakeholder alignment, sequencing), includes both financial and technical metrics in the inventory phase, names the Time/Value matrix and application lifecycle model as evaluation tools (Invest/Migrate/Tolerate/Eliminate), explicitly addresses organisational politics as a real constraint, and specifies the sequencing consideration (decommission in dependency order). Option A is a superficial approach that misses the capability and dependency analysis. Application portfolio rationalisation: (1) Inventory (capabilities, TCO, health) → (2) Fit/value matrix (Invest/Migrate/Tolerate/Eliminate) → (3) Consolidation clusters (functional overlap) → (4) Stakeholder alignment (business value framing) → (5) Dependency-ordered sequencing (2–3 year horizon).
3 / 5
The interviewer asks: "Your organisation has 20 systems that need to share data — what integration architecture would you recommend?" Which answer best covers the integration architecture decision?
Option C is strongest: it classifies integration by pattern type rather than recommending a single universal approach, names three distinct patterns (API gateway, event streaming, process orchestration) with their respective use cases, explicitly rejects ESB (centralised brittle coupling) and point-to-point (380 connections = unmaintainable), names the master data management principle (one system of record per domain, no bi-directional sync without conflict resolution), and gives specific tooling names (Kafka, Temporal, Camunda). Integration architecture for 20 systems: classify by pattern → sync = API gateway (not ESB) → async data propagation = event streaming (Kafka) → complex workflows = orchestration engine (Temporal/Camunda) → MDM = one system of record per entity. Avoid: ESB coupling, point-to-point explosion.
4 / 5
The interviewer asks: "How do you make architecture governance useful rather than a bureaucratic obstacle?" Which answer best demonstrates governance maturity?
Option A is strongest: it defines a tiered decision model that matches governance intensity to decision risk (solving the core bureaucracy complaint of over-governance), explains the principle of proactive guardrail publication (governance confirms compliance rather than discovers violations), distinguishes mandatory from advisory review, names architecture fitness functions as the automation approach for shifting to continuous governance, and adds outcome metrics with interpretation guidance (high bypass rate = governance friction exceeds value). Architecture governance anti-bureaucracy: (1) Tiered decision model (team/guild/ARB by risk level) → (2) Proactive guardrails publication → (3) Advisory default, mandatory only for high-risk categories → (4) Automated fitness functions in CI → (5) Measure throughput, re-work rate, bypass rate.
5 / 5
The interviewer asks: "How do you translate business capabilities into technology decisions? Walk me through your approach." Which answer best demonstrates the business-technology bridging skill?
Option B is strongest: it defines the five-step process of capability-based alignment (capability map construction, heat map assessment, gap identification, technology decisions framed as capability enablers, business validation), explains the layered capability decomposition (L1/L2/L3), names the capability heat map dimensions (IT enablement level, quality, strategic investment), gives a concrete example of identifying misalignment (Customer Experience strategy vs. Red-rated Customer Onboarding capability), and critically reframes how technology decisions should be articulated ("this improves [capability] enabling [business outcome]" rather than technology-for-technology's-sake). Option D names ArchiMate correctly but doesn't explain the business-technology bridging process. Business-technology alignment: (1) Business capability map (L1/L2/L3, independent of IT) → (2) Capability heat map (IT enablement + quality + strategic investment) → (3) Gap identification vs. strategy → (4) Technology decisions framed as capability enablers → (5) Business stakeholder validation.