What is SOA?

There are many definitions of SOA. (See for example Wikipedia's definitions.) I consider SOA to be an enterprise architecture strategy where business logic is organized into services, and business processes are realized through the invocation of these services. I consider a service in the context of SOA to be a related set of automated business activities accessible through a well-defined interface. Services are often expected to be accessible remotely over the network, usually as web services using the HTTP for the transport protocol, SOAP for the message format, and compliant with one or more of the 'million' WS-* specifications. "SOA is more about good design and architecture than it is technology." (from Lawrence Wilkes). This is often confused, unfortunately, by all the vendor hype around particular products and specifications, especially web services.

A successful service oriented architecture needs to address three areas:

1. Services: the units of composition for a service oriented architecture.
2. Processes: the business processes using the services. Each business process is implemented by orchestrating together multiple services.
3. Governance: the policies governing the development and maintenance of services.

I am hesitant to call SOA an architecture pattern. A pattern is generally defined as a reoccurring solution to a reoccurring problem. SOA qualifies as a reoccurring solution, but it is not clear whether it addresses a single reoccurring problem. The more hype-driven literature assumes that SOA is a given without any justification. In other cases, SOA is presented as addressing one or more of a collection of enterprise issues without any discussion of the context around these issues and the consequences of using SOA. I think SOA could be expressed as an architectural pattern, and that doing so would be beneficial in reducing the hype and the sometimes contentious discussion surrounding SOA. I feel that looking at the motivation, applicability, and consequences of SOA would be particularly helpful, and in the remainder of this article I will touch on these points.

Does SOA represent something new? I have heard it said that SOA is merely a set of "best practices" for enterprise I.T. - a collection of what has worked before. Certainly some details of SOA like the enterprise service bus (ESB) seem like a rehash of the message bus in enterprise application integration (EAI). The inclusion of business processes in SOA, especially executable via the business process execution language (BPEL), comes straight from the notion of automated work-flow engines. From the middle-ware vendors' perspectives SOA means a new 'stack' of products to sell. I suspect this has been a major driving force behind the SOA hype. As existing middle-ware such as Java EE servers becomes commoditized and open-sourced, it is rational for vendors to create new, higher-profit markets where this has not yet happened. My perspective is that SOA is at least an incremental refinement of what has come before: it does pull formerly disparate concepts together into a unified whole. Its explicit inclusion of process and governance seems unique, although I remain uncertain how those aspects will work out in practice. Whether or not SOA is something new or just the product of vendor hype, the question "does SOA work?" remains. Below I look at some of the benefits and weaknesses of SOA.

Benefits of SOA

SOA promises many benefits, but how many of these can be achieved in practice? Below I list the reported benefits of using SOA and evaluate each one.

• Integration of legacy or stovepipe applications: Legacy or stovepipe applications, even those implemented in variant technologies, can be wrapped in a service and orchestrated with other, perhaps newer, services to achieve a business process. This mixing of old and new allows existing I.T. assets to be reused rather than needing to be rewritten, which is expected to result in cost savings. I feel this is a legitimate benefit, especially when such an application is not under the control of your organizational unit and cannot therefore be modified directly.
• Bridging the divide between I.T. and the business: SOA explicitly considers business processes and thus links business goals and business use cases with the I.T. architecture through services. While I think SOA goes much farther in this direction than other architectures, I suspect that many of the normal issues that arise between I.T. and the business will remain. The people involved will still come from primarily from one side or the other and bring their existing viewpoints and biases which will inherently lead to conflicts.
• Loose coupling: SOA encourages loose coupling through encapsulating functionality behind course-grained services with well defined interfaces. This allows the implementations of services to change without impacting users of the service, since other services and business processes will only invoke the service through its interface. This is similar conceptually to the use of dependency injection, where the code using an external resource knows nothing about the concrete implementation since it is injected by the container. While I think this is a significant benefit, bad design can still ruin it.
• Reuse: Reuse is one of the more highly touted benefits of SOA. The theory is that the services can be reused to implement new business processes. Since each service operation represents a business activity, its reuse represents a significant savings in development costs. This is the benefit I am most skeptical of. It seems far too similar to the promises made when object-oriented programming was first becoming mainstream. While OO has many benefits, the level of reuse that does occur is far below what was initially hyped. There are a few hopeful signs, however, that SOA may actually enable a reasonable level of reuse. One of the key requirements to enable reuse is the proper management support, which SOA explicitly addresses through governance. Services are course-grained, so even a large corporation will have a limited number of them (less than 500 is a ballpark I have heard). This makes it easier to review the catalog of services and determine possibilities for reuse. And since the service operations have business meaning, both I.T. management and the business can better understand and commit to their reuse, unlike in OO where individual classes or even libraries are at too technical a level to be truly comprehensible to such people. A significant obstacle to service reuse, however, is that it requires the organization's business processes to become more standardized in how various business activities are performed, since the same services to perform these activities will be invoked by these different processes. In a typical large organization with independently-minded business units, perhaps with varying requirements, this standardization will likely be difficult to achieve without senior management involvement.

Weaknesses of SOA

There are a number of drawbacks and challenges to successfully using SOA, of which I highlight what I feel are the most significant:

• Distributed Systems Problems: Making a system distributed is problematic. Martin Fowler's first law of distributed object design is "Don't do it" for this reason. The issues you need to deal with include the following:
  • Reliability: If any required service in your business process becomes unavailable then your entire business process cannot be executed. Even having systems with different scheduled maintenance windows can cause difficulties. One way to address this is to use asynchronous messaging as much as possible and make your messaging infrastructure high availability.
  • Performance: The performance of remote calls is much, much worse than local (in-process) calls. This is exasperated when using Web Services with the verbosity and extra parsing that XML and the various WS-* specs add. This is why service operations should be as course-grained as possible to minimize the number of remote invocations.
  • Transactions: For a typical application, database transactions are used to ensure data integrity. When multiple, remote services are being invoked this becomes much more difficult. One option is to use a distributed transaction, which requires that both the service messaging infrastructure (i.e. Web Services) supports distributed transactions, and that the underlying service implementations can enlist in these transactions. When wrapping services around legacy or off-the-shelf applications, this may not be possible. Even when distributed transactions can be made to work, they introduce yet another performance hit. Another option is to forgot about distributed transactions and deal with the consequences: this usually involves more careful design and the use of compensating transactions in the case of failures. It sounds dangerous to those such as myself used to working with transactions, but there are cases where transaction-limited systems have been made.
  • Security: The current security context - the identity of the user and the actions it is authorized to perform – often needs to be propagated to each service. Propagation is actually not that difficult, especially with the introduction of specifications like WS-Security which automatically include security context in the SOAP header. A harder problem is managing user identity and access privileges across separate, perhaps legacy, systems. Even if you introduce an enterprise-wide security service for all your applications to use, you still face the problem of dealing with off-the-shelf or legacy applications that do not use it.
• Changing Services: Once services are defined, created and in operational use, changing them becomes difficult. One problem is versioning: what happens when the interface to a service needs to change? Especially troubling are interface changes that are non-backwards compatible. Frameworks in languages such as Java with explicit interfaces have already had to deal with this problem. One solution is to change all the consumers of the service at the same time the service changes: this requires significant organizational coordination and is frequently unrealistic. Another solution is to create a version 2.0 of the service, and leave the old service running but deprecated to allow time for consumers to migrate to the new service. This requires that both versions of the service are operational, which increases maintenance costs and is not always possible. Service implementations can also be changed without touching the interface. While a purported benefit of SOA, there is the risk that an implementation change actually subtly changes the semantics of one or more operations and breaks one or more of the consumers of the service.
• Crossing Organizational Boundaries: For all the benefits of SOA to be realized, a number of organizational boundaries need to be bridged. This typically requires a change in organization culture, which is very difficult to achieve. Integrating services in separate, traditionally stovepipe, organizational units requires them to coordinate more closely, both during the initial development project and on an ongoing basis for maintenance. Effective management and reuse of services requires more effective communication between development teams and architecture within I.T, and potentially requires better alignment of separate organizational business processes with enterprise-wide processes. I've already mentioned bridging the divide between the business and I.T. as one of the reported benefits of SOA that is likely challenging to achieve in practice.

Other Viewpoints

As part of my research into SOA, I came across a number of sites with varying views and feedback:

• What is SOA? (wanderingbarque.com)
• What is SOA? - SOA and Web Services Explained (www.indiawebdevelopers.com)
• SOA Manifesto (dotnetaddict.dotnetdevelopersjournal.com)
• Can I Be of Service? (webservices.sys-con.com)
• Tactics, not strategy, drive SOA adoption (www.looselycoupled.com)
• Early adopters: SOA worth the effort (www.networkworld.com)

What is your take on SOA? Please leave a comment and share your experiences.

Why is deployability important?

Maintaining the proper operation of the production systems is a fundamental I.T. goal. The end users do not care how well the software works in the development or test environments. All the testing and other quality assurance activities in the world will not help if the software is not promoted properly into production and fails as a result. Ease of deployment is also important. If promoting changes is a cumbersome and labor-intensive task, people will be tempted to take shortcuts (i.e. skipping the test environment), and it will take longer to get changes into production.

How can you architect for deployability?

My first guideline is to minimize differences between environments. The more similar the environments, the simpler and more reliable it is to deploy the software. Each difference between environments is something that may trip you up when deploying if you have failed to properly address it. Environmental differences can also affect the accuracy of testing: what worked in one environment may not work in a different one. Unfortunately, it is not possible to eliminate all differences without eliminating all environments but one. Common unavoidable differences between environments include different servers, different hardware configurations, different databases, different URLs, and different security settings. When encountering an environmental difference, I ask the question "Is there a good reason for this difference to exist?". If not, then it should be eliminated.

One example from my own experience is a system deployed to Unix servers which had a standard directory structure except for the root directory that differed across environments. In my investigation I discovered that the reason for the difference was that the test server contained two separate test environments, each of which therefore required a different root directory. I considered this a valid reason given the existing hardware at the time. When the opportunity arose, I suggested that an additional test server be added and the second test environment moved to it to allow the paths to be standardized.

To handle unavoidable environmental differences, I recommend encapsulating them within the software to isolate these differences from the rest of the system. The specific mechanism will vary depending on the technology being used and the particular difference being addressed. I discuss some of these mechanisms in my article Designing for Deployability. The goal you should aim for is to be able to deploy the software using a simple, automated process. For deploying code, this typically means an automated script that takes the output of the build process and copies it to the appropriate location (usually on another server) for the environment you are deploying to.

In an earlier article on Deploying Application Changes, I distinguished between full deployments where the entire application or component is deployed as a unit, and partial deployments in which only the delta - the pieces that have changed - is promoted. As I discuss in that article, there are advantages and disadvantages to either approach. Within a single application, I prefer the full deployment approach. When multiple applications are involved, especially across multiple support or business units, I prefer to have the option of partial deployments. If separate applications are too-tightly coupled, then changes in one will require changes in the other, which then requires that both applications be deployed together. So high coupling between applications reduces the ease of deployability of each individual application. Clearly defined interfaces help minimize coupling, and if the changing application maintains backwards-compatibility of its interface, the other application will then not need to change, or can choose to change on its own time line.

Like most non-functional requirements, deployability is often neglected or overlooked during application development. Inexperienced or rushed developers can create systems that work great in development, but have many problems in the test or production environments due to issues with deployment. The absence of a defined and preferably automated deploy process or problems in testing due to environment differences are warning signs that more attention to deployability is needed.