Business failure - a tale of procurement woes

Too often I see corporates trying to move into a new area of business, with-out having any hands-on experience or really any way to guide them on how to approach it, regarding what platforms and capabilities  they need to invest in. They then launch into long and elaborate procurement processes (RFI, RFP), that they hope will be fair process of choosing between multiple vendor offerings. But its much worse than a blind date, because with-out any experience to guide them into deciphering what is real and what is just talk, they cant trust what the vendors are putting out on offer. So they really take a leap of faith, put their trust into a particular vendor, and hope for the best.  After a few months into the project they are already disappointed because the promises did'nt turn out to be true. At this point, it does not really matter if they vendor actually delivered what it promised to or not - but because the corporate had inaccurate expectations, based on hope, and not actual data or experiences, they were setup up to fail from the beginning.  So now we start doubting whether the original business case was valid about moving into the new market, or was it just ITs fault for choosing the wrong vendor (hint - its neither the business case not the vendor thats at fault - rather the incorrect expectations thats not based on real experiences)

When I started a new role just over a year ago, I wanted to start actually using APIs, and seeing what API Management Platforms were really about, beyond what I was reading and hearing. I felt that this will make us more better prepared to guide the corporate machine over the procurement process of choosing and buying platforms.

I wanted to get a real feel for building an API, and using an API Gateway/Platform to manage, expose, and monitor it.
I started a with sample Book list API, built using Sinatra on Ruby, by following this awesome tutorial. I had the Book API running on a test VM, and on Heroku.

I then installed the open-source KONG in a container, to manage those APIs. But I really spent much more time on using Tyk, which is cloud based, to expose and manage these APIs.

All of this was very useful in helping us understand and set expectations for what to expect at work when starting to build our API program. We started off by buying some test licenses for Mulesoft, and building some real APIs that was used in our app. That gave us sufficient learning to launch and complete the RFP process, where we decided to go with Apigee in the end.

Then we used a similar approach when deciding what Cloud Native Application PaaS to use. We started off buying licences on Openshift Online, and learning what a managed Kubernetes platform can offer us, by using it to build production services. That then gave us enough info to guide the procurement process through the RFP, and allowed us to accurately decipher what the vendors were really proposing.

This process, of actually using platforms before we buy, put us into a stronger position for success.