Avoid Vendor Driven Architecture (VDA)!
When looking at the technology buying patterns in the world of SOA, there is one common thread. The Global 2000 and many government agencies purchase SOA technology from their existing vendors, no matter what their needs or requirements might be. I call these purchasing solutions “comfort technologies” since they consider the relationship with the vendor before the value of the technology itself. It’s comforting to deal with the same company, people, and platform.
Moreover, many of the companies that work with “comfort technologies” allow 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 situation seems to be an emerging buying pattern. Architects make 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 designed 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. After all, SOA is architecture, not technology.
In the long run this means failed SOA initiatives where the blame is put on the concept, or perhaps on the product, but never the architecture or the architect, where and when the work needed to get done. 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 considered with some common sense advice that may not be what you want to hear. Indeed, this approach is more complex, but ultimately it 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 toward their “comfort vendors” and “comfort technologies”? It’s a matter of the path of least resistance and a lack of education.
It’s a 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. 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 design that is really required to build an effective SOA.
To the education issues, many who purchase the 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 to understand the basics of the process of building a SOA. This includes the process of figuring out your own requirements, which encompasses 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. 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. However, it’s a huge issue out there as the 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 an 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, it may not be in yours. Indeed, by not considering other approaches or other technologies, your SOA solution could easily be sub-optimal, thus limit or eliminate the return on the investment, and may need replacing sooner than you would like.
Second, technology vendors who actually define, design, and build your SOA. The issue here is the fact that you will typically end up with that vendor’s SOA stack. Thus, you miss opportunities for efficiencies that may come from other technology because it’s not in the best interest of the vendor who’s building your SOA to consider them. Again, not that the vendors are doing something wrong; they are just acting in their own interest which is always to sell their technology. Also, it matters not if this is a separate service arm of the vendors; the loyalties are there nonetheless.
Third, SOA vendors that sell “one stop shopping” for SOA. The “super SOA stack” approach is getting played a lot, driven by a large number of marketing dollars from those vendors. However, it’s rarely the optimal solution for your requirements. Indeed, architects are not doing their job by simply pointing at a vendor and saying yes. They must have a complete understanding of their own needs, tactical and strategic, before defining the proper solution. Then and only then, can they select the technology that is optimal for the requirements. Seems logical, but the most common pattern is to either purchase the technology today and then figure out what it is and how it fits later. SOA is something you do, not something you buy, thus the real value is within the process of getting to your solution. All SOA initiatives are different. Different business requirements, different ways of driving business processes, managing services, and thus very different technology solutions. Sorry, no “one stop shopping.”
The Right Path
So, if your vendor does not define your SOA, and you need to look at many technologies beyond your comfort vendors, what’s an architect to do? It’s really a matter of finding the right set of steps that are right for you, engage objective outside experts when needed, and, most of all, take complete responsibility for the architecture.
This means understanding your own business drivers, or the business reasons for building the SOA. Define just what success will be, the proper amount of investment, strategic considerations around the growth of the business, and committed resources for the execution toward SOA.
Next comes the hard work of figuring out your own issues and requirements, including a complete and detailed understanding of the data present in the problem domain or enterprise, as well as an inventory of candidate services, and a fully decomposed understanding of the major business processes.
From there you move on to service design and development, creating a SOA governance model for your architecture, as well as a complete systemic security plan. Once all of that is complete, you are finally ready to begin defining your requirements for the technology, perhaps using data points from some proof of concept work done earlier.
There is much more detail to the process of defining, designing, and building SOA than we can put forth in this ZapFlash. However, it’s clear that this process is not trivial, and certainly not something that should be handed over to technology vendors who will almost certainly take a technology-oriented approach. Instead, it’s about the business issues of the technology. Missing that point could cost you millions over the year in lost productivity and lack of agility, considering the increased risk that your architecture is likely to be sub-optimal.
The ZapThink Take
The core problem with VDA 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 just as likely that the technology solution is not optimal for your problem domain or enterprise. Moreover, you’ll probably pay too much for the VDA SOA solution versus a best-of-breed approach.
Don’t fall into this trap. While vendors are good people who want to make you successful, they are not responsible — nor should they be — for your core SOA. They are brought into the mix only after you understand your own issues, and only after you have considered all possible technology solutions. While they may know a lot about SOA, it’s in the context of their own stuff, so don’t be fooled that you’re getting objective advice. This caveat 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.
You may find that the “comfort technology” is the proper technology. The odds are just as likely that you will not. Our fear is that many companies and government agencies are not going through the proper steps to insure that their solution will provide maximum value. In the end, it’s all about the bottom line.