Free Newsletters

   All InfoWorld Newsletters
Real World SOA | David Linthicum » Avoid VDA! (Vendor Driven Architecture)

September 15, 2007 | Comments: (0)

Avoid VDA! (Vendor Driven Architecture)

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.

The core problem is that the vendor is not a disinterested third party. They are there to sell technology, so no matter what your requirements are; their technology will meet the need. Chances are, your requirements are not given proper consideration and, chances are, the technology solution is not optimal for your problem domain or enterprise. Moreover, chances are you're paying a bit too much $ for the SOA solution versus a best-of-breed approach.

Don't fall into this trap. While vendors are good people, and want to make you successful, they are not responsible, nor should they be, with your core SOA. They are brought into the mix only after you understand your own issues, and only after all possible technology solutions have been considered. While they may know a lot of about SOA, it's in the context of their own stuff, so don't be fooled that you're getting objective advice. This includes certification courses offered by vendors. Drive your own needs, and leverage independent outside assistance to validate your work, or help you through the process.

Hopefully you'll find that the "comfort technology" is the proper technology. For now, I fear that many companies and government agencies are not going through the proper steps to insure that their solution will provide maximum value. I have a feeling that this blog post will be emailed throughout organizations that are making the same mistakes.

Tell me about your VDA story. dave@zapthink.com.

 

Posted by Dave Linthicum on September 15, 2007 05:08 AM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




I have to agree completely with this article. The reason? Every vendor is going to try to distinguish their product by adding some unique (proprietary feature) that doesn't play with any other vendor's solution. Strip out the added features when looking at the baseline product. How fast and good is it then? What would you have to do to change from one vendor to another?

Those of you with long memories know that all the major database vendors claimed they were ANSI compliant on SQL, but every single one of them put extensions on their SQL verbs and in some cases you could achieve speed advantages by using those extensions. People have a tendency to do it the fastest, easiest way which is the wrong way to
design SOA.

Posted by: Harry at September 18, 2007 09:05 AM

Dave-

While a single vendor affords comfort and convenience at the time of purchase, a one size fits all approach typically comes with functionality compromises.

Further, due to acquisitions and rebranding of earlier capabilities into the SOA domain, full-suite platform solutions are typically poorly integrated.

You are correct that the buyers need to take the lead. And for each area of need, go with best of breed.

- Bob

Posted by: Robert Eve at September 18, 2007 01:28 PM

Dave
I could not agree with you more on this topic. I lead the SOA practice for my organization and see this over and over. I have to give credit to the technology platform companies for putting the marketing spin on their product giving their clients the illusion that there is enough new features in their products to make them best of breed. When in essence much of that new functionality is wrapping old technology with new enablers.
Many companies forget the fact that SOA is an architectural approach that encourages utilizing best of breed approaches to enable business process. Companies should start by understanding their strategic business objectives, then map out the business processes that enable those objectives. From there they should figure out where those business processes are implemented and what technology is supporting them. once they have that mapping of business function to application/technology, they will be better equipped to choose the technology that best enables their business to both compete and succced

Sa'd

Posted by: Sa'd Kanan at September 25, 2007 12:29 PM

There seem to be a few things being stirred together here, the biggest of which has to do with gathering and analyzing requirements appropriately. That is something not tied directly to SOA.

Also, haven't we lived through the 'best of breed' versus software suite skirmishes about 10 years ago?

More thoughts on this topic.

Posted by: Rich at September 29, 2007 06:48 AM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links