What's better for implementing SOA: All-in-One Stack or Best-of-Breed?

Classic architecture considerations never seem to pass up a generation.  The classic debate of whether it is better to buy and implement an "all-in-one" SOA stack from one vendor or to embark on a "best-of-breed" strategy where specific vendors and technology are selected for specific capabilities is a regular discussion I find myself particpating in often. 

First, SOA is a design pattern.  It is an approach to creating IT solutions.  SOA is something you do, not something you buy.  So, there is always some manner of integration, development and "best-of-breed" engineering in any SOA implementation (usually at a minimum in semantic data definitions).

Given this, the key question then becomes how many SOA capabilities are sourced from how many vendors...

Experience to date has shown that integrated SOA stacks are most valuable in business domains where the entire domain's major business solutions are implemented from a common vendor (like SAP or Oracle for example).  The benefit of integration across the SOA functional layers as well as application logic and data provide a material benefit in the speed in deployment.  However, most organizations don't run their entire business on a single vendor.  Different corporate functional groups (like HR, Supply Chain, and Sales) or different business divisions or geographies have different needs for function, cost, etc. so it is very common to find different vendors serving those different needs.  This very common situation results in the development of a Federated SOA deployment.

This common fact means that neither "all-in-one" nor "best-of-breed" is a single solution for most organizations deploying SOA.  Rather some aspects of the business will benefit from "all-in-one" when there is a good match between business process functional and data needs to a stack vendor's business and SOA suite, and that a "best-of-breed" model will almost always be required to connect business domains into an enterprise whole.

Therefore in the development of our SOA platform, Intel SOA Expressway we chose a different model.  Rather than being a "all-in-one" or "best-of-breed" we chose a different path we call "right-sized".  In the "right-sized" model the necessary functions to achieve a specific set of SOA-enabling objectives are bundled into one complete package.  No seperate piece parts, or up-sell modular add-ons.

With Intel SOA Expressway our objective was to optimize the scalability, security and managability of a SOA deployment.  To achieve that objective we bundled network protocol handling, data translation, service virtualization, process orchestration, security mediation, and appliance level manageability features into one highly optimized platform.  To leverage those features in a Federated SOA architecture, we enable standards-based interfaces and tooling to governance repositories, message-oriented middleware, databases, portals, shared security infrastructure like LDAP directories, and vertical market specific service implementations.  The net effect is that through these standards-based interfaces and a validated partner ecosystem a "right-sized" architecture provides the purpose-built fit for a Federated SOA architecture and many of the time-to-value benefits of the "all-in-one" stack.

During the next few posts, I will share more details on how the "right-sized" SOA platform architecture works and how the Intel SOA Expressway validated partner ecosystem is evolving.

I look forward to hearing your thoughts on the "all-in-one" stack vs. "best-of-breed" debate and how you have applied that thinking to your SOA deployments.

Thanks for getting this far...


For more complete information about compiler optimizations, see our Optimization Notice.