Service-Oriented Architecture

DabbaGo's tiffin, grocery and catering businesses all need to check a customer's address, send an invoice, and look up a kitchen. Each team has written its own version of all three. When the tax rules on invoices change, three teams make three different fixes. Leadership asks the obvious question: why not build each of these once and let every business use it?

The rule

Build shared business capabilities once, behind contracts everyone can call.

Service-oriented architecture (SOA) is a style that became popular in large organisations in the 2000s. Its main ideas:

• Services are business capabilities, often fairly large: an Invoicing service, a Customer service, an Address service.
• Contracts come first. Each service publishes a formal description of its operations and data, and consumers depend on that contract, not on how the service works inside.
• Reuse across the enterprise. Many applications call the same service instead of building their own.
• Shared integration layer. Services are often connected through central middleware, commonly called an enterprise service bus (ESB), which routes messages, transforms data formats and connects old systems to new ones.

For DabbaGo, one Invoicing service would produce every GST invoice for all three businesses. A tax change is fixed once, in one place, and every business gets it.

The costs are real:

• Central coupling. If the bus or a popular shared service slows down, every business slows down with it.
• Slow change. Changing a contract needs every consumer to agree and adapt, so shared services tend to change slowly.
• Smart middle. When the bus holds routing and transformation logic, important behaviour ends up in a central place that only a specialist team understands.

These costs are part of why a newer style, microservices, later pushed the opposite way: smaller services owned by single teams, and simple pipes between them. That is the next lesson.

The shortcut

Ask "Is this capability the same everywhere, and does it change rarely?" If both answers are yes, a shared service pays off. If each business needs its own variation, or it changes weekly, sharing mostly adds meetings.

The trap is sharing everything "for reuse". A capability that each business needs slightly differently becomes a shared service with endless options that nobody can change safely.

Drills

Answer fast — trust the rule.

Remember

• SOA builds shared business capabilities once, behind contracts everyone can call.
• Shortcut: share what is the same everywhere and changes rarely.
• Trap: sharing everything, and putting business logic into the central bus.