Vendor King is an architectural anti-pattern commonly found in many enterprises. It refers to an architecture built entirely around a vendor product that pathologically couples all the system in the entire organisation. The architecture becomes dependent on the product resulting in the following consequences:
- Business processes and decisions have to be designed around the tools
- IT maintenance and upgrade driven by vendor product upgrades
- In-depth product knowledge is required to change any systems within the architecture
- Software applications are more costly and take longer to build as they have to be designed and built around the vendor product using their technology and integration methods
Why an enterprise ends up with a Vendor King?
Many companies today do not have the technology capabilities or resources to build their own tools. Instead, they opt for commercial off the shelf (COTS) products and rely on the vendor to custom build the solution.
While this is a perfectly legitimate approach, an enterprise can end up in the Vendor King trap if it is not aware that many vendor solutions attempts to cover many, if not the entire, scope of business operations far beyond the current business needs. This has the consequence of blurring the integration boundaries and pave the way to the Vendor King architecture.
The above typically occurs when an enterprise does not have the technical expertise or progress to undergo a thorough technical assessment of the vendor solutions. Another common cause is the product or vendor selection process being dominated by sales and marketing information.
As any introduction of a new product will have direct impact on the enterprise architecture, it is important that the decision making process includes inputs from stakeholders from both the business and the technology teams.
Bounded Buy as a strategy against Vendor King
Bounded Buy is a term coined by ThoughtWorks in their recent technology radar. It suggests as part of the vendor selection process, an enterprise should
select vendor products that are modular and decoupled and can be contained within the Bounded Context of a single business capability.
I would recommend the following principles as part of a Bounded Buy strategy:
- Be specific with scope – Once the business capabilities to be acquired are decided, they need to be put into context of the overall enterprise architecture. The vendor solution should then be effectively “boxed in” by the architecture, not the other way round.
- Prefer current standard integration methods – A vendor solution should be able to connect to other existing and future systems in the enterprise. Open standard like RESTful APIs, for example, will allow system integration to be implemented without extensive knowledge of the product itself. More importantly, it facilitates modularity and hence replace-ability of the vendor product within the enterprise.
- Demand data accessibility – Any data collected by the product should be accessible. In general, this prevents creating data silos in the enterprise. In the context of bounded buy, it is imperative to prevent the need to build applications around the vendor product because of difficulty in accessing the underlying data – a first step into the Vendor King trap.
