Enterprise Architecture vs Layered, SOA, Microservices & Cloud‑Native: Which to Pick?

Six Architecture Knowledge Areas

Enterprise architecture, layered architecture, SOA, microservices, cloud‑native and architecture evolution each address a distinct observation scale and core question.

Enterprise Architecture: Defining the Business Direction

A retail‑chain platform must support shared product, order and member capabilities; real‑time inventory visibility; high‑peak concurrency; rapid fault recovery; weekly feature releases; and immutable historical settlement data. These goals cannot be solved by choosing a single database; they require planning across four domains:

Business Architecture – business capabilities, processes and organizational roles.

Data Architecture – core data, ownership, generation, flow, sharing, governance and quality.

Application Architecture – applications, responsibilities, interactions and decisions about retain, integrate, replace or build.

Technical Architecture – compute, storage, network, security, messaging, monitoring and continuous‑delivery platforms.

Enterprise architecture must also produce a baseline, a target, a gap analysis and a migration route; a target diagram without migration steps is incomplete.

Layered Architecture: Organising an Application Internally

Typical four‑layer structure:

Presentation Layer ↓
Business Logic Layer ↓
Data Access Layer ↓
Data Layer

The presentation layer validates input and calls business services; it must not embed core business rules or direct database access.

The business logic layer contains rules, workflows, permission checks and transaction boundaries. Example – creating an order writes the order, order items, deducts inventory and writes payment records, all wrapped in a single transaction that either commits entirely or rolls back.

The data access layer (DAO) hides SQL and persistence details and provides a stable API to the upper layers; it must not decide when a multi‑DAO transaction is committed.

The data layer stores business data, maintains indexes, constraints and executes transactions.

Simply placing code in Controller, Service, DAO folders does not guarantee true layering; true layering is judged by clear responsibilities, controlled dependencies and correct transaction placement.

Can a Microservice Still Be Layered?

Yes. Microservices define business‑level boundaries, while layering organises technical responsibilities inside each service.

Example – an Order microservice may expose an API for creating or cancelling orders, and internally be split into:

Interface Layer – receives requests
Business Logic Layer – validates state, computes flow, controls local transaction
Data Access Layer – reads/writes order and order items
Data Layer – persists order data

Services must not share internal DAOs; cross‑service collaboration must use public APIs or events.

SOA: Integrating Existing Heterogeneous Systems

Legacy systems (CRM, ERP, WMS, logistics, POS, finance) differ in language, protocol, data format and address conventions. Point‑to‑point integration quickly becomes tangled.

Core SOA steps:

Identify stable business capabilities in existing systems.

Encapsulate each capability as a service.

Define explicit service contracts (operations, inputs, outputs, error codes, protocols, security, SLAs).

Use registration, routing, transformation and orchestration to compose services.

Typical SOA artefacts include an ESB for routing, service registration (UDDI), description (WSDL) and messaging (SOAP), and BPEL for workflow orchestration.

Example – an inventory service contract defines operations query, reserve, release, confirmDeduction and also specifies message format, error codes, protocol, address, authentication, timeout and service‑level agreement.

Microservices: Enabling Autonomous Business Evolution

When different business capabilities (order, inventory, promotion, membership) evolve at different speeds, microservices allow independent development, deployment and scaling.

Domain‑Driven Design (DDD) helps define sub‑domains and bounded contexts, ensuring each service owns its data (data autonomy) and communicates via APIs or events.

Cross‑service challenges and common patterns:

Distributed queries → API composition, asynchronous event replication, CQRS read models.

Consistency → Saga, TCC, reliable messaging, compensation.

Duplicate messages → Idempotent keys, unique indexes, state machines.

Quick Comparison: SOA vs Microservices

Main Goal : SOA – enterprise heterogeneous system integration and reuse; Microservices – business‑level autonomous evolution of complex applications.

Service Granularity : SOA – generally coarse; Microservices – usually finer, but not necessarily the smallest possible.

Integration Style : SOA – often centralized ESB; Microservices – lightweight APIs, messaging, decentralized communication.

Deployment : SOA – can rely on large integration platforms; Microservices – emphasizes independent deployment.

Data : SOA – shared enterprise data integration; Microservices – data autonomy and storage isolation.

Governance : SOA – more centralized; Microservices – platform capabilities combined with team autonomy.

Cloud‑Native: Providing Modern Run‑Time Capabilities

Even with microservices, an application may still lack cloud‑native qualities if it relies on manual builds, manual scaling, manual fault detection, sparse logging, or risky releases.

Seven cloud‑native principles:

Service‑orientation

Elasticity (resources scale with load)

Observability (logs, metrics, traces)

Resilience (timeouts, retries, circuit‑breakers, bulkheads, rate‑limiting, degradation, redundancy)

Automation of all processes (build, test, release, scaling, monitoring, rollback)

Zero‑trust security (identity, least‑privilege, encryption, audit)

Continuous evolution (small incremental changes, rapid feedback, canary releases, verification, rollback)

Microservices, Cloud‑Native, Kubernetes & Service Mesh

Kubernetes handles workload deployment, scheduling, scaling and recovery; Service Mesh governs inter‑service traffic, policies, security and observability. Neither decides business boundaries, data ownership or cross‑service transaction handling.

Architecture Evolution: From Target to Reality

Target architecture must be accompanied by a migration plan that considers system requirements, technology, environment and distribution.

Evolution can be static (system offline) or dynamic (system online). Maintenance types include corrective, adaptive, perfective and preventive.

Legacy systems are evaluated on technical level and business value, leading to four strategies: refactor, integrate, retire, or inherit. High‑value, low‑tech legacy (e.g., settlement system) uses the inheritance strategy: reverse‑engineer rules, expose them via adapters, and migrate in phased parallel batches with data sync, verification and rollback procedures.

Complete Retail Modernisation Roadmap

Baseline assessment – catalogue business capabilities, applications, interfaces, core data, platform, decisions and quality issues.

Define target enterprise architecture – plan business processes, data standards, application responsibilities and technical platform.

Encapsulate legacy capabilities via SOA – identify stable abilities, define contracts, use adapters and routing.

Build new autonomous business boundaries – apply DDD, create services with owned data, coordinate via APIs/events, handle distributed queries and consistency.

Implement cloud‑native platform – automate CI/CD, enable elasticity, set up logging/metrics/tracing, apply resilience patterns, enforce zero‑trust, adopt canary releases.

Batch migration & retirement – pilot by region or module, run new and old systems in parallel, verify functional and data correctness, expand gradually, roll back if needed, then decommission legacy modules.

Why the Six Knowledge Shelves Matter

Enterprise architecture sets direction; layered architecture organises internal responsibilities; SOA integrates existing systems; microservices create autonomous business capabilities; cloud‑native supplies modern run‑time and delivery; architecture evolution safely moves legacy systems to the target state.