Unifying the Development and Management of APIs with SmartBear’s Dan Faulkner

This is Techron tv. Hey guys, thanks for the throw. We're here with Dan Faulkner, who's the newly appointed CEO for SmartBear, and we're talking about, well, where is API design management observability and all that stuff headed from here.

Dan, welcome to the show. Thanks, Mike. Nice, uh, nice to be here.

One of the things about APIs, I think we can all agree is that it's pretty much become the foundation upon which anything good happens in the world of IT and the web these days, but it's also simultaneously become arguably too much of a good thing. So how do we kind of cope with all the APIs that are out there these days and how should people be thinking about how to, uh, not only build and deploy these things, but live with them after they've been built and deployed? No, it's a great question and um, it's obviously something that's top of mind for, uh, smart Bear.

Uh, we, in fact, just, I was gonna say this month, but it was, we're just in February. So last month launched our API hub, which is designed to address exactly that question. Um, so at Smart Bear, we have had, uh, a number of kind of the blue chip API assets, uh, in our portfolio for a while, um, building on top of the open source assets like swagger and spectral.

Um, and we have an open core product, so a commercial layer that sits on top of those open source assets. So you can just pull all of your open source goodness into, um, a more fully featured, more commercially featured product, if that's what you choose to do. And, uh, to your point, one of the biggest issues that we hear from our customers is API sprawl.

How do I manage them? How do I control all of these APIs that are out there in my network? Uh, so that's very much the challenge that we're trying to solve.

We've also seen the rise of all these generative AI services. Has that shown a spotlight more on the critical role these APIs play because, uh, there's efforts to standardize some of those interfaces and there's just a lot more concern about what data's going out over those things. So are we seeing a little more focus on security as well?

Yeah, absolutely. And APIs are the most natural, um, interface for LLMs to work with. Um, and what we're seeing with some of the, the very recent, um, capabilities that have come out is that they kinda look like web crawl as they're sort of working directly with the same interface that humans work with, and that can start to look and feel very insecure.

In fact, it might be perceived as a security attack. So I think we're gonna see a huge amount of focus on enabling all LLM systems to interface at the, at the API layer. It's more secure, it's more efficient, um, and there's no reason to have LLMs and generative AI systems messing around with a, a GUI that was built for humans.

So you're the new CEO that buck stops with you, as they say. Um, before everybody starts calling you up and they put you on calls like this, what are your priorities? What's the thing you're thinking about or the couple of things that you really want to get done in 2025?

Yeah, I mean, so there's kind of the internal push and then there's obviously responding to what's going on in the market. Uh, I think that's what every CEO needs to be doing is, is thinking sort of about the business that's right in front of you now that you have to prosecute, and then the business that's slightly further out. And so right in front of us, you know, we, we've just done two of the most important product launches that we've done in the company's history of API hub and insight hub, our developer focused observability platform.

We're integrating, um, uh, an acquired company. Uh, we acquired QMetry at the end of last year. That's another test management and test automation company that we've brought into our portfolio.

Uh, and then later this year we'll be launching our testing hub. So really three key platforms that really simplify our portfolio and bring together the best of everything that we have into, uh, clusters of that are coherent for our end users. From an external perspective, obviously we're seeing just a huge acceleration in the capabilities of generative ai and most of our customers view that both as an opportunity, uh, and, and a threat, uh, or, or I should say, and something maybe slightly daunting or, or, or some of 'em are slightly fearful, particularly the customers who operate in the more regulated industries.

And I think one thing that Smart Bear has always done well to quite a pretty well, well known phrase, meet them where they are. So we intentionally design, um, AI capabilities into our products in such a way that they're optional if you are a company that doesn't feel comfortable using them yet. Um, but if you are, then we are right on the bleeding edge with kind of agentic capabilities built into a number of our testing products, like reflect.

So, so wherever you fall on that spectrum of your willingness to adopt AI and and to adopt it, um, you know, to a greater or lesser extent, our goal is to be able to help you. But we will always, always be right on the bleeding edge of what's possible because I think that's our responsibility to our customers. As you kind of ponder all this, one of the conversations at least that, um, I'm encountering a lot of is people are trying to figure out, well, where does API development and deployment fit within the larger contacts, though a larger context of a software development lifecycle?

And they have DevOps workflows and they're trying to understand, uh, you know, clearly developers are creating the APIs, but how does that get inserted into the rest of the application development workflow? Yeah, so, um, our recommendation, um, is that the best way to start is with the design. Um, and you can kind of think of a parallel between, you know, the API and the application, the API, if you think of it as a product, you design it before you start building it.

Um, and then what we're trying to do with API hub is create a very natural lifecycle or pathway for that API to be iterated upon and published and shared by the people who've designed it and then seamlessly, um, consumed. So for the people who want to take that API and build its functionality into their programs, they need a storefront where they can learn about it. They need to be able to explore the API test it in the multiple different ways.

Um, you know, performance, functionality, contract testing to make sure that it's gonna work well in their application. And you are right, they're different stakeholders. You might have a developer designing it, you might have a product manager or a tech tech doc, uh, author doing the documentation.

You'll have a different developer or a set of developers consuming the API. And so what we try and do is integrate all of those experiences so that if one person changes a key piece of information, all the other stakeholders become aware of it automatically. And, and we, we make sure there's no kind of hidden errors that get built into that system.

So you can design it, version it, govern it, and then at the right time, retire it when you want to. Not all APIs are created equal though. And what's your sense of how many of them are what we might refer to as internal facing versus external facing, and do those different types of APIs require a different level of robustness or functionality?

How do I kind of navigate that? To me, it's less about whether they're internal or external and um, it's more about, um, the requirements of the environment that the API is being deployed into. So I'll give you an example where you would have the most rigorous requirements, um, all the way now a a as rigorous as any external facing API would be, um, you know, critical, um, trading technology APIs used within a bank, um, used within an investment bank, even if they're internally facing, those are going to have incredibly high security requirements, audit trails.

They have to be impeccably, versioned, documented and governed. Um, and of course they're gonna need to be among the ro most robust products that that bank is deploying. So they need to be very well designed and incredibly well documented.

So the internal external to me is less of the dimension. It's more about who are the end users, what is the environment that this API is going to live in and be deployed in First. We hear phrases like rogue APIs and zombie APIs all the time, and you know, they bring visual images to people's minds, but how big a problem are those things these days and are we getting a better handle on it?

Um, it's a pretty common concern, particularly of larger organizations is, um, they may just not even have a, a, a full sense of all the APIs that are deployed within their environment. Um, and that may seem shocking, but if you think about some complex environments where they're running multiple gateways, um, and maybe each of those gateways has their own niche bit of API management attached to them, for them to actually get a centralized view of all the APIs that are running across all of those gateways, let alone the APIs that aren't running through gateways. There's, there's still about 40% of the market that doesn't use gateways at all.

So you could have multiple gateways and APIs that aren't running through gateways all kind of live in the same environment. Um, so getting those under control is, is critically important. And uh, obviously that's a big part of what we're trying to solve with the API Out.

So when you visit organizations, what do you see the ones who are doing it well, what are they doing that you kind of wish everybody else would kinda, uh, think through and maybe follow the same playbook? We don't have much time, so I'm gonna hit the headlines, but, um, for me it's, uh, we are really huge proponents of a design first approach. Um, those will give you less headaches over time.

It's like, it's, it's kind of a measure twice cut once mentality to API development versus just jumping in with the coding and then trying to retrofit, um, an open API spec to it. Uh, you will end up with something that is less well formed and more prone to error, um, over time. But on a, on a macro scale, I think it's really important to be mindful about the separation of concerns that you want to have.

Um, we are proponents of the position that the likes of Gartner have taken where we need to start to unbundle things that have previously been viewed as bundled in the API stack. And we believe that API lifecycle management should stand on its own. The, the governance, cataloging design, um, testing documentation of the APIs should be normalized, however many gateways you are running from many to zero.

Um, and I think the more organizations can embrace those kind of good practices for sort of a, not just an individual healthy API, but the keeping their collection, their catalog of APIs healthy, um, the, the more, the better they're gonna be able to sleep at night, the faster they're gonna be able to move. Are organizations getting better at thinking of APIs almost as standalone products versus seems to me there's still a tendency to think of them as an afterthought. I built my software so therefore I should go build an API.

Yeah, it, there's definitely a portion of the market that still does that. And uh, as with all things though, there we're, we're on a technology adoption lifecycle, you will have people who embrace the new, uh, very early on. Um, and uh, you know, even even with things like this, you, the idea needs to kind of cross the chasm to hit the early and late majorities.

And I think that we, um, and we've maybe kind of crossed the chasm with the idea of API as product. I think it's really starting to gain more traction. Um, but it's taken, it's taken time Here.

No matter how great your application is, if the API is a suboptimal experience is not a great application. And damn, thanks for being on the show. It's my pleasure.

Thanks mate. All right. And back to you guys in the studio.