As web services continue to evolve, they are found proliferating throughout more and more enterprise application architectures. The popular belief that they were a mechanism merely for business-to-business (B2B) communications has changed. In comes Service-Oriented Architecture (SOA), the current holy grail of enterprise architectures. In this article I will explain the superficial benefits, the underlying complexity and cost, and of course where we are heading.

In any large enterprise, there are a number of roles that people have to play in order to successfully deliver any business application. It is these key individuals that have to understand what their role is in successfully delivering a SOA. The following is a list of roles and their key tasks.

Business Analyst: The business analyst plays a critical role in the identification of reusable business processes. Those processes are often ideal candidates for a service-oriented approach. The business analyst also is typically responsible for identifying potential improvements in the existing business processes and eventually envisioning a solution that can leverage service orientation when it makes sense.

Enterprise Architect: The enterprise architect in a company is responsible for determining what the best approaches are for enabling service orientation in an enterprise. This includes best practices for interoperability, deployment, and versioning. The enterprise architect will also be the key person identifying opportunities within the enterprise for service orientation.

Developers: Developers are responsible for delivering services that can be easily understood and extended. Developers are responsible for API documentation, service development and testing, and often deployment.

Quality Assurance Professionals: A QA engineer in a company that is attempting to deliver service-oriented applications plays a pivotal role. This role will ensure that those reusable services that are being delivered go through a very rigorous testing cycle. If this role is not a focus, then companies risk losing confidence in the services that are meant to become core components of all future applications.

Application Support Professionals: Understanding the role of services in an enterprise is very important for people who will support applications once they are deployed to a production environment. These roles will also help to drive confidence in the enterprise SOA when a comfort level is reached for troubleshooting and correcting issues as they arise.

Project Managers / Business Sponsors: If you are a person in your company who is responsible for the bottom line, it is important that you understand the immediate costs of service orientation. It is also important to understand the potential long-term goals and benefits.

The above roles will be referenced in a couple of different sections in this article. These are not meant to be an all inclusive set of enterprise roles but, I hope they represent a large majority of the players in delivering services in enterprises today.

The focus of this article is to use a combination of online research and hands-on experience to explain the practicality of SOA as the foundation of application enterprise architectures. The rest of this article will cover three aspects of SOA:

The Good: In this section, I have used what I believe to be the most obvious immediate return on investment items for any enterprise. The upside on these items is substantial and in most cases immediate.

The Bad: All of the items in this section will create some minor headaches when attempting to deliver services that can be reused and remain long lived. The cost is most likely higher than a typical non-SOA approach, but with strong guidelines much of the cost will be a one-time-only issue.

The Ugly: These items are the ones that will likely make any project manager uneasy about the timelines and costs associated with an enterprise SOA. Many of these issues don’t have good answers for them yet and will likely continue to evolve as the technologies being used to deliver services evolve.

Service-oriented Architecture vs. Web Services

Too often discussions about service-oriented architectures inadvertently progress into a best practices discussion on web services development. This article will use many of the existing limitations of web service development to explain the costs associated with delivering service-oriented architectures. Web services are by no means the only technological mechanism for delivering an enterprise SOA. There are code libraries, shared components, and EAI solutions. With that said, web services are the most popular approach and are seen used much more often due to their implicitly interoperable transport mechanisms.

Other Reuse Strategies

It is worth taking a moment to walk the SOA timeline. At the root of SOA is code reuse and there have been a number of mechanisms used over the past 30 years for reusing code. It all began with cumbersome error-prone cut and paste techniques. This eventually progressed into code libraries and code includes. These techniques were foundational for many different development platforms until the introduction of object orientation.

Object orientation soon progressed into an underlying design concept and the packaging and deployment mechanism that followed was dubbed component oriented. These components were used to package and deploy reusable code. However, that still required multiple versions of the code and the next step was to use proprietary channels for remotely invoking those components from a single location.

What seems to be the final obstacle in the evolution of code reuse emerges. We now have a standards-based approach for remote invocation of reusable code. This, above all other reasons, is why web services over HTTP are the most common technologies found enabling service orientation in today’s enterprises.

Service orientation via web services can often be the best approach for enabling core business processes. The most important aspect to finding the SO sweet spot is determining what can be reused. Services are often considered application building blocks. With that comes a great responsibility for the application visionaries. There is a natural time during an application’s envisioning when service boundary identification can be done by those that best understand what business processes can be reused.

If these services are envisioned and designed with the enterprise in mind, and not the specific application being envisioned, there is a good chance that a reusable service will be delivered. There are a lot of inherent risks here too. You have to involve the right resources for auditing those services which are thought to be reusable. Typically in a large enterprise there could be other projects that have either already started or already built a large portion of that same service.

Loosely-coupled, reusable services have a number of other obvious benefits. That is if the services are designed using the four service-oriented tenets listed here:

1.     Boundaries are explicit: This means that we make no assumptions about what is behind an SO boundary. We cross service boundaries intentionally to use a service that would most likely be usable by more than just our application. These boundary crossings are expensive and should be done only when necessary. It is tempting to do this as a standard architectural approach with the hopes that a library of services will become a reality by accident. Architecture never happens by accident, service boundaries being explicit is the most important tenet to understand and abide by.

2.      Services are autonomous: This is self explanatory really; autonomy, by definition, means self-governing or stand alone. This becomes important when you start to look at services that are defined based on the needs of a specific system or interface. When services can not be independently built, versioned, and deployed, they are destined to fail in the long run. Without careful adherence to this tenet, services will never reach their potential for reuse or longevity.

3.      Services share schemas and contracts, not classes and types: This speaks to the platform neutrality of services. All services are designed to exchange contracts for behavior and schemas for data structure. Avoiding type system dependency is what ensures interoperability.

4.      Compatibility is policy-based: Policies define the constraints for accessing the service. This allows services to define a mechanism for communicating no matter what their current capabilities are. This guarantees that services will always be capable of negotiating a set of rules for communication. As services begin to provide enhanced capabilities like transaction flow and reliable messaging, a policy can still be defined that will allow first generation ASMX services to talk text-based XML over HTTP.

When the design strategies for delivering services keep these tenets in mind, they can realize many benefits. Portability of the individual parts of an application is inherent because of the neutral nature of the transport channel. Each of these parts is also individually scalable. Services can also see a huge gain in maintainability and extensibility because of their centralized nature. Services are also potentially durable, reusable core components in enterprise architectures.

There are some other great reasons to look at implementing service-oriented architectures today. One reason is that it provides the ability to extend the investment of the legacy components in your architecture. I love the saying: “If it ain’t broke … front end it.” Implementing a service-oriented front end for a legacy system will expose that same business logic to an entirely new generation of applications. This does come with risks, but if those legacy systems you intend to expose via service orientation are carefully tested, there is a great opportunity for renewed ROI.

Another great implementation of service orientation is often referred to as shared state or workflow-type applications. The best example I can think of is a loan application. If that loan might have a number of different states that numerous applications would act upon during its lifespan, then you will most likely benefit greatly from a service-oriented approach.

The obvious scenarios still apply as well. When you have a need for interoperability, service orientation has obvious benefits. If you need to expose your application’s business logic to a brand new front end hosted on a disparate platform, SOA provides exceptional ROI.

As I mentioned previously, crossing service boundaries is, without a doubt, expensive. Moving toward service orientation has to be done knowing that there are costs, some obvious and some hidden. The first cost I will discuss is the first one on the tips of most developers’ tongues; of course, I’m talking about performance. Performance should not be used as a driving factor for deciding whether or not to move toward service orientation. We should always keep Moore’s Law in mind any time we look at performance as a requirement. I will loosely describe Moore’s Law by paraphrasing it. Essentially computing power and data density has been proven to almost double every 18 months and that trend is expected to continue for years to come. It is my belief that this same growth potential can be applied to network bandwidth. This means that our performance concerns today are not likely to be as significant a concern tomorrow. Always remember that one of the key reasons enterprises want to start implementing reusable services is application longevity.

With all that said, there are some strategies that should be used to carefully monitor potential performance problems. Wire-level tracing and message size is a key metric for understanding service-oriented performance issues. Asynchronous invocation is another important strategy when using service orientation, as it will allow applications to avoid locking situations under heavy load. Finally, always beware of over-extending legacy components. Although there are obvious benefits to renewing that investment, not all components are ready for the stresses introduced by high-volume, online synchronous traffic. I can’t stress enough how important extensive quality control practices are in a service-oriented enterprise.

When developing services in a service-oriented architecture, we are always forced to code to the lowest common denominator when it comes to things like security, type systems, and tools. Security introduces a number of challenges. Interoperable security is very complicated. Both method-level security and role-based security become very challenging to implement when considering interoperability concerns. Service orientation also immediately violates a key security tenet that says you should always look to minimize your attack surface. Extending services over universal channels exposes them to the same attacks as any other code that can be invoked over HTTP. This type of code has traditionally been attacked regularly because of its accessibility.

Interoperability is still very challenging especially if your goal is complete toolkit interoperability. What that means is that any Java Web Services toolkit can consume a contract from an ASP.NET web service, and vice-versa. This introduces numerous challenges. Developers have to avoid intrinsic types and empty arrays. There are a number of date and time issues when going across platforms, and there are very careful decisions that have to be made when deciding how a contract and schema are exposed to heterogeneous clients.

The tools available today for service-oriented development are still somewhat unsophisticated and, at times, even create problems when using their embedded features. A good example of this is how Visual Studio .NET allows developers to create proprietary web services and will at times generate code proxies that have deficiencies. The tools for service-oriented development continue to evolve, and Visual Studio 2005 is a great improvement over previous versions. Developers are free to modify and build things by hand if they are so inclined, but productivity suffers immensely.

Other issues that are costly but can be overcome are durability, data type centralization, and standards. Durability becomes an issue when design strategies are not followed that ensure autonomy in a delivered service. This can create a situation where services and all dependent applications become increasingly brittle. Data type centralization is challenging as well. Type ambiguity begins when centralized types are not reused across varying services. For example if your company uses something called an “Order” that type should be defined and used consistently across services that act upon an “Order”.

Lastly I will mention the issue of standards. I know it seems hypocritical to consider standards a negative even though they have gotten us to where we are, but I’ll explain why. Currently the standards that are available are quite extensive. This makes them difficult to digest and frequently misunderstood. Also, there are a lot of standards currently available. Reading them all is probably unrealistic, and these standards are still in their infancy. Most of them are less than five years old and will continue to evolve. Because of these issues, the standards driving SOA can be quite overwhelming.

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.

Service orientation tells an incredible story. However, there are a number of issues to consider when designing an enterprise service-oriented architecture today. I fully expect service orientation will continue to be a moving target as the standards, tools, and runtime environments evolve. Service orientation has become the focus of all the primary development platforms. Tools are also being enhanced to provide developers with what they need to overcome many of the obstacles I have described above. The Windows Communication Foundation (formerly, “Indigo”) has put in place many enhancements that will solve the versioning issues and the security issues. Microsoft has used the lessons learned from the industry following the delivery of WSE 2.0 and WSE 3.0 and unified all of the distributed technologies, allowing developers to build “enterprise strength” web services that will help enable the service-oriented enterprise.

Depending on your role in your enterprise, you are impacted by SOA in different ways. Just know that SOA will impact almost everyone responsible for delivering applications. The main advice I can give is to remain knowledgeable of the new standards and enhancements in the service-oriented world, because it is very easy to paint yourself into a corner today with first-generation web services. SOA has the potential to become the best approach for building reusable application building blocks that can stand the test of time. However, with the technologies available today for implementing an enterprise SOA, it is likely that the costs and risks greatly outweigh the potential gains in business logic reusability.

In a future article I will take an in-depth look at the enhancements available in Windows Communication Foundation and how delivering SOA building blocks is easier and more practical with the WinFx release scheduled for 2006.