API Evangelist Conversation with Claire Barrett, Digital Strategist at APIsFirst

Hi, Akin. I’m Claire Barrett.I’m joining from the UK. Lovely to be here today with you.

Yeah, so I, I, um, I would call myself a consultant, first and foremost. I run a consulting business, APIs First, based out of here in the UK. And I also co founded the API Collective with Mariuk and Inyoha, another co founder. Uh, of your, uh, your peer group in the, the API think, think space. Um, I am a connector. So I help, um, people who are trying to execute API enabled change, understand and connect with the strategies. are often going on in kind of wider environment, but I also help those strategists actually understand what’s involved, um, and how they can connect with the people who are doing the work on the ground. And the third thing I do is, uh, I’m involved in community building and particularly I lead a women in APIs community, uh, which now has representation in 45 countries.

Yeah, so what we were hearing were a lot, a lot of consistent, um, questions and conversations coming back from particularly large and larger organizations, which tends to be the space that I’ve either been working at, consulted, been consulted to or consulted to. At, um, and you know, in incumbent industries and people were saying, we’ve actually been investing in and around the API space in tooling and, and capabilities and frameworks and management systems. We’re not seeing or feeling that we’re getting the return on the promise. of the big bold, you know, participation in the API economy, um, uh, revenue returns from monetized APIs, um, except for things that, or even efficiencies in the speeding up of, of, of IT enabled change, which you would expect from your kind of composable architecture, um, you know, view. So, so what I, um, prepared was, was my take on this. And, uh, probably two things that, that are kind of important to, to bear in mind in this, how do, how do we get value from this API investment? The first is to understand the difference between what could be directly attributed to having API enabled capabilities. And it’s not often actually directly on the bottom line. And that’s one of the problems is that people have promised too much of what should be the commercial case, the technology case, et cetera. Um, so, so there [00:05:00] is, there is, so, so I talk about the difference between direct and indirect benefits. that you can attribute to having these kinds of platforms enable, enabling capabilities that are typically enterprise wide or, um, that will support business and tech strategies. So business strategies to, um, terrorize, to, um, to, to, to move into new territories, um, to make, you know, operations more efficient, to, then you might have technology strategies around it. Yeah, simpler architectures, faster, faster flow of change. Um, you know, uh, quicker adoption of new things, et cetera. So, so that’s the first thing is direct and indirect methods. And the second is Some common ingredients that you need to have right. I call them like five key themes that organizations need to get behind in order to deliver on this bigger promise [00:06:00] of the A. P. I. Agenda, if you like. And so I go into each of those.

So I don’t attribute it to any one group of people or any one particular discipline more than the others. I think of it more as some mindset shifts that you need to collectively have as a, as an organization or as a, um, a participant in call it the API economy That that if you kind of get it at that level and there I suggested five things. So the first is um, understanding engineers as customers so for an incumbent industry that is used to thinking of customers as even if it’s [00:08:00] another business, and ultimately it’s a you or I. If it’s not B to C, it’s a B to B to B to B to eventually a C person somewhere. And the business models and thing, the commercial models for those organizations are built on, might have once been physical products, it can now be You know, screen data or it can be, you know, distributed, but it’s, it’s physical products rather than what the software tech industry thinks of as a digital product. So if for people trying to justify investment in these more incumbent industries, that if you’re not, if you’re suggesting that your API product Is something that people are going to want to buy those people are need to be able to engage as as engineers or people who Influence engineers coming to use your api that is very different than if your Customer base is the customer base your traditional. So when you’re trying to look at the business case for investing it You’re not necessarily comparing [00:09:00] like with like. Am I making sense on that one? So engineers as customers. Second is designing APIs as products. And, uh, this is obviously something that you’re, you’re, um, you know, very attuned to and those of us that are in the space understanding that, um, uh, APIs are not just a better way to integrate. They’re not just, um, uh, you know, for, again, for incumbent organizations. Thank you. They don’t have the right funding models, if they don’t have the right incentives, motivated innovations for people to design APIs for many people to consume internally or externally. And they’re really thinking about who that customer might be and applying some design thinking early, then they’re not taking advantage of the API opportunities.

So, um, so I think of, um, so but I should actually say sorry, by the way, the third one of the other themes that we’ve got is that we think of API design as a team sport. So exactly what you’re talking about with, you know, this is technologists needing to, you know, be thinking about the [00:11:00] opportunities of data that they can unlock from existing systems or new ways of being able to present and to be able to think about how somebody might consume those in, in, you know, in co, in co, um, collaboration with, uh, the, um, you know, maybe potentially more commercially minded or more delivery minded or more customer. tuned, uh, um, or partner tuned colleagues, um, who are representing call it the business. I mean, you could argue, everybody’s been part of the business. If you’re thinking about APIs as products become digital products that are part of your catalog. So, so I, I, to be honest, don’t try and get too hung up on being too precise about the definition because one can end up in a sort of big title of taxonomy. It’s more to me, a philosophy of thinking about, and certainly the organizations that we tend, that I tend to work with, uh, they, they don’t get the value that they’re hoping from their API. [00:12:00] Programs or their API investments when they think when they still think of APIs as an interface, just a different type of interface. So that’s why we call about, you know, thinking about an API as being consumed by, I always use Mike Amundsen to consume, you’re thinking of something to be consumed by a customer you’ve never met to be used in a way you could never have imagined. That is a very different headspace for people to be thinking about. Then I have a business requirement that comes from a customer that says, I need these particular features on a physical product or, um, you know, an existing known product. If that makes it a non API product.

So firstly, there aren’t one or two things. that are generic across industries. What, what, if you want to catch the eye, you know, and the attention of people, it’s about where are they at, at that point in time, what is, what are the strategic priorities for them from a business perspective and potentially from, and also in, in, in, in, in balance from a technology of inefficiencies. So they are on a An efficiency drive and a, um, you know, uh, a, um, a cost productivity focus. Are they on a, um, uh, you know, more of a growth kind of focus? Are they looking to, um, uh, build tighter, different, you know, different distribution channels through different business partners? What, you know, what, what is there, what are they really trying to achieve that’s the priority at the moment? So what we’re often talking [00:15:00] about is building API capability that lasts beyond the next planning cycles. Um, and, but making sure that what you’re doing and focused on for that, you know, quarter or for that, um, you know, uh, next short horizon is well connected to what the organization’s priorities are at that point in time. And there’s no, there isn’t a black or white on that because What’s more important is that you have a way of finding it and applying your next API priority to that, solving that problem.

Yeah, I mean, I think, uh, you know, there’s, this is kind of the reality of living in, if you’re working in a large organization, which, which partners and works with many other large organizations and large numbers of people, there is naturally going to be lots of different people’s views on even things like, you know, the common terms and so on. So I, I think there, I don’t think there is one size fits all. What I think is there’s the right size for that point in time for that particular group and community. I think if you go to, so often people, you know, frameworks and simple structures and common terms are really, really helpful. They, as long as everybody is using them the same way, I have never worked on a project, almost any industry of, of, you know, of where [00:17:00] people use the same words, all constantly the same way. So, it doesn’t matter what kind of project I’m on, I’m always, always, will start with a taxonomy. Because, and it’ll be, well, at least for the context of what we’re going to be doing for the next, you know, few weeks or months, let’s all agree that this is how we’re going to use it. And often people actually really value the fact that you’ve written down, and it’s the most used terms, That you actually need to spend the most time on. So today, you know, it’s a product or it’s platform or it’s um, you know stream or service or I mean all of them could be so widely used. It’s like well at least for this context, let’s use it this way um, so I find find that it’s just kind of a 101 consulting thing, but uh, I don’t get too tied up when this is this is what’s right for us because you’ll find every organization has their own nuanced um use of things you just say, okay, all right now I see you’re using it that way. All right, let’s, let’s make sure that you realize that if you were going to other industries or if you were talking [00:18:00] to employing new people from a different, um, uh, who’ve also worked in this space, they might not see that term that way because they follow, you know, people like Kin and the API evangelist who would, who would tend to have a much clearer definition of how to use some of these terms.