Most of what I have determined as “ugly” in SOA is, unfortunately, very expensive to an enterprise. Much of the issue is related to the newness of service orientation, and, as is often the case, the most costly aspect of introducing new technologies and concepts is the investment in your company’s human capital. People are resilient and, in some cases, are very agile, but that agility comes with time and experience.
One of the most challenging roles in the service-oriented era is that of the quality assurance engineer. Most services are designed to satisfy the needs of various applications; that makes their requirements somewhat fragmented. QA experts need to understand the internals of all applications that are potentially impacted by a service. Services boundaries, when designed explicitly, can be tested in isolation, but changes and versioning will introduce the need for sophisticated regression testing cycles. QA experts need to understand how one application can change the behavior of another application that depends on that same service they are testing.
Another not-so-obvious added cost with service orientation is the complexity involved in the test environment setup. As applications begin to bind themselves to specific versions of reusable services, those services will need to be set up and made available for testing as an application goes through a normal release schedule. This creates a need for isolated installations and numerous versions of the same services. It also creates a need for quite a few more servers and hardware. The cost comes from the complexity in managing and supporting all of these varying installations of the same services.
I already started to hint at my next major SOA money pit. Versioning with first generation web services is extremely challenging. DLL hell seems to have resurfaced in the WSDL world. Depending on the design strategy, method signatures can create a scenario where changes are all but impossible without impacting the consuming applications. Some strategies have surfaced like message router solutions and message type strategies, but all of them have significant drawbacks.
Another major problem with versioning of services is any implicit semantic contract changes. Any behavioral changes to an exposed service can negatively impact consuming applications. It is not always fair to say that what a service does not know does not hurt it. Consumers could potentially depend on things like error conditions or failure scenarios in previous versions of the service. Syntactic and Semantic contract versioning is very complicated with web services in their current state.
As service-oriented applications begin to move to production environments, control of these reusable services is typically transferred to a production support group. This introduces a new challenge for resources that are responsible for high-availability, distributed systems. Somewhat like the QA engineers, production support engineers often have to become experts of all dependent applications for a service they might be responsible for. The key measurement of success for any production support professional is responsiveness. Without understanding all of the other dependencies, it can be a challenge to even find the root of a problem.
As with other distributed technologies, it becomes more challenging to trace application code at runtime and quickly do problem determination on systems that live on numerous servers and sometimes on disparate platforms. These issues are amplified when applications are not designed with durability and supportability in mind.
The final additional cost to an application delivery timeline is the negative impact service orientation will have on developer productivity. It’s really impossible to take away all of the implicit benefits of a development platform and not see an impact. Earlier we discussed coding to the lowest common denominator. This also becomes true of the standards and best practices for the developers in an enterprise SOA.
I am confident that, over time, developers will overcome the complexity of developing web services that are interoperable, and I’m sure that we’ll see the tools continue to catch up. If you plan to build web services today, these costs are unavoidable but temporary. The productivity costs that will never subside are the needs for detailed documentation. Any reusable component comes with an increased need for clear API definitions.
