In the context of the CIO or CTO role, today I would like to focus on a concrete aspect that is part of this job: understand vendor lock in.
In software solutions one of the long term decisions to be done is to pick the right software or platform.
In the context of IT the classic question is “buy or build?”, but in the era of SaaS is more common to face the situation of asking:
“what are the risks of vendor lock-in if we procure these services?”
This is specially important for the long term, not only in terms of value or cost, but also in terms of:
- Ability to satisfy current and future business needs,
- Agility to adapt the solutions,
- Ability to integrate and host new disruptive technologies,
- Sustainability of the ecosystem.
Let’s talk about vendor lock-in
When you are evaluating a software solution, sooner or later there’s a moment, where the “vendor lock-in risk” is part of the agenda.
So, you better do the homework and analyze it.
What are the main aspects I use to consider?
There are many, these are the main ones I use to check:
- Type of Technology: Proprietary or Open Source tecnology?
- Data Format and Storage, how standard are they?
- Custom Solutions: how much customization are you moving from A to B?
- Complex Integration: how complex is the integration to be done?
- Cost of Change: what is the cost of entering, and what is the cost of exiting?
- Contractual Agreements: what type of agreements are they offering?
- Ecosystem Lock-in: how is the platform
- Lack of Standardization: identify points of low standardization.
- Skillsets available in the market: how easy is to find specialists?
- Team adoption: how easy/difficult is to the existing teams to adopt the work in the new environment?
- Number of substitute products/services available?
- Community of practice: How extended is it?
Context matters and the devil is in the details, so to understand all those dependencies is important to understand what are the viable choices.
Below is a real example of a vendor lock-in analysis where you can find:
- A Wardley map with the main dependencies landscape. The executives are already familiar with this map so the conversation can directly focus on the vendor risks and alternative analysis.
- List of vendors involved in the different integrations and communications between systems: in this way we understand how the dependencies on the map are materialized in a multi-vendor environment.
- A summary analysis of the check list mentioned in the previous section: with details to take into consideration in that particular case.
Behind the scenes there’s a complete document with more details about things as:
- Concrete parts of MSA and contract to be reviewed.
- List of questions to be done to the vendors.
- Requirements document and how the solution satisfy them.
What have been the benefits of this format?
- Fluent conversation,
- Ability to understand main dependencies and different perspectives to take into account,
- Quicker revision of new versions of that document (as people understand the context already).
- The CIO able to prepare for its own reporting in a quickly and proper manner.