Enterprise Integration Architecture: Balancing Traditional Services and Micro‑services in a Distributed Multi‑Center Model

Although SOA and micro‑services are frequently discussed, many still lack a clear understanding of what a service truly is; the author argues that services should be versioned and that architectural tweaks alone cannot solve efficiency problems without first clarifying the relationship between service governance and organizational structure.

Enterprise internal integration must reconcile heterogeneous legacy systems that favor stability with new systems that demand modern, scalable architectures, leading to a need for non‑intrusive adapters that expose interfaces on demand, which makes a fully decentralized (center‑less) integration model unsuitable.

The author illustrates that traditional point‑to‑point connections already form a de‑centralized mesh, and forcing adapters into each application would effectively duplicate ESB functionality, increasing overhead without real benefit; moreover, security considerations demand a physical dispatch center for service composition.

To alleviate centralized load, the article proposes partitioned multi‑center architectures where each business line operates an independent ESB cluster, distributing front‑end request pressure across several centers and improving throughput by adding resources where needed.

For query‑heavy services, data redundancy techniques such as ODS, data warehouses, and read‑write separation are compared; the author favors read‑write separation for higher hit rates and lower coupling, noting that excessive reliance on ODS can degrade performance and increase system inter‑dependency.

A real‑world case from a large insurance company demonstrates a distributed multi‑center design that aggregates internal capabilities, partner services, data services, and third‑party internet services into a unified ecosystem, with global routing enabling transparent access to any service regardless of its physical location.

The capability center’s logical components—Out (service implementation), In (service API gateway), and Router (global service routing)—are described, showing how they enable transparent service consumption, asynchronous communication via queues, and extensibility for security, monitoring, and other domain‑specific needs.

The Internet Open Platform layer adds developer portals, service gateways, OAuth authorization, and operational monitoring, deploying micro‑services on a private PaaS cloud; however, legacy monolithic applications often resist PaaS deployment due to size and lack of intrinsic service orientation.

Additional centers (External Connectivity, Master Data, Composite Service) provide specialized functions such as partner integration, data synchronization, and workflow composition, completing the multi‑center ecosystem.

In summary, the distributed multi‑center architecture offers flexibility to tailor solutions to client contexts, supports both registration‑based and approval‑based governance, and, when combined with the S++ service model, delivers decoupled micro‑services, simplified orchestration, business agility, higher performance, and improved security.