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 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 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. Indeed by not considering other approaches or other technologies your SOA solution could easily be sub-optimal, thus not 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’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. Again, not that the vendors are doing something wrong; they are just acting in their own interest which is always to sell 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.
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. Seems logical, but the most common pattern is to either purchase the technology today, and 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. SOAs are all different. Different business requirements, different ways of driving business processes, managing services, and thus very different technology solutions. Sorry, no “one stop shopping.”
So, if you vendor should 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. Including, defining just what success will be, the proper amount of investment, strategic considerations around the growth of the business, and committed resources for the execution towards a SOA.
Next, comes the hard work of figuring out your own issues and requirements, including having a complete and detailed understanding of the data present in the problem domain or enterprise, as well as an inventor of candidate services, and a fully decomposed understanding of the major business processes.
From there you move on to service design and development, while creating a SOA governance model your architecture, as well as a complete systemic security plan. Once all that is complete, then an only then you begin to define your requirements for the technology, perhaps using data points from some proof of concept work done earlier.
There is, however, much more detail to the processing of defining, design, and building SOA than we can put forth here in this flash, but it’s clear that it’s not a trival process, and certainly not something that should be handed over to a technology vendors, who will most certainly take a technology oriented approach. Instead, it’s about the business issues to the technology, and missing that point could cost you millions over the year in lost productivity and lack of agility, considering the risk that your architecture is likely to be sub-optimal.
Avoid VDA
The core problem with all of 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.
