SOA and COTS Orthogonality – original posting 2007-03-30

I’ve been diving much more deeply into SOA and moving an enterprise towards SOA. In that process I’ve been considering an idea that seems to have a certain truism to it.

An Enterprise strategy that relies on moving heavily to using COTS (Commercial, off-the-shelf) products is not the same enterprise strategy that would fully embrace an SOA (Service Oriented Architecture) strategy. As a great number of companies claim to embrace both in their IT organizations, let me more fully explain what I mean.

The essence is in what ability your seek to enable to the greater degree in your organization. SOA and COTS have biases and while not perhaps completely orthogonal, you certainly can’t take full advantage of both simultaneously without having a rather large conceptual dividing line in the team doing the work.

COTS strategy embraces a stack in most cases, or out-of-the-box-instant-integration. Systems are configured by default to work with each other in certain dimensions, and those dimensions are most often walled garden integration paths either not open to outside systems or not surfaced in a way that effectively enables interoperation with other stacks. The benefit and bias is one of getting up to a certain level in a very short period of time. Most people would think Microsoft with this strategy, and they are perhaps the best at enabling the integration in the stack, but Oracle, BEA, IBM, Sun and many, many other vendors to this in varying degrees, markets and technical layers.

The price most often is in the ability to swap out a piece of the stack if it doesn’t suit your business needs or if it needs to be customized beyond the ability of that integrated stack. At that point the benefit most often has to be unwound to a large degree and portions reconstructed to gain the original integrated functionality back as well as the desired extension. Tightly integrated systems in their very nature are less flexible outside of their designed purposes and capabilities. That is the trade-off in all software. Tight integration with speed and efficiency in exchange for a loss of flexibility and openness. If somebody says you can have both, check your wallet. They should be telling everyone how to change the art of the design trade-off in software engineering worldwide rather than selling you a product stack.

The other side or axis if you stick with my observation, is SOA. SOA is designed around a loose-coupling, highly flexible approach. Swapping a component out is much easier in this case, as the integration is abstracted and highly flexible in nature. The system can be tailored to bring many technology pieces together, and arrange and integrate them in many ways. The approach also seeks for the services to be somewhat granular. Discrete, and at any rate smaller than a COTS stack or large and highly capable product set. Vendors sell more of the enablers of this, and components in those COTS stacks also expose themselves and pieces as services.

The trade-off with SOA is that you don’t get a whizzy-integrated system out of the box, and it’s going to take some work and discipline to get the systems work decently well. The advantage you are taking the hit for is flexibility and agility and the ability to bring entirely new components, services and capabilities into the mix with very little pain and rework comparatively. You also, as a side-effect, are not nearly as beholden to a single vendor as you are if you wire everything into a single COTS stack, as the COTS integration points are not, as a rule, generic.

That doesn’t say why the two are orthogonal though. As I note, the COTS products can expose capabilities and features as services to be used in the stack. But by orthogonal, I was talking organizational strategy. One of the two needs to take precedence to really be able to get the proper leverage out of either solution.

The COTS solution requires the team to become expert at building and customizing that vendors products, and building on that stack. This isn’t a C# vs. Java argument, this is getting a team of developers expert with Exchange Server, Sharepoint, Commerce Server, BizTalk and other vendor systems. Expert in building solutions on top of those systems, and taking advantage of all the capabilities they create in each other. Each of these systems has a set of capabilities, and you learn to use and extend them and the stack.

The other side is a team that is expert at learning the boundaries of systems, often but not always smaller systems or sets of services, and integrating, sequencing and orchestrating them together. If the invoice system isn’t doing what the business needs, the approach looks at how to augment it with another system or replace it entirely without deconstructing the enterprise.

Where COTS would extend and customize the existing system to fix the issue, and thereby become expert in extending and partially writing/customizing the inventory system and generation process (something I would note you expressly bought the COTS piece so you would not have to do it), the SOA approach looks at getting the tool that does solve the needs for the invoicing working within the enterprise, but that process is around getting information in and out, and controlling the system. It does not get into the system itself.

The experienced ones will know full well the environment is not this cut and dry. I am not claiming that it is, but polarizing the backdrop to better see the trade-off. The trade-off is what kind of team and enterprise you want as the main driver and focus. Most decent sized enterprises will have both sets of people, as there is always a bit of COTS customization to do (it’s not that big a deficit to throw the product out) and there’s always a bit of SOA or Application Integration (The SAAS provider for CRM doesn’t talk our COTS stack) but the bias is a conscious decision that affects the team. Do you want the IT group to bring in solutions fast and cheap (COTS) by default and specialize in a specific set of vendor tools as their primary skill set, or do you want the IT group to work to put together new and legacy systems that fit your business and spend the time putting those pieces together in flexible ways, taking a bit more time and money to do so? There is a long list of advantages and disadvantages to both. I contest that you need to pick one of the two as your primary thrust (or neither if that’s your preference), but you can’t honestly pick both.

Currently playing in iTunes: On My Way by El Chupacabra

Leave a Reply

Your email address will not be published. Required fields are marked *