It’s amazing how principles and styles from the software world map directly to day-to-day events. Let it be core OOP concepts such as abstraction, inheritance, polymorphism or design patterns such as singleton, MVC, MVVM, Observer.

SOA — service oriented architecture. It basically means derivation and integration. In SOA, the solution is divided into different services exposed as HTTP endpoints. In real life, consider your solution to be an organization — MyCompany Inc. Like any organization, it will divide responsibilities among various groups: sales team, marketing team, production team, finance and legal team.

Even though all these teams are headed by the same management folks, they often interact with each other. What makes this interaction possible? From a software point of view, the term would be “A Data Contract.” Two teams can understand each other only if both are agreed upon the same data contract — just like SOA.

By splitting the organization into small focused teams, MyCompany Inc can achieve separation of concerns. Each team is focused on doing one thing, and one thing only — exactly the same for SOA.

The diversity: it’s very unlikely that MyCompany Inc will have each team with the same background, ethnicity, culture. Yet despite all the differences, it has to function. Similarly, as each service is an individual component, each service can have its own environment, from underlying language to production server.

Understanding the way SOA relates to life gives you a much more comprehensive approach for analyzing the pros and cons of this architectural style.