Evaluating vendors in today’s landscape
The post discusses how cloud gradually and AI today have transformed the build v/s buy landscape and therefore, the vendor evaluation criteria, forcing a relook at how we think about vendors.
6/14/20263 min read
The post discusses how to think about vendors today due to the fundamental shift to the cloud and in cloud technologies including acceleration of AI. The shift has been in the making as cloud transformation took place over the years. What used to be the Datacenter model of strong affiliation with specific technology stacks, is now a diverse set of technologies across multiple clouds.
The technology diversification in the cloud has been made possible by software at scale on continuously increasing physical infrastructure around the globe. The result is leveling of the playing field for vendors through reduced barrier to entry, where everything is software with no hardware dependency. With the influx of AI, the time to create software continues to go down significantly while enabling more complex applications (look up compound engineering). Anyone with good prompt skills can create applications, resulting in increased software access more generally to non-software acquainted people. So, naturally one may question, why do I need a vendor?
The answer depends on use cases, application development lifecycle, AI and application retirement. The following are a set of high-level considerations that may bias your strategy to build or go with a vendor:
Define use cases and stakeholders
What is the nature of the problem you are looking to solve?
Defining scope will help you to focus on key objectives and prevent solving for everything.
Who are the users of the application?
Ultimately, the purpose of the application needs to work for its users and knowing them is important.
Evaluate Application Development Lifecycle
Do you plan to add features?
A static application is easier to manage whereas, complexity tends to increase with requirements.
How the application will be maintained long term?
Beyond features, understanding infrastructure needs over time will help to determine maintenance requirements (e.g. data growth, upgrades, compute changes)
Track use of AI
How do you plan to keep a handle on the application?
With AI, there is a departure in human understanding and closeness to application development. A deliberate focus on how application is developed, changed and managed will help here.
Plan retirement
What is your exit strategy?
Keep an updated view of depending applications to inform a transition plan. If planning a replacement, a plug and play model can support smoother transitions.
Answering these questions with a weight tied specific to your needs can help determine whether building or going with a vendor application makes the most. The questions do not look any different just because of AI. Interestingly enough, you can frame AI as one of the “vendors” in which you have more influence on design, development and maintenance.
When you go with a vendor
The following considerations can help to rethink evaluations when considering a vendor for your application or solution needs:
Everybody can build software
With global cloud access, software build ability is no longer a strong differentiator. Any capability developed today can be scaled and replicated with AI in relatively less time now.
Roadmaps will change
An initial capability assessment is point in time and roadmaps are going to be even more dynamic, given increased pace of development and because of point 1.
Mergers and acquisitions can change everything
In a vendor situation where roadmaps align both short and long term, mergers and acquisitions can alter previous understanding.
Not to forget, the classic concern of lock in
When dealing with a vendor solution, you may be forced to a vendor lock in where portability is not easy (e.g. proprietary protocols, data formats). This is no different today with the exception of increased consolidation of features due to points 1, 2 and 3 so you might as well benefit sticking with an existing vendor.
To expand on point 1 on broader software build ability (and important one), it has enabled new entrants while allowing existing vendors to expand capabilities in different domains. As an example, a cloud IAM capability is not only offered by different vendors both new and existing but also by vendors that may not have previously operated in the IAM space. Further, point 2 on roadmaps and point 3 on mergers and acquisitions can be leading indicators to determine if an existing vendor is looking to expand capabilities in the IAM domain. In other words, evaluating a vendor in today’s world is more fluid and requires continuous focus than ever before.
Key takeaways
Building applications is getting easier for everyone. Build your own or buy from a vendor has become less about capability with reduced cost and effort, thanks to cloud and AI. Ability to pivot from your build to a vendor application or between vendors can enable faster realization of use cases and user requirements. The crux of this pivot in my opinion lies in a plug and play model which avoids minimal upstream and downstream impact to other applications and technologies. As for the changing user interfaces between these pivots, I believe the AI agent can act as the consistent layer, which avoids constant user unlearning and relearning.
NO AI TRAINING: Without in any way limiting the author’s exclusive rights under copyright, any use of this publication to “train” generative artificial intelligence (AI) technologies is expressly prohibited without author's explicit consent. The author reserves all rights to license uses of this work for generative AI training and development of machine learning language models.