Mastering SOA Service Architecture: A Complete Planning Methodology & Real-World Case

Overall SOA Service Architecture Planning Methodology

The core principle of Service‑Oriented Architecture (SOA) is decoupling. When decoupling requirements are satisfied, the architecture should enable sharing, collaboration, and reuse. A complete business system is divided into three logical layers: application , service , and resource . The resource layer exposes coarse‑grained capabilities as services, while applications consume shared services to implement functionality.

1. End‑to‑End Business Process Analysis

Start with a top‑down decomposition of end‑to‑end business processes. Break each process into activity units, then group the units into high‑cohesion, low‑coupling business domains and components using matrix analysis (similar to CRUD). Identify cross‑domain interaction points; these become potential service candidates.

2. Data Architecture Planning

After the business architecture, design the data architecture. Focus on Shared Information Data (SID) , which includes master data and shared dynamic data. Apply functional‑data matrix analysis to discover SID objects that serve as inputs/outputs of business activities, and define corresponding data‑service capabilities.

3. Technical Architecture & Common Platform Analysis

Assess cloud‑enabled platform capabilities (IaaS, PaaS). Extract common technical components and component‑based services from the PaaS layer to form a technical service layer that can be reused across business services.

4. Integration Architecture & Interface Catalog

Map the identified business components to integration points and produce an interface catalog. For each interface record:

Data flow direction (e.g., System A → System B)

Synchronous or asynchronous mode

Real‑time vs. batch execution

Implementation technology (DBLink, Web Service, RPC, etc.)

This catalog drives the conversion of interfaces into services.

5. Service Catalog Planning

Convert interfaces into services while ensuring appropriate granularity and reusability. Typical transformation patterns include:

Merge multiple asynchronous interfaces into a single synchronous service.

Split a synchronous interface into asynchronous services for fault isolation.

Separate data‑only interfaces into distinct business services when usage scenarios differ.

Consolidate duplicate data interfaces into a unified service.

Replace point‑to‑point data distribution with a publish‑subscribe mechanism via an ESB.

Classify services into three functional layers (process, business, data) and two technical layers (platform, infrastructure). De‑duplicate, define service attributes, and organize them into a hierarchical service catalog.

6. Service Types

Process Services : Long‑running, automated workflows that require strong consistency and transaction support.

Business Services : Real‑time, rule‑driven operations tied to specific business actions.

Data Services : CRUD‑oriented services for master or shared data, often non‑real‑time.

7. Case Study – Telecom Operator Service Architecture

The case demonstrates expanding an existing MSS domain to a BOSS domain and integrating ERP, CRM, budgeting, marketing, and later OSS resources. Key points:

Component‑based design with public PaaS support.

Shared services registered on an ESB; non‑shared services remain within their business domains.

Gradual SOA migration, allowing shared services to originate from legacy or new systems.

Service classification (process → business → data → platform → technical) and layered calling order.

Service‑view dimensions (process, data, application) derived from the integrated architecture enable multi‑dimensional catalogs (by business type, by data type, etc.).

8. Service Catalog Structure

The final catalog presents services in hierarchical layers, supports full service lifecycle management, and aligns with enterprise‑wide integration and governance. It facilitates:

Service discovery and reuse across projects.

Consistent governance of service attributes (owner, version, SLA, etc.).

Clear mapping from business processes to underlying technical services.

Illustrative diagrams: