When looking at technology buying patterns in the world of SOA, there's one common thread. The Global 2000, and many government agencies, are purchasing from their existing vendors, no matter what the needs or requirements. I call these solutions purchasing "comfort technologies" since they consider the relationship with the vendor more than the value of the technology itself. It's comforting to deal with the same company, people, and platform.

Moreover, many of these same companies working with "comfort technologies" are also allowing the vendors to design and define their solution. I call these vendor-driven architectures or VDAs but they are always called a bad idea if you understand the core issues. What's most disturbing is that this seems to be an emerging buying pattern. Architects are making the "SOA deal" with a vendor in hopes some magical technology emerges from the box that will suddenly make their existing poorly defined and design architecture, agile, loosely coupled, and return quickly on the investment. Won't happen without work, and there is no magic technology that can enable SOA. It's an architecture not a technology after all.

What this means in the long run is failed SOAs where the blame is put on the concept, perhaps the product, but never the architecture or the architect, where and when the work needed to get done. While we've made similar mistakes over the years, and are paying the price right now, we risk history repeating itself, if we're not careful.

The influence of the larger SOA vendors is very much a force in the market today so learn to discriminate. It may not be what you want to hear, but ultimately it's the right thing to do. The first step is to learn to recognize VDA, and don't let it kill your SOA before it has a chance to do some good. There's too much at stake.

Moving Out of Your Comfort Zone
So, why are organizations looking to their "comfort vendors" and "comfort technologies"? It's a matter of the path of least resistance and lack of education.

Path of least resistance because the relationship is already established and you don't have to go through the hassle of getting to know new players or many new players. So it's easier to buy the latest SOA stack from good old Bob than it is to go through the detailed requirements, analysis, and design required to build an effective SOA.

And many people who purchase technology don't know the first thing about SOA, or even their own requirements and business drivers for that matter. An effective knowledge transfer project is needed to understand the basics of building a SOA, like figuring out your own requirements, including a semantic-level, service-level, and process-level understanding of the problem domain or enterprise. Then, and only then, should you begin pinging vendors, including your comfort vendors about what technology may work best for you, considering that in many cases it will be a collection of technology from many vendors. For sure, not comfortable, but necessary.

Of course beyond the issue of always leveraging the same "comfort vendors" is the issue of vendors actually creating the architecture for the enterprise. This is wrong on so many levels it's difficult to know where to start but it's part of the impact those millions of marketing dollars spent larger SOA vendors is having. There are three major areas of concern:

First, the vendors who drive "SOA certification" programs. While these programs are sold as an objective SOA education, it's a way to get into deals and lead students to the promised land of the vendor's SOA technology stack. Not that this is a trick, it's not. They are merely acting in their best interest, but in many cases it may not be yours

Second, technology vendors who actually define, design, and build your SOA. The issue here is the fact that you're typically going to end up with that vendor's SOA stack. So you're missing opportunities for efficiencies that may come from other technology that may not be considered because it's not in the best interest of the vendor who's building your SOA to consider them.

Third, SOA vendors that sell "one-stop shopping" for SOA. While the "super SOA stack" approach is getting a lot of play considering the amount of marketing dollars behind those vendors, it's typically never the optimal solution for your requirements. Indeed, architects aren't doing their job if they simply point at a vendor and say yes, it's best if they understand the requirements, tactical and strategic, before defining the proper solution, and then and only then, select the technology that's optimal. Sorry, no "one-stop shopping."