SOA and COTS Orthogonality – a follow up and clarification – Original post 2007-07-08

Thanks to some very creative and insightful feedback on the original post from a few colleagues of mine, a bit of clarity and expansion on the dimensions is warranted.

For the sake of illustration in the article, I polarized the camps in the post as “SOA” and “COTS”. The intent of the SOA label was a best-of-breed, service-oriented connectivity model in an organization that is as likely as not to use a different vendor for every business core application. I believe that aspect was reasonably clear, but I blew it and mislabelled the “COTS” approach. Obviously, the label has a nod to IBM, Oracle and Microsoft in that they clearly offer integrated, custom, single-vendor stacks of software that work quite well emwithout/em needing to do very much integration. The list goes on with SAP, Sun and many more. The bias isn’t clear at this point, as an SOA organization can use these stacks quite well, and those stacks can be adopted completely and still integrate with yet other applications by SOA.

The labels really weren’t the point. They were intended to illustrate the bias in an organization towards a number of product specialists, being developers that will take a stack and be very capable at extending it and pushing it in all the required dimensions, vs. the generalists which in general don’t know the products to a great degree, but are very capable at putting very different and foreign systems together and making the integration the strength of their skill and of the enterprise, and can cobble custom code and applications together reasonably well.

Now, with a big nod to my colleagues, obviously, the vast majority of organizations have both types of developers (including ours) and most enterprises especially those of middle to large size will have experts of both types within their boundaries. It’s quite healthy indeed to have such a mix, and enables the best features of both approaches.

Flexibility and such multi-faceted capability matrices don’t come across very well at the higher levels of executive logic. Thus you wind up with a bit of a polarization. In one, the executive either has buzzworded themselves and you’re chasing SOA (likely with some preferred vendor), or you need to reduce and consolidate on a single vendor stack for efficiency and getting a unified set of developers and resources. (Work disclaimer, our executives are emnot/em as strongly afflicted by this condition as many, fortunately!)

That brings up the core discussion point. Is “best of breed” an approach to wander off and try to get the perfect vendor and thrash with continuous re-implementation of core business systems? Is “single stack” a simple procurement optimization that lets you have one company to pay the bills to and yell at when things go off the rails? Why does this either-or conceptualization exist?

Most often, when communicating the strategy of an IT organization, a “mission statement” of sorts is what is needed. That often grinds down into specific aspects of the implementation, and what shows up on the accounts payable. That simplification is problematic at best, for as noted earlier, the vast majority of teams is comprised of both aspects, and both types of developers. So then to the executive level, the teams are disorganized and inefficient, which is patently incorrect.

Really, good development teams need to get a job done, and they will use the tools they know, followed by the tools they are interested in, followed by the tools people they trust talk about, and finally, followed by the tools they are told to. Dire employment threats may elevate the use of the mandated tools higher in the stack, but that introduces a legislative inefficiency in the development process much as economists complain about legislative interference in the market creating inefficiencies. So the cases all boil back down to a question. What is the goal?

Getting the job done in the quickest way possible creates an inefficiency in that as changes are required, they usually require more effort than if some flexibility around that need was built into the solution in the first place. The trade was speed for flexibility. That’s most often the COTS approach. You get a “good enough” fit from pulling a pile of ready-to-rock code off the coat rack, and adding a nice shirt, tie, belt and decent shoes to go with it from your closet, and you’ll survive the presentation to the board just fine, it didn’t cost you a pile, and it can be replaced by next year’s style without too much pain. Unless the shirt and shoes start looking aged…/p

If you need the job to be done and each piece to be near the top of the game, say for competitive advantage, then you want a bit more out of the box. You want a top of the line suit, tailored to your specific needs, and not just anybody in a 42 Tall, you want it to fit your business down to the inseam. The tie is selected to go with the suit, and complement it precisely. The shirt and shoes and belt likewise. The goal is the ultimate ensemble to present to the world and take the headlines at E3. I’m stretching the metaphors again, but this gets to the central piece of the COTS vs. SOA, or specifically, COTS vs. Custom integration debate.

What’s the business advantage? If you aren’t making money off of your accounting department (and if you are, the SEC may wish a word), then your accounting system is a COTS piece with minimal integration into your other enterprise systems. If your accounting is part of an integrated ERP approach because your business is driven by operational efficiencies, and that defines at least a reasonable amount of your competitive advantage, then you want that system to fit precisely, and drive more benefits to the corporation directly. That’s the payback and that’s the decision fulcrum.

So I’m going to backtrack from my original assertion of bias on a team. It’s bias on a component, especially in the SOA world of today and tomorrow. In some cases you want your COTS/Stack integration team to ripple through and keep the overhead low on necessary but non-advantageous systems, and in others, your custom integration and customization teams will take the a product and adjust it to fit the company exactly, and bring competitive advantage and leverage to the table in a system that is critical to the nature and core business of the organization.

Just don’t do a custom job when the simple stack will suffice, and don’t settle for off-the-shelf when your core business depends on it.

Leave a Reply

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