Enterprise Architecture and Integration
Architecture domains and integration styles
Enterprise architecture (EA) describes the business, data, application, and technology layers and the roadmap that connects current-state to target-state. Frameworks such as TOGAF's ADM and Zachman's taxonomy give candidates vocabulary, but exam questions usually test judgement, not memorized phase letters. Know the difference between architecture (long-lived standards and principles) and solution design (a specific delivery). Integration patterns matter: point-to-point links are simple but scale poorly; hub-and-spoke and enterprise service bus (ESB) centralize mediation; API-led connectivity exposes reusable services; event-driven pub/sub decouples producers from consumers.
Traps: treating an ESB and an API gateway as interchangeable (the gateway handles external API policy and routing, the ESB historically handles message transformation and orchestration); assuming SOA requires an ESB; and confusing orchestration (a central controller calls each step) with choreography (services react to events). Also watch for synchronous assumptions in distributed workflows-retries without idempotency create duplicate orders.
Worked example: an order process must reserve stock, take payment, and ship. A single orchestrator is appropriate because the steps form one business transaction and compensation is needed when payment fails. By contrast, a customer-updated event should be published to multiple subscribers without the order service knowing who consumes it. Rule of thumb: orchestrate a single complex process you own; choreograph cross-domain notifications, and make every consumer idempotent.