Ten Emerging Best Practices For Building SOAs

Many enterprises have achieved success implementing Web Services to solve point-to-point integration problems, and are now looking to leverage the power and flexibility of Web Services strategically across the enterprise-which means building loosely coupled, standards-based Service-oriented architectures (SOAs). Such enterprises typically assign the task of exploring SOAs to their architecture teams or committees, who must then recommend an approach for transitioning their IT infrastructures to SOAs.

In many ways, however, these architecture committees are breaking new ground. There are few examples of full-fledged SOAs to learn from. To fill this void, ZapThink’s research has uncovered ten emerging best practices for building SOAs. We call these emerging best practices for a reason: the term best practice generally refers to lessons learned from hard experience, and only after making many mistakes does an organization discover its true best practices. However, SOAs are an emerging computing approach in an emerging market, and as such, the best practices discussed in this report rely upon a broad range of experience beyond companies that have implemented SOAs.

#1: Develop a top-down, extended enterprise SOA

Today’s applications of Web Services tend to focus on the details, while the best approach to formulating a SOA strategy is to consider all aspects of the IT infrastructure, both inside the enterprise and among the company’s partners. It is important to point out that starting with the big picture does not mean reworking the entire IT infrastructure at once. Instead, this best practice specifies the vision for the enterprise SOA-a guideline for the enterprise to fill in as it progresses.

#2: Build & maintain a platform independent Service model

In the traditional “design-build-run” waterfall software lifecycle, architects create models during the design time phase for developers to follow during the runtime phase, and the models are then put on a shelf. In an SOA, however, the model continues to serve a critical role on an ongoing basis. The core model in an SOA models the coarse-grained business Services that encapsulate and expose IT functionality to the business realm. This model, which ZapThink calls the Service model, acts as the clearinghouse for information about what’s going on in the IT environment at any point in time. It tracks current and future business requirements, and follows the current and future versions of the Services available on the network.

#3: Maintain feedback at all points of the architecture

This feedback between the business realm and the technology realm must be both active and automatic. Active in the sense that the software implementations of the Service model must direct the production of the Services and their underlying code. Likewise, this interaction must take place automatically, rather than requiring human input for the interaction to take place.

#4: Follow Agile Methodology principles & techniques within the context of the Service model

There are several best practices from the world of Agile Methodologies like Extreme Programming that are applicable to SOAs. The Agile Methodology best practices that enterprises implementing SOAs should follow include focusing on simplicity, operating in small teams focused on speed and efficiency, using tests as a means to guarantee functionality, refactoring by reworking existing code to make it more efficient without changing its functionality, and maintaining a focus on the users and their requirements in the context of the Service model.

#5: Encapsulate existing/legacy functionality

The Service-oriented approach to accessing legacy data and functionality is different from the traditional, adapter-based approach. Once a company has a requirement to access a legacy system, developers should encapsulate that system with a Web Services interface that exposes the functionality of the legacy system as atomic Web Services. Once the encapsulation is complete, those Services are now available on the network to meet current as well as future requirements of the business. Companies that take this approach to legacy enablement will find new uses for old data and functionality, because the cost of accessing that information will be dramatically reduced.

#6: Embrace heterogeneity/follow a federation model of software

The enterprise application story of the 1990s was all about suites. Buying a few large packages with several tightly integrated modules made more sense than going with a best-of-breed, “mix and match” approach, so the argument went, because integrating products from multiple vendors was such a nightmare. Web Services and SOAs reverse this argument, because Web Services can reduce the cost of integration to the point that best-of-breed approaches make solid economic sense. Not only does Service orientation allow enterprises to squeeze more value out of a variety of existing systems, but it also allows those companies to continue to purchase heterogeneous solutions, as long as they offer standards-based interoperability.

#7: Compose atomic Services into coarse-grained business Services

The real work of building and running SOAs involves taking fine-grained, atomic Services and composing them into the coarse-grained, business Services found in the Service model.

#8: Build for consumability/broad applicability

One of the holy grails of software development is code reuse. In an SOA, developers should construct the Services to be as simple as possible, where they continually refactor them so that they are as broadly applicable as is practical. The resulting services are then reusable at runtime-nuggets of software functionality (both fine- and coarse-grained) that can be used in a variety of situations, as contrasted to typical code reuse, which is a design time principle.

There is an additional, related concept to broad applicability that goes even further: the concept of consumability. It’s not enough for a Service to have the potential to be used in a variety of situations, it must actually be usable. Not only must the Service’s functionality be technically applicable to various situations, but people must know about the Service, understand its use, and be able to find it when they need it.

#9: Perform ad hoc upgrades

Once the SOA is in place, new business requirements will continue to cross the Service model to the IT staff, requiring new and updated Services. The IT staff can then make the required changes on an ongoing basis. In addition, taking an ad hoc upgrade approach reduces the need to “rip and replace” large portions of the IT infrastructure. Companies should only consider a rip and replace strategy as a last resort, and then only within a Service orientation context.

#10: Prioritize SOA transition activities on the fly

The previous nine best practices only touch upon the process of transitioning to an SOA, for a reason. There is no one right strategy for adopting SOA-no specific timeline or checklist that would qualify as a best practice. Instead, companies should take another page out of the Agile Methodology playbook and apply it to SOA transition activities, by repeatedly identifying the toughest IT problem in the enterprise that is suitable for a Service-oriented solution, and solving that problem in a Service-oriented way.

Fundamentally, this best practice doesn’t simply omit a preferred timeline for adopting an SOA — it explicitly recommends against using one at all. Instead, companies must first take an agile approach to thinking about the problem of SOA-that is, to accept the fact that the business environment is in a state of constant flux, and plan accordingly.


Service orientation represents the next major trend in enterprise computing, and as such, requires a new perspective, new techniques, and new tools for implementing technology solutions that meet the needs of business. At this point in time, the IT industry stands at
a cusp-a tipping point where sporadic applications of Web Services become a movement toward agile, thrifty computing. When people stand at such a threshold, they often have a difficult time planning for the future, because many of the business patterns that have applied in the past may no longer apply.