The original inspiration for Service-Oriented Architecture (SOA) was vendor neutrality and interoperability among best-of-breed technology components, comprising a cohesive system that is flexible and adaptable enough to meet ever-changing enterprise demands. Yet, recent news from well-regarded SOA technology vendors might lead one to believe SOA is heading in the opposite direction, toward a multi-faceted yet proprietary solution from a single source provider. What should enterprises consider as they plan SOAs, or do if their SOA implementations are already underway? This article reviews the best-of-breed versus proprietary approaches, and draws conclusions based on the original intentions for SOA.

SOA is used to provide standardized interfaces between enterprise systems so that one application can easily utilize the services (data or process logic) of another. SOA promotes interoperability and reuse of information assets, enabling IT professionals to build and change applications faster in order to keep up with rapidly changing business demands. But how exactly do you achieve an SOA to reap all of its promised benefits? There are a myriad of solutions and approaches available to help companies with their SOA implementations.

Let's first look at the proprietary approach whereby you obtain all the SOA pieces from one vendor. These pieces include the data services layer, the transaction services layer, the business process management (BPM) layer, and a services registry. The relative importance of each piece may be debatable, but many people will agree that these are undoubtedly four of the main pieces. IBM might be the only vendor in the market that can legitimately claim to offer all these capabilities, with perhaps one or two other vendors having credible claims to such a wide offering. The advantage of a proprietary approach is guaranteed compatibility among all the components. The disadvantage is that each component may not be the best available in the industry, as each piece may have inferior functionality to other solutions provided by other vendors that specialize in a specific piece of SOA.

At the other end of the spectrum is the best-of-breed approach by which you can pick and choose the best products in the market place for the function required. These solutions can come from established vendors or from startups. If a suitable solution is not available, you can choose to develop the required software in house. Companies can choose from a wide range of available products for data services, transaction services, business process management, and registry. The advantage of this approach is that you can pick the best available technology designed to meet your specific needs. The downside is that you run the risk that the parts may not work together. But, as we'll see, if SOA lives up to its promises, this is actually not a concern.

The foundation of SOA is interoperability. This allows companies to leverage their existing assets, and permits them to plug in best-of-breed products as needed to support their businesses. They are no longer forced to sunset a perfectly useful system just because the technology is "outdated" nor to implement an entire suite of products for only one particular module. The value of this is fairly straightforward, but one of the benefits that stands out is that now business requirements drive IT and are no longer encumbered by it.

In a typical IT environment, you have a mixed set of tools and systems. You might develop web-based applications using IBM, BEA, or even open-source products like JBoss. You may also have tried-and-true systems like SAP and Oracle E-Business Suite running your back office. Merger and acquisition activities may bring numerous other disparate systems into your IT environment. The need for systems to talk to each other, or use data that resides within another system, plus combine information from these various systems to execute business processes that lead to effective business decision making, is at the heart of the need for an SOA. SOA promotes (if not assumes) mixed technology from multiple vendors and in-house developers interacting through agreed standards.

Could we realistically expect one vendor to provide all the needs for SOA? We described four major components for an SOA earlier. In addition, there are numerous supporting pieces that are pertinent to the architecture, a list that is likely to expand in the future. SOA is simply too big of an initiative to be fully addressed by a single vendor. Even if we look at examples of a single vendor addressing a large need for its customers, we see that it cannot provide everything. For example, SAP is often cited as the single-source vendor for back-office management. However, loyal SAP users will admit that the system handles financials and manufacturing operations very well, but is less complete when it comes to the areas of supply chain management or customer relationship management, so they will implement complementary best-of-breed IT products. The customer is best served if these products work well together. The same is true of SOA.

There are many advantages to the best-of-breed approach, other than the right tool for the right job. With best-of-breed, by definition, you get what you need. You do not have to wait for any particular incumbent vendor to provide the functionality that you need in the "next release." Best-of-breed is also a practical approach, in that you only purchase what you need and nothing more. Why spend beyond your budget on tools and functionality that you don't need because it is included in an "enterprise deal"? You may believe that you have a toolset that will allow you to meet your needs for the future, but, as you proceed in your SOA implementation, you discover unanticipated needs not covered in the "one-size-fits-all" tool set. If done correctly, the best-of-breed approach allows you to grow and evolve with your changing IT environment.

Let's take a closer look at an example of a best-of-breed component of SOA and how it can grow and evolve within an IT environment. One of the critical pieces of SOA is a data services layer. Data services access and combine information from existing systems and deliver the data as SOA services. These services are used in applications that require data from across the enterprise. Every SOA needs a data services layer to abstract the complexity and location of enterprise data, making the data more available and reusable. You can start by allowing the data services layer to abstract only a few of your existing systems, and, as you add more systems to your environment, the data services layer expands to tap into those systems as well.

SOA is not just about technology. SOA implementations also need to take into account the people and process realities involved in the IT environment. A couple of things to consider are the ease of use of the technology and whether the tools leverage knowledge already in house. A tool that has all the features in the world but is not easy to use would be impractical because it would never be used, so promised benefits would never see the light of day. Introducing a technology that requires developers and users to learn it from scratch also faces resistance, so, in choosing the best-of-breed component, you should consider if it's the best fit for your people and processes.

Companies will go about their SOA implementations in a way that best fits their current IT environment. There are advantages to a proprietary approach, but there are far more advantages to a best-of-breed approach. Best-of-breed not only provides the right tool for the specific job, it allows growth as the SOA expands and adapts to changing business needs. Therefore, the best-of-breed approach is the most practical approach to SOA, and provides the most flexibility.