Service-Oriented Architecture (SOA) has been around for a long time, but in the last years it has started to become the obvious solution to many problems: where RPC, and CORBA are unwieldy, and big entreprisey J2EE apps communicating with SOAP are a pain to work with, web apps using JSON are a godsend.
Technical advantages
In my opinion, a big advantage SOA brings is the possibility of designing your information architecture using sensible software patterns, leading to many advantages:
- tight cohesion: information that belongs together is managed together within the same service;
- loose coupling: since the information architecture is designed to leverage interoperable services, you can upgrade portions of your information architecture without impacting other sections;
- separation of concerns and encapsulation: each service provides authoritative information in a designated area. The interface is clearly specified to maintain compatibility, and the internal implementation is free to adapt to the circumstances (e.g. new tax laws);
- testability: each service can be developed, tested, and improved independently. As you probably know, dividing complex problems into small manageable pieces leads to higher quality, as testability increases and complexity is reduced;
- availability: service failover can be managed according to criticality. Critical services can be heavily redundant, whereas “nice to have” services will simply provide a degraded service on failure;
- future-proofness: services can be reused once implemented, but more importantly, they can also be moved without significantly impacting the entire architecture. In an era where commoditized cloud platforms are being leveraged so IT departments can focus on delivering business value, it makes little sense to lock your software into your own hardware;
- business value: using the various services as basic “information components”, it is possible to recombine them into specialized tools tailored to business processes. Instead of having to deal with a hodgepodge of incompatible tools and munging data through Excel and Access (or by hand), employees can be empowered with tools specially adapted to their jobs. And given the SOA nature of the information architecture, information entered or manipulated with these tools is immediately available to other services and tools: no duplication, no propagation latency.
Business advantages
As mentioned above, a service-oriented information architecture can reduce technical risk and overhead, as the redundancy of each service is adapted to its criticality. But SOA also reduces business risk: implementing large projects with a big bang methodology is quite a risky bet. This very reason makes ERP switches (or even updates!) treacherous, because it’s an all or nothing affair: you cannot “half implement” and ERP system.
In contrast, SOA enables you to take a much more gradual approach that Martin Fowler calls the StranglerApplication:
gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.
This approach, applied to a service-oriented information architecture, means you can start with implementing one service after the other and interconnecting them, until there is no need for the old system. By dividing the changeover into manageable components, you will not only reduce the complexity of the final system, but you can also involve end users and other stakeholders more efficiently throughout the development process (putting in place a tight feedback loop encouraged by agile methodologies, to ensure the final product meets end user needs, and to benefit from their immediate buy-in).
Finally, SOA provides much more flexibility and avoids vendor lock-in: as services can be replaced independently (as long as they implement the specified interface), one vendor’s service can be replaced for another’s, or developed in-house (if your needs have evolved beyond market offerings). If, on the other hand, you have a monolithic ERP containing all of your information, business rules, and processes, you’ll be in a difficult situation if your vendor decides to suddenly jack up license and maintenance fees (or worse, goes bankrupt), or you need a specialized application layer that can only be developed by said vendor…