Bick Group

David Linthicum

Subscribe to David Linthicum: eMailAlertsEmail Alerts
Get David Linthicum via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Avoid VDA! (Vendor-Driven Architecture)

It's time to throw your comfort blanket away

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."

More Stories By David Linthicum

Dave Linthicum is Sr. VP at Cloud Technology Partners, and an internationally known cloud computing and SOA expert. He is a sought-after consultant, speaker, and blogger. In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing including EAI, B2B Application Integration, and SOA, approaches and technologies in wide use today. In addition, he is the Editor-in-Chief of SYS-CON's Virtualization Journal.

For the last 10 years, he has focused on the technology and strategies around cloud computing, including working with several cloud computing startups. His industry experience includes tenure as CTO and CEO of several successful software and cloud computing companies, and upper-level management positions in Fortune 500 companies. In addition, he was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities, including University of Virginia and Arizona State University. He keynotes at many leading technology conferences, and has several well-read columns and blogs. Linthicum has authored 10 books, including the ground-breaking "Enterprise Application Integration" and "B2B Application Integration." You can reach him at david@bluemountainlabs.com. Or follow him on Twitter. Or view his profile on LinkedIn.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.