First of all the term “Service oriented Architecture” (SOA) is a software design/ architectural style from the late 1990s that makes software components reusable, usually on enterprise level. In comparison the small brother, called “micro” service architecture (MSA), is typically applied within one application context/ domain.
Independent from the scope of application, services lead to capabilities which also address organizational questions:
- Service contracting: API ensures consistency and predictability of value flowing, between clearly defined value creating unit of work (primarily the main processes)
- Service coupling: Loosely coupling allows independent capability development
- Service reuse-ability: Expertise is centralized and bottlenecks can be easier identified or the other way around, units of work can act autonomously (also the support processes)
- etc.
One important aspect and difference between SOA and its small brother “microservices” is the statefulness. SOA services have to keep the state between calls from/ to other (e.g., via an Enterprise Service Bus, short ESB), “microservices” are stateless.
Sub-clause: In other words SOA is more the Business-Process-Management (BPM) and “microservices” the Adaptive-Case-Management (ACM) play.
Don’t worry about the term “micro” and the statefulness. It just summarizes the scope of a state change. Reflected on organizations, you should break it down into smaller (logical) parts and start to change on these smaller organizational parts. Some call it continuous evolution or agility.
Equal applies to organizational changes.
Sources:
- https://www.leadingagile.com/2016/10/guiding-organizational-design-soa/
- https://www.opengroup.org/soa/source-book/wp_soa4bt/p4.htm
- http://soa-manifest.de/soa-manifest.html
- http://soa-manifest.de/prinzipien.html
- https://www.researchgate.net/figure/Overview-of-the-SOA-Problem-and-Solution-Space_fig1_200827741
- https://www.axoniq.io/blog/soa-versus-microservices