Introduction
Many organizations trying to reorganize their architecture rely strongly on IT departments and supporting architecture teams for driving and managing the architecture initiatives. For instance, in the world of SOA, very often the talk of the architecture leads to discussions on technical and organizational challenges rather than on business values. IT professionals tend to focus more on products rather than processes. They are often looking at the “complete” technology stack solutions, including hardware, software, and services to be provided by their existing vendors. Obviously, it’s easier to deal with the same known vendor with whom a relationship has already been established and to get the whole SOA stack from them, than to look around for different solutions and go through the detailed requirements, analysis, and design with someone else.
Furthermore, the organizations that work with their existing vendors, allow the vendors to design and define their solution, no matter what their needs or requirements might be. The architects make a deal with a vendor hoping that they will acquire some piece of technology which will make their (sometimes poorly-defined) architecture miraculously working. From here, it’s pretty close to falling into the trap of letting the vendors drive your architecture.
In the following paragraphs, we will describe pros and cons of the vendor-driven architecture.
2. Vendor-driven architecture – why not
2.1 The Good
Let’s say you know your vendor. You’re about to change your architecture, so you naturally look at the existing vendor. You have a good relationship with them and you feel comfortable to deal with the same people and platform. You don’t need to go through the trouble of getting to know any new players. Then, you allow them to drive your architecture, just because it’s easier this way. Next, you buy their product stack, possibly receiving multi-product bundle discounts and free support. If they come up with some innovative solution, you may even become a pioneer, an early adopter of the new technology, possibly gaining competitive advantage. Of course, you get locked in to the vendor’s solution, at least till standards are created for this new technology.
2.2 The Bad
Relying too much on vendors can be a disaster. The vendor’s goal is to sell you as much stuff as possible. Your goal, though, should be to implement the architecture successfully and provide your company with maximum benefits at minimal costs.
The vendors will be trying to sell you their technology solutions, no matter what your requirements are. While vendors may be knowledgeable in regards to an architecture in general, their knowledge is always limited by their own perspective. They will provide you with advice, but that will always be from their point of view. You should specify your own needs, and try to validate your work by some independent expert assistance. That’s why it is so important to first understand your own issues and specify clear and detailed requirements, and only then start looking for all possible technical solutions.
Another aspect of relying on vendors to drive the architecture is that most of enterprise architects work from their experience, which not always is as broad as it should be. The less matured the architect is, the more prone will she/he be to go with vendor’s advice. There is always a risk that she/he will not focus enough on the core business problems and fail to sufficiently align technology to the business. That alone can cause a huge loss of productivity and money in the long run.
Don’t get stuck with the vendor’s product stack. You may miss opportunities for efficiencies that may come from other technologies. Don’t expect the vendor building your architecture to advise you to go with some other technology – it’s simply not in their interest to do so. What they care about is to sell their own technology, and there is nothing wrong with that. It’s up to you to be smart, stick to your requirements, and do your research.
When implementing architecture such as SOA, don’t forget about its principles: delivering your applications with agility, flexibility, and reusability. However, when you allow vendors to drive your architecture, these principles may be lost. You may end up trapped in vendor’s lock-ins, getting susceptible to expensive services, bound to proprietary technologies and product limitations. Your SOA may just become the JBOWS (Just a Bunch of Web Services) architecture.
Vendor-driven architecture characterized with its vendor lock-in is particularly important to be aware of in the design of cloud services and integration. What the vendors of cloud services promise is avoiding the upfront costs of licensing and hardware, paying just for metered consumption. Problems occur when you don’t have a clear exit strategy, and the vendor increases its pricing, removes support for something previously supported or changes some other terms and conditions. Also, due to the lack of standard interfaces, open formats for data interchange and other cloud-related standards, the integration between services obtained from different cloud providers as well as between cloud resources and internal systems is very difficult. The individual cloud vendors offer non-compatible underlying technologies and proprietary standards, which gets the customers locked-in with the current vendor, due to high cost of porting the applications and data to a different provider, legal and technical constraints.
3. Conclusion
Vendors should not drive the architecture. A mature approach to driving architecture should steer away from the vendor-driven, difficult-to-change-around needs of the business architecture, and from the related vendor lock-in. What vendors can do, is providing you with some tools or solutions needed for implementing your architecture. Bear in mind, though, that selecting just one “right” technology solution and committing to just one vendor could be a huge mistake, possibly generating unnecessary short- and long-term costs. Your architecture, SOA or otherwise, is (as they say) something you do, not something you buy, so “one stop shopping” may not work here, since there are always different business requirements, different processes, different services requiring different technology solutions.
Architecture is about holistically describing the system of people, processes and technology according to your organization’s specific needs, and this is something what vendors – acting mainly in their own interest – may not be able to objectively provide.
