Rosemary Missier, Samvit Software Solutions

Thank you for tuning in to today’s 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 Rosemary Missier. I learned a lot talking about the API lifecycle and governance with Rosemary, and I really enjoyed her flipping the tables on me and interviewing me for the remainder of the show. I always start with the basics: who are you and what do you do?

I’m Rosemary, and I’m from Melbourne, Australia. I work with Samvit, and I’ve been working in various different roles, but most recently I’m a PM consultant, but with a very strong technical background that goes down a decade. I love software engineering, still a software engineer at heart, but just trying to marry the engineering side and product world as well.

Yeah, so what does APIs mean in your world? How do you see the world of APIs?

Talking from my experience, it goes back to the days where I started off writing web services, and it’s just evolved. And today, I see it as two different things. There are companies that are API-driven, and there are companies where APIs are just part of their work. But I think it’s become like a password right now, where everyone has started looking into the values of APIs and trying to see how to monetize them, and how is it that we can share that knowledge across everyone where you have different platforms. So I guess we are still early days in the API journey, if I may say so.

Yeah, I would agree. I feel like, I always go back to the SOA, the service-oriented architecture days, web services, but I feel like the last 20 years have just kind of been practice for what’s coming up. I feel like now everyone’s awoke a little bit too to what the potential is. But I’m hearing a lot of people talk about, what’s come before is very IT-led, and what’s happening now needs to be product management, have more business stakeholders involved. Does that jive with how you see the world?

Yeah, I totally agree, but it depends on the organization as well. So I can say that when you are really venturing out into that API journey, it’s a different world. The business gets more involved rather than the engineering team, and then it’s altogether a different game, because you’re getting strategy, marketing, all the different stakeholders there, trying to have those partnerships. So you’re looking at it from a totally different angle rather than the actual product API itself. But there are places where that mindset is changing, you’re having that API-first mindset, and that’s completely changing as well. From day one you’re starting to work very closely with your third-party developers and partners and trying to work hand in glove with them and offer that support. So I think it’s depending on where you are in that API journey, I think you can say it is heavily IT-driven sometimes, and it is also the other way.

Yeah, I like that you use “API journey,” because I feel like this is one of the distinct characteristics that’s different. A lot of APIs I’ve seen over the years have been projects, kind of, once you’re done you check that box and like, we’re done, we did the API, and that’s not how modern APIs are done. They’re living, they’re evolving, they’re sustained in sustained mode, or you’re deprecating them and you’re constantly moving things forward. So it’s definitely a journey for people, and depending on the maturity, how they see the space, they’re going to see things differently.

So what’s the majority of APIs that you’ve worked with? Is it internal, is it partner, is it public, is it a mix of the three all working in concert?

I think I have touched, I would say, private, public, and hybrid. But just to go back to your previous point, sometimes with the private APIs you treat them as features, rather than as a product, and that’s where you get stuck, because sometimes they never get used, and you’re just rushing to get this API out for a particular partner which you do not see has value, and then you start trying to add more to it and it just goes nowhere. So from my experience with private, public, and hybrid, I would say the ways of working are very different. For public, you’d understand that as well, so you’ll have this larger ecosystem of partners, and my way of working with them is completely different as opposed to where you’re working, I’ve also worked just on private APIs where you’re just treating it as a project as well as a feature.

Yeah, right. I don’t know, but just to go back to your previous point, do you see a pattern where, with the project-related work that you’ve done, say on APIs, I’m sure you have done, where would you see that being treated as a project, on the private side, public, or is it a pattern right across the different APIs?

Yeah, I mean it depends on the organization. I’ve seen a lot of government agencies do public APIs that were very project-driven. They had a budget that was kind of finite, we did the thing, and then now, I’m hearing this phrase a lot, they’re zombie APIs, or zombie API portals. They’re there, but there’s nobody home, and if it goes down, it may not ever come back up. But then, I would say, if I had to say what’s the common, it’s people, it’s kind of a mix of maturity. From the inside out, as APIs begin, they begin as kind of microservices or just ad hoc APIs behind one mobile app or one web app or one system integration, and then it starts to get usage, it starts to get traction, and it’s maybe getting a little bit more budget, a larger team, it matures, it hardens, then it starts, hey, we have a partner who wants it, can we expose it to them, and then it becomes a partner program, emerges, maybe it gets hung in a portal. And so that kind of outward-facing maturity happens organically. But I think what a lot of companies I’m seeing are desiring is they want to strengthen that muscle and be able to do that confidently, like move an API from idea to public external exposure confidently, securely, safely, all of that.

And I think that’s exactly where product or business needs to step in, because when you’re starting in that idea journey, I think you need to see what is the value that you’re getting in that API. You might start off just as an internal API or another team in your company, but you just never know, you might start exposing the data to an internal team, but then over time you might start exposing that to one partner, and then that could change your whole world. You might stop, but then I’ve noticed that sometimes fundamental problems are, different stakeholders don’t get involved just when you’re starting to create internal APIs, and actually that’s the fundamental problem, because you need to start at that point in time, the thinking starts right now, before you end up in a way where you’re having throwaway APIs just because you haven’t thought. And I’ve been in situations like that where you haven’t thought that this could explode with time and you are going to have an ecosystem, but that’s when you’re starting to talk about, how am I going to handle this? I mean, it’s not the API portal alone, but you’ve got to look at the infrastructure, you’ve got to look at the security, you’ve got to look at everything. And so your whole approach to the problem changes, and that’s where you start looking at API as a product, because a product could be something that everyone could use over time, and it’s got to have a lifecycle, and the way that you work with various developers could also change.

Yeah, so I would say that reflects what I’m seeing, is enterprises wanting to get a more well-known, common API lifecycle across groups, so that’s something that’s repeatable, teams are kind of on the same page using the same vocabulary, tooling, contract-driven, Swagger, OpenAPI. But it’s still, in most times, like even the ones that are moving to design-first or any more advanced concepts, you say getting business stakeholders involved, they don’t speak Swagger, OpenAPI, they don’t speak JSON Schema for modeling. So how do you make this more inclusive to these business stakeholders?

Yeah, so I’d say you’re never going to be lucky having business people who speak technical jargon. I’ve been lucky that wherever I worked we’ve had like technical opinions, everyone is technical, but you never, I’ve been also in teams where you really do not understand the language and speak the language. And I think that’s where you’ve got to work as a triad, because you need a counterpart from engineering as well as the equivalent on the product or business side, because then you’re talking, even if you’re trying to draw up a contract, whether you use Swagger or anything, irrespective of the tooling, you’re speaking both languages there. And I think, I’ve worked with teams where both parties, so my team as well as the third-party developer, we ensure that our calls do have product as well as engineering, so we are able to throw in different ideas or different perspectives from both sides, and you’re getting everyone’s opinion at the end of the day. So it’s more agile, we try to do it more agile as well, so you keep these conversations going, and the product team can always step in while the engineering team is also helping business understand what is it that you’re trying to achieve with these endpoints. So it’s not just, you’re not just heavily IT-driven or business-driven at one point in time.

Yeah, and I think the more we expose business stakeholders to these processes, give them a voice in it, give them a seat at the table, hopefully those are diverse voices, those aren’t just people who are in alignment with IT or just white male. I would even throw out, throughout that, you know, we want to make sure it’s a diverse set of stakeholders at the table early on, be part of that feedback loop internally, but then once it’s opened up to consumers, that feedback loop extends the same way to consumers, and you’re gathering feedback, and that’s all a well-thought-out process.

Yeah, and I think that involvement of stakeholders needs to start early, because at every point in time you would need the relevant stakeholders. I’m not saying that you need to bring everyone in this journey, but I think when you start off you might need a particular set of stakeholders, maybe midway through you’ll need a different bunch. So I think sometimes I’ve noticed where we involve different stakeholders too late in the piece, so that is also a problem. It’s like, try to come out with who your stakeholders are right in the beginning, and figure out who is it, do I need to consult or inform or work very closely with. When you draw that out, you’re obviously going to be bringing in the diversity that we spoke about, you’re going to be more conscious who is going to be involved at what point in time, and then you’ll ensure that you’ve got not just different disciplines, but you’re talking about diversity and inclusion. That’s always challenging, but I think you need to take that effort early rather than just ticking the box last, at the very end, to say, hey, I’ve done my job.

Great. And I’m seeing a wider group of people involved. I mean, we have QA, we have security folks, so it’s definitely getting to be a larger group of stakeholders who are at the table, and depending on whether it’s public or partner, those things come in there. But I’m really seeing, there’s kind of a shift in power that I’ve seen since the SOA days. So I’m an old database guy, so COBOL databases to FoxPro to SQL Server, Microsoft, and that was my progression through the 80s and 90s, I’m dating myself now. But the database is always a power center in the enterprise. And what lit me up about APIs was, web services were exciting and interesting, but it was once you started seeing that usage of web APIs, of HTTP, and they weren’t really good APIs, they weren’t like the best designs, but they were scrappy web APIs out of social companies, and what Salesforce did and Amazon and eBay and all of these caught my attention, but it was exposing holes in this power center that was the database. And I feel like now it’s kind of becoming the gateway as well, the API gateway is taking over as this kind of power center where the value is transmitted or transacted. And are you seeing, when it comes to the gateways and API management, are you seeing a centralized, or are you seeing a more federated, multiple kind of gateway approach across these teams and stakeholders?

No, I think, once again I’d say it goes back to the maturity, because I’ve been in teams where you started on a very small scale, you do not want to invest in API management solutions, you start building out your small mini gateways internally, and you’re just trying out all that. Whereas there are organizations where they have a very big ecosystem, and so that’s when the federated and everything else falls in. So it’s going to be a mix, I’d say, but I wouldn’t say I’ve seen a pattern. But I think the more mature you are, you would start understanding the value in having, taking a federated approach, having an API management solution, a portal, the gateway. You start seeing through what benefits you’re getting from a security point of view, you’re also starting to see from an end-user point of view what is it that you’re giving the user, being your partner or developer as well. So you’re changing the whole scene here. Because I think that’s where I do not see companies or organizations investing a lot in these solutions, because they’re not seeing the big picture or the value that your partners would get. And that’s when you do not, like I worked with teams which just went on without any API portals for a long time. And that’s hard. It gets to a point where you’re trying to actually do everything in-house, and then you’re starting to see a massive interest in these endpoints and APIs that you’ve built, and then you’re going back trying to then start thinking about, what is it that I can do with my current system, do I need to start investing now? I think it depends on the maturity. I don’t know, what would you say? Is there a pattern, now that you’ve spoken about the world of databases that you’ve worked in? I’m sure you may have seen a different trend with different types of organizations.

I mean, there’s a couple things in what you just said I would say are fairly common to what I’m seeing, but I want to make sure I got it right. So you’re saying there has to be this kind of consumer balance to what’s happening via the portal and via these API management, to offset the kind of producer, like you have to invest in a portal and become more mature and have up-to-date docs and have a feedback loop with your consumers and keep them updated, and have a balance with the consumer side of things, otherwise it won’t work. Was that kind of what you’re saying in there?

I’m saying, you’re partially right, have a balance, but I’m not saying invest, because when you’re still trying out, when you’re starting, you definitely wouldn’t want, business would never invest in an API management solution or a portal, or investing with great docs and all that. But have, give a thought to it, because now you’ll probably want, it’s like a black box that you’re working with. So think from a developer and user point of view, how is it that you can give them the docs, give them the logs, give them the keys, the tokens, everything, without the solution? Because if you do not think, you are going to bump into problems, especially where I work with teams which are risk and compliance, you’ve got to think, because you’re not investing in these solutions early days when you’re experimenting. So the balance has to be there, but you do not have to do it with sophisticated tools right from the beginning, but a thought has to be given. Once you’ve got to a stage where you’ve done your POCs and everything, you know that this is definitely got a value prop to it, you definitely need to start thinking about what would happen in a few years’ time. So I think that’s where, going back to our first point, getting your architect, your engineering team, and product is key, because what could start as a one-day, you know, Friday project could end up changing your whole API scene.

Yeah, no, that makes sense. And I would say, back to what I was saying as far as some of the common aspects of what you’re saying, what I see is, I see people who don’t have a portal, I see the whole mix, API-early as we would call them in the journey, and then once they start becoming more API-aware, they hopefully have a strategy in place, as you said, and then they start investing in more tooling. But even the ones who have a portal, on public or privately, there’s, back to the zombie API portal, it’s not always up to date, the most common thing I’m seeing is it just doesn’t keep pace with the pace of change within the enterprise, and/or there’s no incentive for people to publish metadata about APIs to make it accessible. And so I was just writing a list from this week of other conversations I had where people were asking, well, we just want our gateway logs to tell us what APIs all exist out there and give us an accurate snapshot, because we don’t know.

Yeah, I would say sometimes the composition of our teams is a problem. And I can see some data-driven companies doing this differently. I think it starts with us, because we’ve got to start thinking how we can leverage the data that we are collecting, because then you flip the coin and say, okay, this is something that your external developers would need too. So when I mention about composition, sometimes you need a data analyst or someone to sit in the team, if your product person or anyone else who’s wearing a different hat in the team is not able to think about that, because sometimes we slip, we’ve got to start thinking about how is this data going to be of value to our partners and our ecosystem. Because we all know APIs are a black box, it’s there, it’s very easy to use, but beneath it they don’t know how we implement it, but there’s a lot that we need to do, and the only common language that we speak between these two different types of software, if I may say, is this API language, and all that we can get out of it is the logs. But if you’re not thinking about what is it that the logs are giving, it’s ultimately data, we then start to take a step back and see that right throughout the development phase, how is it that we’re going to start using the data? So sometimes when I work with my teams, what I tend to do, and this happens closely very much in the finance industry, is we definitely need to audit and keep track of the data that we have because of the security and various compliance standards that are in place. And so for us, we start looking at data governance, data controls, everything, and so we start looking at what is it that is there in the logs for it, and those conversations start happening with our partners too. That’s actually our starting point for any organization that we have, is data for us. Because for fintech, there is never a second chance. What happens if you start divulging all your sensitive data? What happens if your logs are going to have all this data? So those conversations happen early, depending on the industry. Some industries where data isn’t as sensitive as, say, fintech, I’ve seen that they’re more lax, they’re not as concerned, and so it’s typically the example that you mentioned, it just sits there, doing nothing.

So shifting gears to the financial space and the role of fintech and APIs and kind of changing this monolithic industry, what are the real, honest, no-BS motivations of the C-suite for a financial company, a large bank, an HSBC, to make a go, API-first, to make API change? Is it that, is it a regulatory argument, is it a competitive, profit-driven, what’s truly going to motivate them to do APIs well?

I think it’s the security risk that comes with it, and the standards that they’ll have to adhere to, which come from different regulatory bodies. I think it’s mainly compliance, which is why I think there is, they’ve started, but there’s hesitancy. And I think different countries are mature in their own different ways, but I think the pattern across all is, you’ve got various standards set by different regulatory bodies, which means, okay, they’ll start saying the information has to be encrypted, you can’t send this type of a field, you’ve got to remove certain fields which cannot be exposed, and then that changes the whole product and business conversation. Because a use case is invalid if you do not send this information, why aren’t you sending this information, that information is too sensitive because this regulatory body has a problem saving it. And I think that’s the fundamental problem, because you’ve got to, you can’t have one set standard, but you have different standards that you need to adhere to, and there’s that continual check that you need to do, which slows us down a lot in fintech. But that being said, we can’t get away with it. So steps are being taken, controls are being put in place, standards are being set, but I think it is slow. We are getting there, but I think it is very slow. It can be a long time before that category of companies would call themselves as API-first, mainly because of the regulations and the compliance that they’ll have to adhere to.

Yeah, I think it’s interesting to watch European regulation kind of set the tone and then have it echo out across the world, so Hong Kong, Australia, Brazil, others are emulating it. I think the US is doing its best job to act like it might be, could be, should be, but then we’re not, so we’re doing regulatory theater I think right now when it comes to it. But it’s interesting to watch how each country or region pays attention and starts doing things.

I’ll definitely agree there. I was lucky enough to work across different countries, and I’ve also got a chance to work with a few folks from Hong Kong, and I noticed the pattern there, they are running at a faster pace than certain other countries. I don’t know whether the regulatory bodies are more stringent in trying to get things done quickly. And because sometimes I’ve noticed for Australia, the places that I have worked with, we do have set standards, but sometimes you get caught up in the process, and that’s what takes us time. So it’s a combination of different factors. It’s probably, okay, in the USA, it must be a different, I’d probably like to hear, what is the reason that you see the US different from other countries? Is it that you do have more stringent requirements, is it the complexity in the fintech world, what would you say?

Ideology. It’s how America views regulations. If you’re, I mean, the conservative view of regulations, it’s a bad thing, and that’s the default stance, regulations are bad. But if you at all work with business, regulations are good, and a lot of enterprise organizations depend on regulations propping up their industries. And regulation comes in a lot of shapes and sizes. There’s the privacy aspect of regulations, so GDPR and CCPA, California is leading that, so there’s the interoperability and standards and reuse part of regulation, there’s the privacy, and then there’s the, I would call it the automation of regulation, or deregulation. I worked on regulations.gov for the US government, and so it’s, how do you automate the informing and reporting of regulations, so it’s automated using APIs. So those are the three spheres that I see regulation playing out, and the US is just unique in our view. Well, maybe not unique, but we’re special in our view of hating regulations and just believing it’s bad, but it’s kind of theater, it’s not real. I don’t know, it’s weird.

So on that, I’d like to understand, from the stakeholder point of view, going back to where we started, we were talking about APIs being IT-driven, where would the balance be, talking about that, still in the fintech space?

Yeah, I mean, my view of APIs, and this isn’t limited to financial, is there’s a Venn diagram of three circles: the technology of APIs, the business of APIs, and then the politics of APIs. And I don’t care how good your API design is, hypermedia, perfect, whatever, if you don’t have a business model, if you can’t pay for it, it doesn’t matter. And then I don’t care how much money you’re making or whatever, I’ve seen, you know, the Twitter API has been the politics of it and rate limits, Facebook being investigated by the FTC right now for anti-competitive practices in their ecosystem, because once they bought Instagram they started throttling and giving elevated error rates to the other image applications via their API. And so you start seeing those games playing. And so when it comes to financial, you see it with PSD2 rollout, well, hey, yeah, we’re PSD2 compliant, but you can’t find the documentation or figure out how to onboard, it’s like really weird things like that. So I say politics, but it’s the games people play, because I saw the potential of APIs early on, and a lot of people say, yeah, we like APIs and we like interoperability, but the first lesson I learned is, no, not everyone actually truly wants interoperability, they want lock-in. And so it’s an interesting game to try to understand.

So when you say not everyone likes, what is the fundamental reason? Is it like a lack of knowledge on the potential that APIs bring, or is it, we’re not looking at the short term and the long term, really just looking, caught up with the problem and not seeing the future? What would you say is the reason?

I mean, I would say all of the above across that. But I would say first and foremost people don’t understand. A lot of people just think, oh, if it’s a public API, making it publicly available, I’m giving something away, I’m giving away unfettered access to all my digital resources and capabilities. And then but, in the same motion, the same companies will be like, well, we don’t have any public APIs because of this reason, and then I can proxy and show them a list of all the APIs behind their mobile applications and web applications and everything, and they think those are somehow private APIs, and so they don’t understand the mechanisms of API management and a known lifecycle and a kind of producer-consumer relationship, and the value of feedback loops, how much control you have over authentication and access control, they don’t understand all of that. So you see it as, back to the database-to-gateway analogy that I said earlier, this shift in power, they see gateways as a threat, they’re giving away something, or they’re not going to make money off of it, and they don’t see the potential.

So is there something that technical teams or engineering teams could do, or would you say it’s the composition of the teams that is adding to the problem? Should we have a balance to, like, how do we get about getting this knowledge out there?

Yeah, I mean, that’s our challenge. It depends on the culture, it depends on the organization, the industry, how much lock-in there is, how much, it just really depends. Because some industries, I’ve seen top-down, CIO saying, hey, do API-first, here’s all the learning, the knowledge, the education you need, the tools, we’re going to enable you to do the right thing, and that just works, I’ve seen that happen. And then everyone on the ground floor go, no way, we’re not doing that, that’s dumb, we’re not going to do APIs. But then I’ve seen amazing bottom-up, organic, engineer-led champions going, hey, let’s get an API lifecycle that’s known, let’s advocate and evangelize, let’s start a center of excellence, and let’s come up with standards and all use the same version of OpenAPI instead of Swagger, and have contracts and share tests and have hackathons and stuff like that. So it’s a mix, but it really takes evangelism. I mean, this is, I’m the API Evangelist, I’m the chief evangelist, it takes evangelizing, that’s my belief system.

Yes. And would you say to your role that it should start, would you advise starting, say, internally? Because sometimes I’ve noticed that, you’re talking about internal APIs, and some teams are great at it, but some teams aren’t even aware that we should be thinking about APIs for everything. So where would, as an evangelist, what would you do to ensure that it starts first with our own team, our own company?

Yeah, start internal, start small, get little wins. But API-first for me isn’t just about producing APIs, it’s about consuming APIs. And one easy one there is, before you buy any new software or anything, you make sure it has an API first, and then use that API to automate and make sure you’re not locked into that vendor. That’s like a business-level, API-first capability. But yeah, start internally, start small, because the ugliest messes I’ve ever seen are companies who haven’t really dealt with all their internal baggage and politics and drama, and then start opening up public APIs, and kind of open up the curtain to the audience a little bit faster than it probably should be, and they weren’t quite ready, and that can hurt, that can scare people away from doing it anymore, so you’ve got to be careful.

Yeah, that becomes a problem. I’ve been with teams where you end up in situations like that, and the example where I mentioned, saying that you had, and I had like a situation where our partners exploded in terms of numbers, now that’s where I see there’s a fundamental problem, where it should have started internally before you start thinking of exposing publicly. But something that I wanted to go back to, another point that you spoke about, you mentioned one of the problems as discoverability.

Yeah, nobody knows where their APIs are. I don’t care who you are, every enterprise organization, every startup, nobody knows where all their APIs are. I’ve done all-day consultant sessions with the Internal Revenue Service in the United States, the IRS, about their internal API strategy, nothing to do with their public, and they don’t know where any of their APIs are. They admittedly have problems with hoarding. So when, another project I worked on, this is very common in federal agencies, I worked for the Obama administration going around to federal agencies getting them to open up their public data assets in a machine-readable way, that was the mandate that I worked on. And I was at the VA doing web service inventory, so finding WSDLs is all that I did, like four days out of the week, where are the WSDLs? And so you go around the Department of Veterans Affairs looking for WSDLs, and who’s got all the, no one knows where WSDLs are except for Deloitte, the Deloitte staffer, all the contracting firms know where the WSDLs are, and they have a catalog, and nowhere, because, so it’s hoarding, it’s digital hoarding. And you see that in web service environments within large enterprise organizations where budgets are associated with, in the VA, if you have the authoritative record for the veteran, you’re given a lion’s share of the budget, so of course everyone has an authoritative record for the veteran, and so everyone kind of defends their world like that. So access to data, there’s just a lot of illnesses that exist across organizations. And then there’s organizations who don’t have these illnesses, I’ve seen groups, I’ve had conversations where they, you know, 100-year-old company modernizes their legacy infrastructure within like five years and they’re running in the cloud and they’re elastic and they’re API-first, they still have issues but they don’t have all that legacy baggage.

So, okay, so what would we say is the problem? Is it that product and engineering teams need to think about, say, maintenance as part of, you know, we’ve been done with our product development, that’s it? You’re referring product as APIs, but are you thinking that we should be looking at maintenance as well, where, you spoke about hoarding, is it like an accumulation due to legacy stuff, or is it something that just done without putting too much thought into it, and we have never been looking at it as a cleanup work, or text it, or anything? Is that the reason? Is it that you’ve done, written your API, you’ve done everything and done, handover, finish, but we never go back and look at it as part of the maintenance phase?

Yeah, interesting question. There’s a lot going on in there. I would say that project-based mentality that we talked about earlier, check box, done, that’s why the people who did the projects or had the contracts know where the WSDLs are. So there’s a whole mix, but I would say we have a lot of unhealthy relationships with legacy technology in the space, and not all legacy is bad. If you think about the notion of the word legacy, like legacy doesn’t always mean that, like your legacy on this earth or whatever. So when you work in an organization, you do the legacy work, it’s not as cool, it’s not as sexy, it doesn’t get as much budget, you want to do the front, there’s something about that. But some of these systems don’t need to go away, some of them need to go away, and that process just needs to be healthier and more balanced, and have these feedback loops and these cycles, because sometimes this stuff is important, legacy is meaningful, we should keep it around and it works. I mean, if you look at like the unemployment system in the US when COVID hit, they had a big, oh no, what are we going to do, this is all written in COBOL and uses IBM mainframes, and they just ended up training a bunch of young kids on how to do IBM mainframes in COBOL rather than rewriting it in Node.js and microservices, because it’s what needed to happen. So I think there’s a lot of unhealthy views of how and why we do technology, and it’s just all in this big ball of yarn that we call the enterprise.

On that note, I think I’d like to take it really tactical. What do you think we should do? Should it start right at the bottom from the engineers where we build up a backlog of all this work and say start from there, or should it be from the top where we need to start educating everyone as to, it’s not a handover, it’s not a project, because it ultimately goes down to your API strategy, or should it start from the bottom?

I mean, it depends, and it’s both. But I would say leadership, especially in large enterprise organizations and government agencies and higher ed institutions, they have to think longer term. And I think there’s competing incentive models and reward systems in place within enterprises that reward short-term thinking at leadership levels that aren’t always in alignment with the business or the industry or what’s needed, and that’s why you end up with this ball of yarn that’s twisted, because of that imbalance that exists. So you’ve got to have longer-term thinking. Back to the government example, when I worked in the government, people ask me, are you a GS person, are you staff or are you contractor, or are you like a political staffer? Because you’re political staff for two years or four years, if you’re a government employee you’re there longer, if you’re a contractor you’re there for a fixed period of time and then you’re gone, and there’s not a lot of knowledge transfer, capacity transfer, you’re just there one day and you’re gone. And I saw whole wings of offices just gone one day and empty for like a week and then filled with new bodies. And so this kind of long-term capacity and capacity building internally, like, who knows how these services work, they’re not documented, they’re WSDLs, how do you find them, how do you sniff them out, how do you understand how this works, it’s working and it supports all these systems, how do we not break that? There’s just a lot of knowledge that needs to be shared, and it’s not always properly incentivized to be shared. So it’s got to start top-down and have that long-term thinking, or build a system for short-term thinking. If you’re just a pump-and-dump scheme for a stock, then build APIs accordingly. But do it appropriately. So yeah, I guess it just comes down to, what is it that is really the vision for your company, and I think that would dictate what the strategy is and the ways of working with APIs.

Yeah, otherwise you just go down the project route.

Yeah. And so strategy, you kept saying, you’ve got to, it’s got to be done strategically, it’s got to be done more honestly. I don’t think there’s a lot of honesty in the API lifecycle in some organizations, and in others there’s a lot, and it pays off.

Well, we’re at 45 minutes, so this is much longer than most of the podcasts go, but it’s been great having you ask me questions, because I love, somewhere around 26, 27 minutes you started slowly asking me all the questions, and that’s funny, I like that.

It’s great. Thank you, it’s nice chatting with you, because you’ve got a wealth of knowledge behind you, and it’s a nice combination, because I come with product and engineering, whereas you, yeah, you’re an evangelist, it’s good to get different opinions.

Yeah, I sat down, I was telling Latoya, my show partner in crime here, this weekend I had the first time to kind of sit down and absorb all these conversations I’m having across Breaking Changes. So I have like four or five Breaking Changes episodes a week that I’m recording, kind of building out an inventory, I have four or five enterprise customer conversations as part of my job, and just every week I have these conversations, I learn so much, and I don’t always have time to absorb it. And so going back and breaking this, the great thing about Breaking Changes is these are recorded, there’s a show transcript, and then I’m able to go back and reread it, I write a blog post when it comes out, so I do have that time to absorb it and my conversations with amazing, smart people like you. So thank you.

Thank you so much for having me.

Yeah, no, this has been great, thanks for coming, and this has been good, I learned a lot. Thank you.

Likewise, thanks.

Thanks again to Rosemary for stopping by. For more about Rosemary, you can find her on LinkedIn. 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.