My name is Ravee Chintha, an enthusiastic developer and an solution architect by profession. Every since I laid my fingers on a key board, I have been designing and building middleware software. For a solid seven plus years, most of my focus and contribution went into enabling SOAP-based web services. It was during 2008 when I got first introduced to Vordel API Gateway solution. I had the privilege and honor to know and work with a few legends Mark O’Neil, Isabella Mauny who primarily helped me and my team with standing up and leverage the API Gateway in the most and best efficient way possible.
In 2012, Vordel got acquired by Axway. Around June 2013, I had the opportunity to jump the ship and join the Axway team as a pre-sales solutions architect. A hard core heads-down and hands-on engineer to a pre-sales solution architect. Wonder how that happened! As they say, everything happens for a good reason. You just gotta place your trust and march forward. And that’s exactly what I did. Pre-sales is by no means and measures an easy job to cope up with, especially for a shy developer like Yet again, there was Mark O’Neil who mentored and guided me in every possible manner one can imagine.
Starting 2014, I was leading the customer discovery calls, proof-of-concepts, onsite and remote workshop sessions, implementation. The list goes on and on. Needless to say, the travel across the continents, dealing with the jet lag across the timezones were the unasked bonus gifts. Is it all worth it? My answer is “Absolutely!”. A good sales representative, who also happens to be a mentor and friend gifted me the book “Mastering complex sales”. The one quote from the book which sinked deeper into my heart and soul was “Knowing your solution is expected credibility. Knowing your customer’s problem is exceptional credibility”. This one phrase changed everything for me.
I pivoted from giving feature-rich and slides-rich demos to “listen to your customer problems” conversations. The shift in the mindset in a way taught me to be a good listener. It compelled me to make sure I am listening and repeating what I listened with the customer for confirmation. To a degree, the understanding and repeating the problem back to the customer helped with building credibility at the early stages. There were a few occasion where the prospective customers did say “We are glad you actually listened and understood”. No kidding fellas! The minute I hear those words, I knew I already won and crossed the finish line. Despite the wins and losses, which I often rephrase celebrations and calibrations literally, the ONE THING I learnt and am still learning and will continue to learn is “listen, listen, and listen”. If you stop listening, it is end of the deal.
I am not active in the pre-sales arena any more but I have never lost my touch with API Management Lifecycle. I still design, architect, code, and support Full API lifecycle management (FLAM) platforms. I still get inspired and fascinated by the speed at which the API landscape is shifting and evolving. Despite all the fuss and buzz around AI, how AI can throw can automate end-to-end API lifecycle management aspects, the ONE THING I would like to emphasize and make enough noise is laying out a strong foundation.
A solid foundation combined with a shared accountability and responsibility culture is paramount to a secure, scalable, and stable evolution of API platforms. What do I mean by a solid foundation? Let’s dive a little deeper into the bricks which help with the strong foundation.
Brick #1: Vendor-agnostic framework.
This is the first and far most important aspect in my opinion. Now a days, it is rare to come across any enterprise who goes all in with a single API Management solution. Enterprises evolve, requirements change, people and teams evolve. Change is the only constant, they say. With so much in motion, putting your bets on a single vendor solution and making it sticky is a risky thing. It is not a question of IF. It is only a matter of WHEN someone says “the current solution is not working. Time to explore a new one”. Speaking bluntly, phasing out an existing solution with a new one is not easy as anyone says. It consumes time, effort, energy, and budget. And the world is not going to stop for you till you make the shift. So what happens? Guess? You will end up with multiple API Management solutions.
Though almost every API Management solution in the market implement features abiding to RFCs and industry standards, they all have their own unique ways around implementation. A simple analogy would be “same lyrics, different compositions”.
So how do you deal with variations? How do you keep your teams agnostic of the vendor solutions? How do you create a platform with a greater degree of abstraction and encapsulation? The answer is simple. Every enterprise has well established principles, process and procedures around deployments, operations, support, and self-service. Take what you have into consideration and focus mainly on the engagement aspects of the platform. How can an API owner publish, manage, and support their APIs on the platform? What are the minimum “vendor-neutral” artifacts required to lead the end-to-end lifecycle? Once you establish this so called “vendor-neutral” framework, half your problems vanish right away. How? Any vendor solution which does not fit and cannot be customized to fit into your framework, just don’t consider it. It is out of the game!
If you are one of those enterprises who already purchased a solution and making it work, you have my sympathy and empathy. But it is not end of the road. You could still make it work. Just whatever you do, make sure you are always keep the “vendor-neutral” mindset and work towards it.
Brick #2: Security, Security and Security
When it comes to real-estate, the name of the game for the most part is “Location, location, and location”. Similarly, when it comes to using API Gateways, the name of the game is “security, security, and security”. In many RFIs, RFPs and proof-of-concepts I have been part of, I run into questions and use cases which talk about service mediation like REST to SOAP, SOAP to REST, request and response enrichment, custom business logic implementation, service orchestration, service aggregation, so and so forth. Let me put this in simple and clear words as possible. API Gateway’s single and sole responsibility is SECURITY. Anything you do with respect to token validation and mediation, rate limiting, etc. is permissible. Anything outside security is NOT.
It still aches me to see a few enterprises that I worked not able to sunset old API Gateway solutions just for one reason. They broke the rule and made the solution super sticky. Keep in mind that APIs and anything that goes into these APIs is your enterprise intellectual property (IP). No matter what adjective you put in front of your API (composite, orchestration, system, process, experience, macro, etc.), all of these APIs need to be designed and implemented in the backend and not within API Gateways. Sticking to this one rule is enough in my opinion to build a loosely coupled, flexible and extensible API platform. It will even help with narrowing down your options of selecting the right API Gateway/Management solution.
Brick #3: Shared responsibility
Have you ever come across the question “who should own the API Gateway/Management solution”? I did! Almost every time. No kidding! It is a fact. When I was a customer of Vordel API Gateway, my team took the sole responsibility of standing up the solution, developing and publishing security policies, real-time support, NFRs, etc. As much as I learnt from this opportunity, I did also lay a great foundation for giving birth to going bald. Lesson learned hard way. Throughout my journey in pre-sales, I continuously preached and still preaching on every opportunity I get to think, adapt, and implement a shared responsibility model. If you are a small enterprise with skeleton staff, sorry! I am not much of a help here. But if you are an established enterprise with well established teams and boundaries, please make all the stakeholders (SecOps, CloudOps, DevOps, API owners, support, etc.) responsible and accountable. Make sure to define a RACI matrix and follow it to the core.
That’s it for now! If anyone is interested, you are welcome to connect with me on a specific topic of API lifecycle management. I love to connect, ideate, and hopefully become worth your time. Adios!
