The rest of this book will discuss several aspects of SOA in practice. That means we'll go a bit deeper than the usual "five slides" approach, which presents SOA in such a simple way that everybody wonders what's so complicated and/or important about it.
Still, to give you an initial idea about the essence of what you will learn, here are my five slides introducing SOA. Bear in mind that these five slides give an oversimplified impression. The devil is in the details. Nevertheless, this overview might look a bit different from the usual advertisement for SOA.
Service-oriented architecture (SOA) is a paradigm for the realization and maintenance of business processes that span large distributed systems. It is based on three major technical concepts: services, interoperability through an enterprise service bus, and loose coupling.
A service is a piece of self-contained business functionality. The functionality might be simple (storing or retrieving customer data), or complex (a business process for a customer's order). Because services concentrate on the business value of an interface, they bridge the business/IT gap.
An enterprise service bus (ESB) is the infrastructure that enables high interoperability between distributed systems for services. It makes it easier to distribute business processes over multiple systems using different platforms and technologies.
Loose coupling is the concept of reducing system dependencies. Because business processes are distributed over multiple backends, it is important to minimize the effects of modifications and failures. Otherwise, modifications become too risky, and system failures might break the overall system landscape. Note, however, that there is a price for loose coupling: complexity. Loosely coupled distributed systems are harder to develop, maintain, and debug.
Distributed processing is not a technical detail. Distributed processing changes everything in your company. Introducing new functionality is no longer a matter of assigning a specific department a specific task. It is now a combination of multiple tasks for different systems. These systems and the involved teams have to collaborate.
As a consequence, you need clearly defined roles, policies, and processes. The processes include, but are not limited to, defining a service lifecycle and implementing model-driven service development. In addition, you have to set up several processes for distributed software development.
Setting up the appropriate policies and processes usually takes more time than working out the initial technical details. Remember what Fred Brooks said in 1974 (see [Brooks95]):
A programming system product costs 9 times as much as a simple program.
A factor of three is added because it's a product (with the software being "run, tested, repaired, and extended by anybody"), and another factor of three is added because it's a system component (effort is introduced by integration and integration tests). The factor increases when many components come into play, which is the case with SOA.
Web Services are one possible way of realizing the technical aspects of SOA. (Note, however, that there is more to SOA than its technical aspects!)
But Web Services themselves introduce some problems. First, the standards are not yet mature enough to guarantee interoperability. Second, Web Services inherently are insufficient to achieve the right amount of loose coupling.
As a consequence, you should not expect that using Web Services will solve all your technical problems. You should budget enough resources (time and money) to solve the problems that will remain.
Also, you should not fall into the trap of getting too Web Services-specific. Web Services will not be the final standard for system integration. For this reason, let Web Services come into play only when specific infrastructure aspects matter.
Of course, this also applies to SOA. General business cases and concepts might not work as well as expected when factors such as performance and security come into play.
In addition, the fact that SOA is a strategy for existing systems under maintenance leads to issues of stability and backward compatibility.
And, in IT, each system is different. As a consequence, you will have to build your specific SOA—you can't buy it. To craft it, you'll need time and an incremental and iterative approach.
Note in addition that whether you introduce SOA is not what's important. The important thing is that the IT solution you introduce is appropriate for your context and requirements.
Probably the most important aspect of SOA is finding the right approach and amount of governance:
You need a central team that will determine general aspects of your specific SOA. However, the ultimate goal is decentralization (which is key for large systems), so you'll have to find the right balance between centralization and decentralization.
You need the right people. Large systems are different from small systems, and you need people who have experience with such systems. When concepts don't scale for practical reasons, inexperienced people will try to fight against those practical reasons instead of understanding that they are inherent properties of large systems. In addition, central service teams often tend to become ivory towers. They must be driven by the requirements of the business teams. In fact, they have to understand themselves as service providers for service infrastructures.
First things first. Don't start with the management of services. You need management when you have many services. Don't start with an approach that first designs all services or first provides the infrastructure. It all must grow together, and while it's growing, you'll have enough to do with solving the current problems to worry about those that will come later.
Last but not least, you need support from the CEO and CIO. SOA is a strategy that affects the company as a whole. Get them to support the concept, to make appropriate decisions, and to give enough time and money. Note that having a lot of funding in the short term is not the most important thing. You need money for the long run. Cutting SOA budgets when only half of the homework is complete is a recipe for disaster.