Subramanian Krishnan, @citrix

Thank you for tuning in to today’s full episode of the Breaking Changes podcast. I’m your host and Chief Evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today we have Subbu Krishnan, architect for the technology strategy organization at Citrix. Subbu shared with me a very sobering view of what API governance looks like at a large enterprise organization, providing a blueprint that I’m going to be revisiting over and over for many months and years to come. I always start with the basics, really simple. Who are you and what do you do?

My name is Subbu. I work for the technology strategy office in Citrix, and as part of that, it’s a horizontal organization which caters to the needs of all products and services, and my specific focus there is APIs. API infrastructure, API strategy, API design, best practices, anything to do with APIs I like to get involved. So that’s what I do, and I’m one of the people who founded the Citrix API platform when we started on the journey in 2018.

So what started this journey? Why did you feel like it needed to happen?

Oh, I mean we badly needed it, and a lot of us also believed that we were actually already late even when we started in 2018. Quite a few things we were seeing happen, Kin. To name a few, one is that we had different services and products and each one did have APIs even at that point in time, but they all looked so very different from each other, so there was nothing called consistency. For an outsider, if they look at two APIs coming from the same company, it wouldn’t look the same, it would look like two different companies. Part of the reason is that things happened organically, things happened in silos, and things happened because of acquisition. So there are good reasons why it happened, but net net, it was not a good idea to have that kind of a different view of the APIs that Citrix had. So there was no consistency, and to add to that, even if somebody wants to look for documentation for APIs, there was no one way or one place to go. Some teams had PDF documents, some had HTML documents, some had zip files which you could download from the product documentation, and some had curl commands embedded within the product documentation. So it was totally all different ways of doing things, and when it comes to the experience of the consumer it was very inconsistent, and if I may say, a little bit frictional and painful also. So that is the other thing we wanted to fix, in terms of how do you go and look for documentation in a standard, consistent way.

So documentation, and to add to that, in terms of security, what you could do when you have an API gateway in place, what you could do when you had policies to rate-limit so that your back end doesn’t get overflooded with requests, all that good stuff that we wanted to have, but we had not taken any concrete action to make those things happen. So in 2018 we felt that it’s high time that we do something about it, and that’s how we got started on the journey.

So you speak of consistency. It’s not just consistency in the design of the API, it’s consistency in delivery and operation of the API.

Absolutely, and consistency in the experience of the consumer. It’s a different world and experience, like some of the documentation, it’s almost like dumping something on the developer, so it’s not catering to the needs of a consumer, you are not showing them the needed respect. We had all varieties. Not to say that people were not doing good APIs, there were some teams who were ahead of others, but you are absolutely right, consistency in terms of where you look for it, how is your experience when you work with those APIs, all that thing was not in place, and we wanted to start fixing those things one by one.

So I know at a large enterprise, when you have everyone evolving on their own journey in their silos separately, when you try to put in place some sort of governance to try to dictate or help, even help, you get a lot of pushback from people. So how did you go about getting everybody on the same page here?

I mean, you just know it, Kin. You said it absolutely right, that was indeed our experience, and there were many learnings along the way, and I do want to touch upon some of the key ones. One is, we definitely learned that trying to force things on others, or push, or trying to be on the pedestal up there somewhere saying that we, a bunch of people, know how to do APIs and the rest of you follow us, that doesn’t work, because we are talking with people who are very busy, we are talking with people who are very intelligent. So trying to force or dictate things doesn’t work. We tried various approaches and that’s not something which works. What we found really works is being there in the attitude of someone there to serve them, to help them do things the right way, so that they reap the full benefits of the APIs the teams are building. So that mindset itself had to shift, from up there somewhere dictating, to somebody who’s your partner, who’s your ally. That helps.

And also, as we moved along the journey, we realized that if somebody doesn’t want to do it, you don’t stop there and say that they are not interested. You try to dig deep, what is stopping them, and when we did those exercises of trying to find out what is preventing them, we are not telling them something wrong but what is something which is stopping them, then we had a lot of learning. One of the very first learnings we had is that something similar which was attempted some time back didn’t go through very well, and one of the reasons was that it was not an all-inclusive approach. So when we did the API guidelines and started drafting it, we took people along, and what I mean by that is we enrolled or recruited architects from each of the services, at least minimum one person and somebody who is respected within that team, so they are a part of what we call the API virtual team. A group of architects together discussed and debated on the guidelines, and together we committed and signed on it and agreed that, okay, this is what looks like good guidelines for us as Citrix and we commit ourselves to follow it. When you have that kind of a buy-in, even though initially it takes a lot of time to have all those discussions, debates, arguments, back and forth, and redraft things, you are actually pushing it left, which is in a way good, because it’s good to happen in the beginning rather than late in the game. Because then making changes means everybody gets affected. So taking people along right at the very beginning, that helped us.

Some of the other challenges we found is that we took a very prescriptive approach. So it’s a huge document having so many sections, and we, by the way, were inspired by a lot of good guidelines that other companies have created and been generous enough to publish out, so we took our inspiration and gave credit to the inspiration wherever we took it. The other thing we realized is that it’s quite a lot, and if I remember correctly there were 250-odd must-have guidelines. We were following the RFC format, and there are a lot of musts, shoulds, mays. So nobody even cared to look at the shoulds and mays because the musts itself was quite a big list, and people said this is too much for us to comply with, and we don’t have that kind of time and bandwidth. So very quickly we realized that number one, trying to do things manually is not going to work at all. Initially we tried doing Excel sheets and marking with a yes/no, all that stuff doesn’t work and is very painful, and if you redo things you have to start all over again. So we realized that we need some kind of automation to automate whatever can be automated. Unfortunately in those days we didn’t have what we can do with Spectral today, so we ended up building our own homegrown validation service, exposed as an API as well as a GUI, so you can upload your OpenAPI or Swagger and get feedback at least based on the statical analysis of the specification. That definitely helped, because that reduced the pain point and friction for people who wanted to do the guidelines but were finding it difficult to manually navigate that.

And the other thing, finally I would like to say a couple of things. One, we started this Slack channel where people could go to get support or get clarification or guidance on why some guideline is like that, because we try to write everything, but still there is historical context which cannot be always written down. Sometimes people want to do it but they want to be sure, like, why did somebody, is it a typo by any chance, or did they oversee something. So it helps when there are people who can answer and provide guidance, provide support, and be there for them. And even that needs to be scaled, so we again realized that a small number of people can’t do it, so we looked for people who are very passionate about the whole thing, and we took their help to champion the cause of doing the API design right and also being there to help others. That attitude of helping others and being available really helped us a lot in our journey. As I said, that Slack channel and the validation tool and a place where people can interact and get guidance, that helped us a lot as far as the guidelines and governance processes was concerned.

Yeah, it’s a very familiar journey I’m hearing from a lot of other enterprises. They’re at various stages of that same evolution and realizing how hard this is and how much work, and how automation is pretty key. But one of the things I get a lot of enterprise folks asking, telling me, is, well, how can we just put all of those rules in the gateway, or block it from going into the portal, and make it so people just can’t ever publish. And I’m trying to help them explain that that’s not really a good idea, you’re probably going to have more problems. So what balance are you seeing? Do you enforce it at the portal, at the catalog level, do you enforce, educate at the design level? How are you finding balance?

I mean, very spot-on observation. We also tried that approach, where we have the guardians and custodians of the infrastructure, so, guys, unless you follow every single thing we say, we are not letting you onboard the gateway or portal. And you know what happened, people said, okay, we don’t even want to be onboard. So again, that forceful approach, that trying to impose things on others when they are not bought in or when they have other genuine concerns, we realized quickly that doesn’t help, and more than that, it actually starts hurting. We were in a situation where there was no adoption happening, and you tell me, what good is a platform, a portal, or a gateway when there’s nobody onboarded on there? So very quickly we had to learn our lesson and correct ourselves and say, no, this is not the approach which is going to work, that you prove your worth, so to say, and then we’ll allow. That’s not the way. We are their partners, and there is some good stuff, good capabilities available when they are onboarded on the portal and on the gateway, so we have to encourage and support people. So we took a slightly lenient stance, wherein we said we’re not going to block you, we’re going to encourage you to comply as much as you can, help and support and figure out what’s your genuine concern and how we can address that. And in many cases it was okay to give an exception. For example, there are legacy APIs, you cannot go and change everything from scratch, that takes too much of an effort. And APIs are one more thing people are doing, so we have to also understand that they are in product and there are other customer requirements which may not be API-related. So there are many things which are pulling people in different directions, and trying to make them do everything that you want them to do, that doesn’t work, that bargain doesn’t work. So we realized that we have to strike the middle path, the middle ground, if we all want to be win-win and successful. Then that started working for us, because then we realized, okay, maybe there are a few which are non-negotiable when it comes to security, when it comes to the way you do auth and certain other things, but not every single thing has to be forced down their throat. So here is the prescriptive guidelines, if you want to read it in detail and comply with everything you are free to, and that’s what we encourage you. But if you feel that’s not worth your time, or you want to strike a balance so that you go out there rather than doing your APIs for the next six months or one year to get it 100% compliant, even we agree that it’s important to put things out there rather than keep beautifying it. So that’s what we again learned, and what worked is trying to look for that middle ground, and again being an ally here rather than trying to be custodians of the infrastructure, that didn’t work for us.

Yeah, no, it’s an important balance, and I see each company’s a little different in the culture depending on if they’re more developer-led, more IT-led, more business-led, or a mix of that, you get different cultures who are willing to do different things. But people are smart, people are opinionated, people are busy doing their jobs, and you can’t always just tell them what to do, and maybe they actually know better and your guidelines are wrong and you should update your guidelines.

Absolutely. It happened just two days back, the day before yesterday or something, when somebody pointed out an actual contradiction. So in two different sections two different things were written, and when he pointed out, I started wondering, and the first thing I said is, thank you for bringing this to my attention. It’s not that I know it all, I stand corrected, all the people who looked at it. And that was not a deliberate mistake, it’s just that two different sections you talk about the same thing in different languages or different interpretations, and that ends up being contradictory when you put them side by side. So that’s exactly what this person did, and then I said, in this case A supersedes the guidance B, because that’s how the HTTP protocol wants it to be. So you’re absolutely right, people are smart, people sometimes know more than what you know, so you have to be their friend and sometimes you need to even get corrected based on the inputs they give. Which is why one of the other things we also did is that we didn’t freeze the guidelines saying that this is written in stone and now nobody shall ever question it. Instead we said this is also a repo like any other repo, feel free to submit your PRs. In fact, we don’t have that much bandwidth in any case, so instead of making us craft the changes, why don’t you create PRs and submit, and then we’ll review and merge. So there have been people who have contributed to that, meaningful and valuable contributions. So you’re absolutely right, you’ve to go to the extent to take people along, if I have to summarize in a sentence, that’s what it would be.

Yeah, getting people’s buy-in and having them be part of the process and seeing they can make changes as part of that. And APIs are hard to see, and guidelines are hard to see applied to your API, especially when you have two, three, four hundred of these rules that you have to do. But one of the ways that we make APIs more visible and able to see or apply is the product catalog, or the portal, or the gateway. All this convergence is where a lot of the APIs become real, they become tangible for both producer and consumer. So talk me through how you approached your portal strategy.

A very valid point, and you’re absolutely right. Guidelines is fine to implement, but then the end product has to be visible to the end user, and that’s where the portal helps, all that discovery, the catalog where you go look for it. There’s no doubt in our mind that we needed one for sure. In fact, we also wanted to do some kind of consolidation, because what was happening, as I was saying in the beginning, is that there were documentations all over the place in different ways and forms. So we had to look at one place where, not just you list the APIs and have these APIs properly and consistently documented, but which can be the home landing page from where you get guided to the other documentation, which could be links from here, which may not be directly REST APIs, could be an SDK, could be some other form of an API, but at least you start from here and then you reach wherever you want to reach. So we did want to have one starting point.

When it comes to a portal, again, it was a learning, because our initial thought was, okay, let’s go and take the first best thing and create the portal, and then we were successful, we were able to have that portal. But again very quickly the learning started coming in. Some of the key learnings we had as that one, what we had taken was something which was coming from a vendor, and that had helped us get started quickly, but that really cut our wings when it comes to customization and flexibility, because we are a big enterprise, we have a lot of stuff that we want to put there, and we have our own creative ideas, and none of which could be accommodated in that portal. So very quickly we had to start thinking about V2 of the portal. So we ditched that third-party-vendor-based one to create a homegrown portal. But I’m still glad that we started somewhere, because unless you start somewhere, the learning doesn’t happen. If you keep debating on PowerPoints and meetings, it’s just more meeting minutes and drafts and documents, but when you create something and put it out there and people can look at it, play with it, then the real feedback starts coming. So you can call it an MVP of sorts even for the developer portal. So I’m glad that we made that mistake, because that helped us learn, and we quickly corrected ourselves.

Some of the key learnings with respect to the portal is that you want it to be something which is customizable and flexible. I’m not saying that you have to always write it from scratch, there are vendors who provide you that kind of flexibility. I am talking of an era like 2018 where we didn’t have that kind of flexibility, so that is something we want to keep in mind, you don’t want to get straitjacketed into something which doesn’t let you move left or right, you want a little bit of flexibility. So for us, writing it from scratch helped. Self-serviceability is absolutely important, because again, the other mistake we had initially made is that we had the central team and a bunch of developers, and we told people, oh, you want to get your document published, okay, mail it to me or send it to me or put it here and we’ll take it and upload it. And that’s how we were initially doing it, and that doesn’t scale. And then when people are making constant changes and corrections, that cycle time increases, it frustrates the people who are doing the job of updating, because it’s very repetitive and boring. So we again realized this is not something which works, we want something which is self-serviceable. So when we were designing our own homegrown portal, we made sure that it is something which is just as simple as checking certain files in a certain format into a Git repo, and then there’s a way to create a developer version of the portal where you can actually see your changes, play around with it without touching the actual production. So you could do whatever you are doing, check in, keep making changes, keep seeing how beautiful and how perfect it looks, and only when you’re satisfied you merge the PR into the other branches, and there on the CI/CD kicks in and takes it forward. So we made it extremely self-serviceable, except for some checks which we put in place just to make sure that people don’t by mistake publish something which is not supposed to be there. There were minimal checks and balances, but it was nowhere close to the manual work which was happening initially in terms of collecting all the files and putting it there. So that was the second key learning, that it has to be self-serviceable, enable people, and you would rather spend your time creating tutorials and videos on how to onboard rather than collecting files from people to personally go and update, or have your team do that.

The other thing we also found is that initially there was a word of resistance, the initial one or two people it was hard to get there, but once people onboarded and when they saw that final portal and how the documentation looks there, the experience of it, the consistency of it, the ability to try, the ability to download a Swagger, so many things which you were not able to do before because you are not following certain practices and principles and using certain capabilities, now all that was at length. They didn’t have to invest any time other than creating the OpenAPI aspect, which anyway they need to start doing for a good API. And mark also, we didn’t restrict ourselves to only OpenAPI, because there is something you can document and there are some things you can’t. For example, in explaining your API you want to put a diagram or a link to a video, you can’t put it in the OpenAPI. So we made it a little bit flexible, saying that OpenAPI is the actual specification, but you might need some surrounding things which make the whole experience complete and put things in context. So here is an opportunity for you to create markdown files, put whatever you want, the diagrams and text, make it bold, make it italics, change the font size, do whatever you want, and the CI/CD will pick it up and it will show up nicely on the portal. And again, I feel really happy, because when you look at the final documentation it looks complete, it looks consistent, which creates a good experience. So portal, again, a journey, and it’s an ongoing journey, we are not done, more to do, but still proud of where we are and the distance we have covered so far.

So why do you do this? Why are you so obsessed with APIs and making this change and being on this journey, because it doesn’t sound easy?

I mean, that is something even I asked. As a technologist, I’ve been in the industry for 20 years, but some things naturally call me to it and some things don’t. Some things I have to do, some things I love doing. So I don’t know why, but ever since I got associated with APIs or got interested in APIs, there was no looking back for me. And Citrix is actually my second stint when it comes to APIs. Even before Citrix I was with IBM, and there, towards the last one and a half, two years, we were building a cloud-native service which was all about cloud integration, creating REST APIs for doing operations on a system of record, be it Salesforce, be it PeopleSoft, whatever. There the abstraction was a connector, and the most beautiful thing about a connector is that it exposed REST APIs, it consumed APIs, and the whole life cycle of a connector was through APIs. So day in and day out we were doing only APIs, and I love that whole experience. And then I have thought, why does this appeal to me so much? The closest I could come to it is that, for me, API is something which allows value to flow, and to the extent you enable value to flow, it does overall good, and to the extent you block value, keep it to yourself or keep it in a silo or keep it locked up somewhere, you are minimizing the impact that you can create. So for me what API philosophically means is an abstraction which allows value to flow freely. Of course you can put your checks and balances, maybe somebody might want to monetize, nothing wrong in that, but unless you have the abstraction which allows value to flow, you are restricted, and again that also curtails creativity. So I feel passionate about APIs probably because if you do it right and you have the right thought process and attitude and work towards it, you see a lot of value flowing, and then the innovation that happens around it and the impact that happens around it, it means a lot to a business, it means a lot to me as a technologist. When I could build whatever tool, for example that validation tool I could have built, but unless I make it available to others through whatever means, and in this case it was an API and a GUI, how will others use it? So if I want to make it available, I better have APIs, and if I want the APIs to be easily usable, I better have good APIs. And that has been my thinking. And you’re right, it’s not an easy thing. In fact, I do wonder, technology is one part, but how do you share this passion and love? Something which bothers me is, how do you make others love APIs at least part of how much I love it, how do I share the love for APIs with others and make them feel about it the same way? And this could be a developer, this could be a product manager, this could be even the C-level executive. And I don’t have an ultimate answer to that, Kin, and if you know, you should probably let me know, because that will definitely help me. But I do feel that if people love APIs, if people genuinely understand what an API does for them and what it can do for the business, the way they approach it, the way they invest in it, the way they leverage it will be very different from a mindset where two or three people are trying to force things down other people. That doesn’t work. You have to know it, you have to love it, that’s when things happen the right way. That’s my belief and my experience so far.

Yeah, well, I don’t have the answers either, that’s actually what this show is for, is to try to figure out the answers, and you’re all supposed to be bringing me the answers, and then I’ll get all the credit and being the person who ends up knowing and giving it. From what I’m seeing in the conversations on this show, which I’ve had quite a few since January, I think we’re around 50, 60 conversations I’ve had, the one theme that I’m seeing that gets people caring about APIs is they’ve got to be successful in what they’re doing, and that means it’s got to have alignment between business goals, what the consumer needs, the user of the APIs, and then what the developers want, and there has to be a balance between that. And that’s what, API product managers, I see a lot of product managers evolving and iterating, because they’re really working to be that bridge. They respect and care about developers and acknowledge that developers and IT have a lot of power and a lot of knowledge and understanding, but then the consumer also needs certain things, and then there has to be that business alignment. So that’s where I see the big next iteration of what’s happening here, is product managers involved in that conversation, and it changes the tone of the conversation that I see in IT groups.

That was again spot on, and very insightful points that you shared, and that has been my observation too, to the extent that I have observed, and I’m not talking one particular company, based on my conversations with a bunch of people across the board. One very good way to figure out where somebody is in their API journey, their maturity level, is talk to product managers. So if you ask a product manager, do you know what APIs you have, and if they don’t even know, that tells you they’re not even started on that. And if they say, okay, it might be there somewhere in the documentation, that’s the lowest of the low levels. Whereas, let me go step by step, the next level could be somebody who says, oh yeah, we invest in APIs and we follow the guidelines and we onboard onto the portal and this and that. So it’s like, okay, some bare-minimum thing they are doing to just make sure that at least it’s designed properly. But the real catch, in my opinion, the highest level of maturity is when you actually have a product manager. That’s one very good way of knowing how a company is invested into APIs. In fact, when anybody approaches me or tries to talk to me, I try to figure out, do they even have a role for an API product manager, because if they don’t, then it tells me from the business side there is not that much focus and interest, it’s just a technical game that they are playing, which has nothing bad in itself, but again, I call it intermediate level of maturity. Whereas if you have API product managers, and when an API product manager talks and they talk about API roadmap, and if the word API gets them excited, they talk about use cases, they talk about the addressable market and what kind of things customers are building and how they are going to enable that, and start talking about monetization, take it from me for sure that that organization is deeply invested in APIs. That’s my thermometer to figure out how far somebody has gone in the journey. And that’s how even I tend to look at, even in my own organization, how we are maturing. At one point nobody was talking monetization, nobody was talking APIs for use cases, API-first, API product, at the max it was, okay, let’s talk guidelines, governance, and infra, but then now I slowly see things changing and product managers are beginning to talk about it. And that, if you ask me, is a very good sign, a very healthy and very welcome sign. And you are absolutely right, until the business is supporting you, till the product managers are your allies and they are actively driving it from the forefront, it’s very hard for just a bunch of technologists to get together and get the API program right. I don’t have too many cases who have done that.

And one more point if I may add here, when I ask you that question of how do you get people to love APIs and get them really excited about it, one of the learnings we had along our journey is that, tell people the value in a way that they can understand. It is one thing to tell them, okay, here are the onboarding documents, go onboard onto the portal or onboard onto the gateway. Okay, they will ask you why should I do that, what benefit, anyways people are using my API, what benefits. But when you shift the conversation around the benefits they will get, so I can give a few examples. One is, you can talk about, okay, today how are you securing your API against a DDoS attack? What will happen if somebody tries to bring down your API intentionally or unintentionally? What kind of protections are you building, and if you are building it, how repetitive and how much resources you’re investing on that? But here is some welcome information for you, that if you onboard onto the gateway, this entire infrastructure has an ingress, it has a WAF in front of it, it has DDoS protection, so just by having your API there you get all of this for free. You don’t have to spend one more dollar of development or test effort, it’s there for you. So when you start talking in that language, what benefit they get and at what cost or no cost, that gets people excited. The other conversation which has worked for us is talking around analytics. We may ask them, do you know how many API calls are coming into you, do you know which is the most-used API, what’s the average response time? And people don’t know the answer, but then when you show them the dashboard for the API analytics and show them all those numbers, you say, the people who are getting these numbers didn’t have to write any analytics code or create their own Splunk or anything, they just onboarded, and just by onboarding on the gateway these metrics start getting populated automatically. That’s how easy it is, and then again people start getting interested. So one thing we realized is that you talk value, value for them, how it’s going to help them, people get very excited. In fact, we have seen that change in terms of adoption also. At one point we were chasing around people asking them to onboard their APIs on the portal and gateway, and there have been times when we had to turn down people or ask them to wait and put them on a waiting list, because we wanted to be doubly sure about the capacity that we have, we didn’t want to have an API which is coming and consuming a lot of the capacity we have and thereby starving others. So we wanted to deliberately do it, even though it’s self-service. And that was again a very welcome change, wherein from a place of asking people, to a place where you tell them, you wait for some time, we see that you want to get the value, but let us do it the right way so that, because it’s a multi-tenant thing, let’s not disturb others and roll it out in a way so that everybody benefits without anybody getting disrupted. So talking value in real concrete terms is again something we felt that it does help when you talk to people and try to influence them to do the right things the right way.

Yeah, no, I would say that’s consistent with what I hear with other conversations, is that value exchange, if you focus on that. And the other part I heard you say is enabling people to focus on the value creation, so they’re not spending their time building out another analytics system or another firewall or becoming security experts, they’re able to just focus on the thing, the value, the business value that matters to them and makes their life easier. And that enablement, that’s the other consistent theme I’m hearing, is governance is something we talk about at the higher levels, at the center of excellence, no one cares about governance and operations, they just want to be enabled to do the right thing and not make mistakes. And so governance is just about enablement. But I’m really curious, you mentioned it in there a couple times, what is your definition of API-first? What does it mean to you?

The honest answer is there’s no one definition. I would look at it like the famous story of a blind man looking at an elephant, and somebody catches the tail, somebody catches the trunk, and they’re all right in their own way, but none of that is complete. So a few thoughts which come to me when I hear API-first. The first word is like treating APIs as first-class citizens, and what that means is directly what I was talking to you about, showing it the love that you would show the other parts of the system or the other things that you develop. So not treating it like a byproduct or an afterthought or an addendum, that is what is API-first, that is treating it as first-class citizens when it comes to support, when it comes to quality, attention, and investment. That is one way I qualify something as API-first.

The second thing, again sharing real examples, I have seen cases, without quoting organizations or teams, where people do the development, and of course in the development there will be some annotations in the code, and then they’ll run a tool and that will spit out an OpenAPI spec, and then they say, okay, this is my API. So I say, no, that is not API-first, that is API-last. You did everything that needs to be done, you did the implementation, and now you’re telling me this is my API. API-first is not the same as having an OpenAPI spec or a Swagger. It’s like, when you think about the design and interface first, and then get feedback on it from all the relevant stakeholders, and then get a buy-in, and then agree to it, commit to it, and not lock it in in some sense, and then start the implementation, that is API-first. So when you pay attention to the interface first, that is again API-first for me, doing it the right way, the way it needs to be done, which is again same as treating it as first-class citizens, whether from the producer standpoint or from the consumer standpoint. So that is the other interpretation I have of API-first.

And the third one, which again I use once in a while, and I have seen that in practice not a lot but quite a lot, people who are aware of it, is people who have this mindset that, I don’t care about the GUI first, I’m not going to spend all my time trying to build GUIs before I go out and deliver my capability, so I’m going to go out with my API first. And yeah, some of the capabilities might be there in the GUI but not all of it, because that’s too much time, but I want to get feedback, so I’m going to go hard with my APIs first. So my first delivery will be in terms of the API, GUI might be along with it or might come later or might never come also, for that matter, because we have seen cases where consumers don’t want to use your GUI, they don’t care about it for whatever reason, they want to integrate the capability into their portal, or they want to maybe just write a bash script or a Python script and not use the GUI at all. So the third way I would call out API-first is when you get into the field with your APIs first, then your GUI or your documentation or whatnot. So that’s the third way I interpret. There’s no one way, as I said, but I have seen all these things, and for me it’s a beautiful combination of all these aspects that qualifies as API-first.

I like that, it’s flexible, it’s pragmatic, it’s prioritizing the things that matter, it makes a lot of sense. Well, I really love your view of things, and I always love chatting with you. I look forward to the next time we get to hang out in person, because it’s been a while, but I really appreciate you coming by today and sharing your journey.

Absolutely, thanks for having me, and it’s such a complete pleasure to talk to you, Kin. And I know I can’t end the call without saying a few things. Number one is, thank you to people like you, because I didn’t know anything about APIs when I started on my journey, I think it was 2014 or around that time frame, and it was people like you, people like Mike Amundsen, Erik Wilde, you guys are from the front leading the charge and also generously sharing your knowledge and connecting people and putting out thoughts, putting out wisdom, putting out learning. So if I’m able to contribute even a little bit, a lot of it has actually come from you and people like you. So really grateful and thankful to all of you for being there as somebody whom we can look up to and learn from and get inspired by. So that’s one.

And one more thing I will definitely say, I absolutely love Postman, and I think I got started with Postman sometime again in 2015 around that time frame, and I just love it for the simple reason that it helps me get my job done. But more than that, there could be other tools which do that, but for me there’s this emotional connect with Postman, because it helps me tell a story. I have blogged and posted about it, how in certain cases it helped me make an influence and get an agreement which was not happening otherwise, but by showing a bunch of collections, how the APIs work, people really bought into the idea. So it helps me in storytelling, I don’t see it just like a tool to make some calls. And likewise, any new API that I have to use, the first thing I try to look for is, is there a Postman collection, because I know if I am able to find one it’s going to save me a lot of time. So I do spend quite a lot of time searching for a collection first, and only when I am sure that nobody has created it or I don’t have access to it is when I break my head on the other stuff. But it really saves me a lot of time, and finally it’s a lot of fun to work with Postman. So thank you for what you’re doing at Postman, it is really helping me and many others who use it on a day-to-day basis to get work done and have fun along the way, so thank you for that.

Well, it’s good to hear, thank you for the kind words. And regarding information sharing and helping new people understand the space, I hate to tell you, you’re the front line now too. That’s what this show is about, is reaching new people, sharing and getting them aware of what needs to happen, and this show is very much creating that next generation of API product managers, designers, architects, and they’re going to be learning from you. So now you’re part of that front line as well, so thank you.

I’m happy to share with others, again, learning that also from you, appreciate it.

Well, thank you so much for your time today.

Thanks for having me, it was a true pleasure talking to you.

Thanks again to Subbu for stopping by. You can find more about them on LinkedIn, and Citrix at citrix.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host, Kin Lane, and until next time, cheers.