Buy @ Amazon

Key Things To Consider Before Adopting A Third-party Vendor Platform

on


Build vs Buy is always a tough decision to make. In the absence of an Architecture Board/Council/Group in a Scale-up company or bigger ones, it is likely that a Technology Head can overlook some critical things in their decision making of technology choices. Sometimes the repercussions of these choices could cost a bomb - no pun intended. I have witnessed real bad outcomes in the light of such circumstances since the beginning of my career, especially during my consulting stints. 

In the recent past, I had the pressure of witnessing a company adopting a third-party vendor platform to re-engineer their existing micro and macro services to be developed and deployed on it. Unfortunately, even at technical leadership level, no one had a clue as to why this platform was chosen, how did they zero-in on this over any other available options, what is the road-map for this re-platformization etc. Blame it on the rate race we were in, instead of having a room for conversations to get enlightened or the absence of documents supporting such big decision. It happens in the tech world, although I wish it doesn't happen. And it likely wouldn't happen, if an Architecture Council is established and they drive decisions and collaborate with other stakeholders in the execution of a roadmap.

If your company is scaling up and you are a technical leader, setting up an Architecture Council is likely your first best move. Once you have it in place, and you encounter a situation where you have to decide on a third-party proprietary platform for your re-engineering or platformization efforts, I have compiled below a list of key things to consider, discuss and publish the data points for your decision making:

  1. Vendor Lock-in : This is the first thing that should hammer your mind to safeguard the interest of your business. Adopting a proprietary platform introduces dependency on that specific vendor's technology stack, APIs, and ecosystem. This should in all likelihood limit your ability to switch vendors or transition to an alternative solution in the future. Consider the long-term implications and evaluate the ease of migrating away from the platform if needed.
    In the event of your company's dissatisfaction with the vendor for what ever reason it be, what are your answers to the following questions:
    1. How long does it take to move-out from this platform to another? 
    2. Does this timeline and migration cost, justify the investment (again both of time and cost) that is to be made to onboard on this vendor platform?
  2. Cost : Even popular platforms are criticized for their cost and it is a genuine concern to have it addressed. Vendor platforms often come with licensing fees, subscription costs, or usage-based pricing models. If you were to engage their professional services in your endeavors of embracing their platform/tool, it usually costs a bomb (no pun is intended here). Depending on the scale and complexity of your application, the cost of adopting a vendor platform may be a significant factor to consider, particularly if it requires a long-term commitment.
    Try answering the question:
    1. What would be the ball-park cost of onboarding the vendor platform + vendor's professional services + training cost of your development team including all developers, quality analysts, product folks etc + cost of development on the new platform + cost of deployment of your services on the vendor platform including the cost of using their network bandwidth, storage, processing, etc. + cost of ongoing support? 
  3. Customization Limitations : Vendor platforms are designed to address common use cases and cater to a broad range of customers. However, they may not fully align with your specific business requirements or have the flexibility to accommodate unique needs of your business. This requires working in tandem with the product and ensuring that you are having a good grasp of the domain and how the existing system is built to address it.
    To safeguard yourself and the business in suffering from late discovery, prepare a checklist of things like below to have it documented:
    1. Existing domain documentation to grasp the business flows.
    2. Existing system documentation to grasp the components involved and know their behaviour.
    3. Existing system challenges/pain-points to know if your choice solves these and how they can with your choice of proprietary platform.
  4. Vendor's Reliability : Embracing any vendor platforms imply relying on their ongoing support and maintenance. Beyond the cost, there are other factors to consider such as the vendor's reputation, track record, customer support capabilities, roadmap for future development and more importantly how is their market capitalization in general and more importantly with regard to your specific business domain. Assess the level of trust you have in the vendor's reliability and their ability to provide timely updates, bug fixes, and support when needed.
    I would care to find answers for the following:
    1. What is their tech-stack on which their platform is built? How contemporary or cutting-edge is this tech-stack? I for one, flag crypto and blockchain as risk, personally because I'm not comfortable with it for lack of know-how on how it works.
    2. What is the infrastructure on which their platform is built, and who maintains it? Say, for instance, if it is on-prem of the vendor, I would doubt its scalability. Or say if their infrastructure is built on open-stack and that it is maintained by another third-party other than the vendor, I'll check to see if that vendor's vendor reliability is appealing to me. It is an OMG moment for tech leaders.
    3. Who are the vendor's current customers? If my company is an NBFC that is into lending, I would care to see if there are other customers in the same space who have adopted this vendor. IMHO, there is significant risk to business in being a first-mover and I would want to be explicit on how the pros outweigh the cons.
    4. If you are into regulated business, how does this vendor cater to those regulatory measures?
    5. Does the platform provide for enough security, high-availability, scalability needs, etc.? 
    6. Does the vendor cater to the needs of customization requirements and how does that work for us as a consumer company?
    7. How financially stable the vendor is? What is their market ranking in the space they are operating? For how long have they been operating in this space?
  5. Learning Curve and Motivation : Introducing a vendor platform often means your development team will need to acquire new skills and expertise specific to that platform. This learning curve may require additional time, training, and resources. Assess whether your team has the capacity and willingness to invest in acquiring the necessary expertise.
    Seek answers for:
    1. Does the vendor cater to the training needs - classroom, online, recorded sessions, documentation, demo app and environment?
    2. How steep is the learning curve for onboarding various roles? Do they provide role-wise training?
    3. Is the team motivated to let go of their love for current tech-stack in adopting the proprietary technology? Do they have FOMO of their market value and thus compromising their career?  
Simply put, the decision to adopt any vendor platform depends on a careful evaluation of your specific application requirements, budget, timeline, and strategic goals. It is crucial to weigh the benefits against the potential drawbacks and make an informed decision that aligns with your organization's unique needs and priorities.