Avoid VDA! (Vendor Driven Architecture)

David S. Linthicum

When looking at the technology buying patterns in the world of SOA, there is 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 their considering the relationship with the vendor more so 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 that some magical technology will emerge 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 the 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 have some risk here that history could be repeating itself, if we're not careful.

The influence of the larger SOA vendors is very much a force in the market today, and should be considering with some common sense advise that may not be what you want to hear, indeed is more complex, but ultimately is the right thing to do. The first step is learning to recognized VDA, and don't let it kill your SOA before it has a chance to do some good. There is too much at risk.

Moving Out of Your Comfort Zone

So, why are organizations looking towards their "comfort vendors" and "comfort technologies?" It's a matter of path of least resistance and lack of education.

Path of lease 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. Thus, it's easier to purchase the latest SOA stack from good old Bob than it is to go through the detailed requirements, analysis, and designed that really required to build an effective SOA.

To the education issues many who are purchasing technology don't understand the first thing about SOA, nor their own requirements and business drivers for that matter. Needed, is an effective knowledge transfer project do understand the basics of the process of building a SOA, including the process of 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 technology that 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 issues of always leveraging the same "comfort vendors" is the issue of vendors actually creating the architecture for the enterprise. This is wrong at so many levels it's difficult to know where to start, but it's also a huge issue out there as millions of marketing dollars spent by the larger SOA vendors are having their effect. There are three major areas of concern:

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

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

Third, SOA vendors that sell "one stop shopping" for SOA. While the "super SOA stack" approach is getting played a lot considering the number of marketing dollars beyond those vendors, it's typically never the optimal solution for your requirements. Indeed, architects are not doing their job by simply pointing at a vendor and saying yes, they most have a complete understanding of their own needs, tactical and strategic, before defining the proper solution, and then and only then, selecting the technology that is optimal for the requirements. Sorry, no "one stop shopping."