Independent applications before SOA is put in place

Service oriented architectures (SOAs) are about reuse. The goal of a service-oriented architecture is to build applications using modules that (1) look like network services, (2) are potentially very far away and (3) perhaps owned by someone else. There are some significant benefits to be had including reduced hardware expenses, fewer systems to operate and maintain, and better software reuse. All of these benefits come at the expense of significantly increased complexity. Let's see why.

The two figures to the right show schematically what can happen to add this complexity. The first figure shows five applications with their modules all operating independently. Changes to the yellow application have little impact on the operation and behavior of the other applications.

Interdependencies between applications after SOA is put in place

The second figure shows a similar set of applications that are interdependent because of module sharing. This is more of a problem than simply sharing beans in an EJB application where the application will be built, tested, and maintained separately. Here, because we're sharing services, rather than just code, the operation of many modules affect the overall operation of many applications. For example, the failure of the purple module in this scenario can cause all five applications to fail.

There are basically three problems:

1. No one team understands or controls all the moving parts. Problems have much wider impact. As the second schematic shows, there is a big ripple effect for service failures, increased latency, security lapses, and so on.
2. Change management is more complex. Parts need to be added, upgraded, fixed, and replaced on the fly with no external impact. In an SOA, expected level of service can change after its put into production. For example, we may put a module into service and then increase its expected service level when it is incorporated into a new, mission critical application.
3. Separation of concerns is more difficult. Stake-holders (operations, engineering, security, lines of business) need to be able to do their jobs without having constant interaction. Traditionally, deployment is the time when all stake-holders come together. Moving to an SOA can't cause the entire business to be reorganized. For example, when a privacy policy is changed, does everyone need to get together or can just the privacy officer and operations make the change without involving development and the lines of business?

Web service intermediaries are attempting to solve some of these problems, but there is still little corporate experience with these issues on a large-scale basis and little "best practice" information is available to help companies plan for a move to an SOA.