S4 Ep2: Unlocking Developer Velocity: API Design & Blackbird
About
Episode Guests
We’re kicking off this season just after of the GA launch of our new API development platform Blackbird. In honor of the occasion, I had the pleasure of guest-hosting a very special guest for this episode about boosting developer velocity: API Design & Blackbird
I sat down with James Higginbotham, founder of Launch Any, author of API Developer Weekly, well-known API expert consultant, and all-around great guy (from what I can tell). We sought James out to be one of the first to test Blackbird and provide valuable feedback. He’s explored it through the lens of his widely-respected approach to helping companies craft and maintain good APIs: ADDR (Align, Define, API Design, Refine).
Transcript
01:15.39
Steve Rodda
All right. Welcome back to API intersection. I'm the guest host today, Steve Rada. Um, and I'm here with James Higginbotham. I see you again.
01:25.44
James Higginbotham
Hey, Steve. Yeah, good to see you.
01:27.01
Steve Rodda
Yep. So we got a, why don't we start with a brief introduction of yourself and then we'll dive right into the questions.
01:34.56
James Higginbotham
Sounds great. Yeah, ah James Higginbotham. I'm the founder of Launch Any. We're a ah consulting company that focuses on APIs, everything APIs. So a lot of what we do is help to establish, grow, and mature API programs. ah We work with mature startups,
01:53.72
James Higginbotham
that are looking at their growth. They have product market fit and they're looking to grow their API programs. We also work with a lot of enterprises as well globally to help them get their API program off the ground and focus on maybe establishing API platforms as well. So do a lot of that. I've written a book called the Principles of Web API Design with Addison Wesley. and That's part of the Von Vernon Signature Series ah in the Pearson, with Pearson Publishing.
02:24.27
James Higginbotham
And, and then I do a lot of writing and other things as well.
02:28.66
Steve Rodda
I'm a busy guy.
02:30.16
James Higginbotham
Yes.
02:31.72
Steve Rodda
That's good. Great. So well why don't we why we just get started here with you know what kind of trends or shifts have you seen in the API industry, i'm given that you're so involved in it and have your hands all over it.
02:35.62
James Higginbotham
Yeah.
02:44.96
James Higginbotham
Yeah, absolutely. I'm seeing two primary shifts right now in the API industry. we've you know I've been involved in in the API world for about a decade now doing training and consulting and so on. And we go through different seasons in the API space. Sometimes it's focused on design, sometimes focus on consumption and other aspects. But what I'm seeing now first is is there's kind of two things that a lot of organizations are talking about. The first is this talk of the great unbundling, particularly of API tooling.
03:16.46
James Higginbotham
We have a lot of vendors that have been producing API gateways and entire API management layers, and then a lot of other tools around the ecosystem and the API lifecycle. And some of the bigger vendors have been delivering features as part of the API gateway and management layer offering, ah but they have not really been delivering what people needed. They were, in some cases,
03:42.59
James Higginbotham
ah just not aware of what the deep needs were, and it's taking a little bit of time to kind of get there. And then in other times, they're just really focused on maybe the network layer, because that's really where their expertise lies. So, you know, companies aren't really excited to deal with unbundling and trying to stitch together a bunch of tools. And so there's a lot of discussion right now of should these vendors be delivering an all in one solution? Should they be playing nice with the industry? And, you know, and in allowing easy integration of some of the API tools that are out there, so from Winters to API catalogs and other kinds of things. So it's I'm seeing ah that a lot. And then the other thing I'm seeing is experimentation with GenAI when it comes to API design and delivery. And you know I've written about in my book the ADDR process, the Align, Define, Design, Refine, four phases we should be taking to turn.
04:40.38
James Higginbotham
ah product definition and requirements into an API design, whether you're in an enterprise or if you have a SaaS or whatever it might be. And there's a lot of experimentation I've been doing with Gen AI as well. and Where does it fit in the ADDR process? how What things do we need to make sure that we continue to have people involved with and what things can we automate and speed up? So both of those are really being encountered pretty frequently in in the enterprise space.
05:07.35
Steve Rodda
Yeah, I've been a longtime fan of you know design versus thinking and in general. um And so I love the recent blog posts you had on ATDR that I read, because you know the more you could do upfront and get right, that's a key point.
05:21.65
James Higginbotham
Mm hmm.
05:22.24
Steve Rodda
The more you could do upfront and get right, ah the more time you save on the back end.
05:23.04
James Higginbotham
Yeah.
05:26.74
Steve Rodda
And I've ran engineering teams of 400 or 500 people before. And that at scale, if you don't don't spend the time up to design, can create quite the bird's nest. so Yeah, I appreciate that. um So how is the platform talk, ah you know, infiltrating the meetings that you're having with your clients and, you know, what are your clients struggling with most nowadays as it relates to APIs?
05:51.18
James Higginbotham
I'm definitely seeing a shift toward API platforms. i've been I too have been beating that design first drum and then thinking about at scale, you know a few of my clients are anywhere between five and and even up to 10,000 developers. And when you have an organization that big, you have to really help developers along, give them predictable processes and repeatable processes to go from that design so that you understand what the needs are and then delivering on that API.
06:17.24
James Higginbotham
so that it's self-service as possible and easy to use as possible and has a great developer experience that we all really strive for. ah but But a lot of it now is shifting toward API platforms. And most of the API platform talk I'm seeing is how do I get myself organized? How do I um go beyond just thinking about coding up APIs and really integrate the API lifecycle into every team and build that up into a platform? So how do I empower every team to produce APIs that are thoughtful and deliver on outcomes and contribute to an overall platform that both supports other developers in the organization, say outside your and one immediate team to another team, maybe within the same domain area or line of business, or maybe across a particular domain or line of business when we're trying to pull things together.
07:08.10
James Higginbotham
for partners and customers and so on. So we see a lot of desire to to get these API platforms up and running and think about reuse and managing the API portfolio. So it goes beyond just the engineering roles. So a lot of the discussions that I'm having now with enterprises really are focused on a lot of different cross cutting roles. Kind of that idea of what we've been trying to achieve for a while in the in the software development space is getting products, talking to engineering, talking to security, talking to operations.
07:41.83
James Higginbotham
Sometimes it's underneath that shift left moniker, ah but really it's just having cross-functional teams, all contributing to the APIs but in and making sure it all works together to develop that platform.
07:45.37
Steve Rodda
And.
07:54.34
James Higginbotham
If we don't have product folks thinking about what the needs are of our partners and our marketplace, if we don't have business contributing to what's going to deliver value and what they're seeing ahead on the roadmap, then our APIs are going to be very much fit for purpose and there's going to be very little reuse beyond maybe ah an individual team reusing a service. We're not going to really see it grow and and be available where people need to go with it. So, you know, making sure that we assess our API platforms, figure out where we're at on a maturity scale. I do an assessment that's about 200 questions across eight different disciplines to find out how are you doing in in the different areas of your API platform? and
08:35.15
James Higginbotham
and then try to find those gaps and address those, try to emphasize and mature of the things that are really working well. So that's that's you oftentimes the struggle is that clients just really don't know where to start. And so those assessments really make a huge difference to be able to kind of drill in and see, okay, we're really good. Maybe we have really good engineering practices and architectural practices, and we're doing the well architected cloud native approach to things, but maybe we're not as great on API design, or maybe we're not as great on uh, managing the API through the full life cycle and really applying product thinking to it and so on. So we do a lot of that and a lot of training with organizations to skill up their, their teams. Uh, one of my recent training engagements that I had, I had a ah group of 40 developers and not one of them had seen HTTP over the wire, which was kind of, I open, usually when I take a survey, it's about 25% and you figure, okay, everybody's career is a little different, you know, and we have different backgrounds and things like that. But, uh,
09:32.96
James Higginbotham
But to have 40 people who have never seen HTTP over the wire, they've just sat in using their favorite framework in their favorite programming language and just coded things up. They're creating these accidental APIs, these accidental designs that really don't fit what's needed. And it's pretty challenging. So that I've been seeing a lot of that and in the platform space.
09:53.12
Steve Rodda
Well, i and so I'm super curious about that. I actually read a stat the other day. I think it was the F5 networks that was talking about, um you know, it's something like there's like 2 billion APIs that are out there that live like shorter than a year that companies are claiming that they created that are there.
10:07.72
James Higginbotham
Hmm.
10:09.98
Steve Rodda
So it anything on that you're seeing for like how does how do these short term kind of you know, APIs fit fit into these platforms. And, you know, how do you manage that? And, and you know, I'm sure security has got to be a concern and all that sorts of good stuff.
10:23.79
James Higginbotham
Yeah, yeah, absolutely. Absolutely. It is. ah ah So there's a few things to consider on that perspective. One is I see organizations that will build up APIs, they'll they were kind of taught to go down the microservice path. And so they're thinking services are APIs. And I try to kind of disconnect that and say services are, they're distributed components that help us decompose really complex problems. They may not necessarily be designed for a partner to use.
10:53.74
James Higginbotham
And the API side of things, when we think about API as a product or put product thinking to an API, that gives it a little bit longer life. So I could imagine, I would say those numbers might be a little bit off based on what I'm seeing, but it's hard to say. But and what I do see is there are a lot of APIs out there that were built to the best of someone's ability, but without this kind of thoughtful design.
11:19.19
James Higginbotham
they get shoved in a corner and sometimes they're not even used at all. They have zero consumers, but they're out there. One of my clients has six thousand over 6,000 internal APIs right now. And so now their job is to figure out, okay, using the ah reports that we have from our infrastructure, it gives us observability. How many of these APIs are not used at all? How many are being used by the immediate team? How many could be thoughtfully improved?
11:48.38
James Higginbotham
ah So we have a lot of APIs out there that are just kind of put together really quickly or generated from different types of you know integration tools and things like that to to make it work. So I see a lot of that and trying to shift people over to thinking about a platform as you know a set of APIs that you manage and own and steward and curate it takes a little bit of of work, but it shifts that process to where all of a sudden now we have APIs that partners or other teams want to use.
12:19.96
James Higginbotham
It just takes a while to get there. But there's, there's definitely quite a few APIs that are either what we might say zombie APIs or shadow APIs. You know, either we don't know about them until we discover them in our, uh, infrastructure logging mechanisms or somebody's doing an auto, their cloud environment and go, what's that?
12:34.83
Steve Rodda
Yeah.
12:37.13
James Higginbotham
And then they realize there's some API out there that's being used or a zombie API that's just kind of out there and not really being used at all. And, and, uh, and so it's, it's a challenge to get ahold of that whole portfolio.
12:47.46
James Higginbotham
and and start to manage it effectively.
12:50.34
Steve Rodda
or a high profile hack that happened a couple of years ago where the user's api endpoint got published with no authentication. that's ah That's a fun way to find out your APIs are out there. well
13:00.27
James Higginbotham
but Oh yes, absolutely. Yeah, one of my clients did a self audit just to see where they were at. And they found about two dozen APIs that were not even behind their API management layer. And they went and tracked it back and realized that a VP had authorized the accelerated delivery of this API to skirt governance, to override any checks and balances they had in a production environment.
13:25.88
James Higginbotham
And thankfully it was caught. They reviewed the logs. Nothing was found, but that was, they had 24 APIs with however many operations that totaled up to probably 50 to a hundred operations that were potentially those kinds of attack vectors that no one would have known otherwise because they weren't being tracked.
13:39.97
Steve Rodda
yeah
13:42.94
James Higginbotham
So. So education goes a long way too to helping folks all the way up into the executive tier understand their are decisions and what kind of impact it could have on the organization.
13:55.12
Steve Rodda
That makes sense. So how how can you know API tools evolve to not only help with that problem we were just talking about, but the other things you mentioned um you know that you're you're kind of seeing in the industry?
14:07.23
James Higginbotham
Yeah, a lot of what I'm really asking vendors to do is to think beyond the laptop. I think a lot of vendors say, if this works on a developer's laptop, I've, I've solved the problem. And, and there's so much more to it. As you know, there's just a lot to managing, uh, tooling infrastructure, you know, anything along those lines. Uh, so not just optimizing for those single developer experience, but the holistic organizational experience. What is that organization's policies and practices and how does this fit in and
14:41.44
James Higginbotham
um Vendors are going to have to probably start working with other vendors. The larger vendors are going to have to start spending a little time with the the the smaller initiatives, the community initiatives that are maybe, you know, open source driven, community driven to figure out how they can help support those, but not just to fund staffing, which is great to fund, you know, the continual support of those tools, but the integration of them. How can we make this tool easier to integrate into an overall pipeline and deliver on that?
15:10.92
James Higginbotham
And and i it's it's really sad to see in some cases the state of our API tooling ecosystem. There's a lot of really great little tools, but they require us to move and jump between tools and copy and paste things or transform things or do all kinds of integration hurdles. And that slows a lot of organizations down. So things like even just an API catalog, a lot of people say, well, just go to backstage and use that. That's pretty popular tool these days for cataloging.
15:41.45
James Higginbotham
APIs and what will happens is people will look at it and go, I cannot dedicate five or six full-time engineers to taking this this tool and then figuring out plugins and then writing my own plugins to make it work in my ecosystem. So being able to get vendors to contribute plugins to certain tools that are starting to to gain some gravity and and in mindshare and then getting those tools equipped to be able to play in those environments that go beyond one developer or a small developer team that you know were originally designed to scratch an itch and eventually need to really support multiple teams with perhaps a regulatory you know requirement for an organization like a bank or or insurance or other areas where we have lots of regulatory rules, healthcare, care and others to to think about well what is their workflow like and does the tool kind of support that as well as
16:37.00
James Higginbotham
the developer who's got an idea and they're kicking off that startup. So there's a bigger ecosystem out there that I think is is lost and it's really hurting because our tool ecosystem really lacks some of those capabilities, you know, at least in some of the tools.
16:55.16
Steve Rodda
Now it makes a ton of sense and certainly certainly we're familiar with that as well. So um so yeah, you know speaking of that, we noticed you're using Blackbird and obviously it's very important to us.
17:00.42
James Higginbotham
Yeah.
17:08.53
Steve Rodda
So we'd love to hear what your experience has been thus far.
17:11.87
James Higginbotham
Yeah, yeah it's it's been really great. It's been eye-opening. It's exciting to me because the things that I pointed out about some of the things that are not working with the tools in the tool ecosystem, um the Blackbird is starting to overcome. So one of the things is just that full lifecycle understanding of how to deliver APIs. you know My ADDR process encourages design first, which means we spend time understanding and interviewing developers and business and uh, other domain experts on what the problem is and what we're trying to solve and how the API or APIs that we're going to be delivering are going to solve that. And then usually what happens is I train people on how to do that. They get to an open API spec stage. They produce that and then they're kind of off into other tools and they're having to grab this tool to maybe generate some code in this tool to, to you know check to make sure that we're following our standards and practices and
18:07.48
James Higginbotham
you know, another tool to say, well, is this API already exist? Or if I need these capabilities, what kind of APIs already exists that I can use? And so Blackbird is starting to think about that. It's thinking about the catalog. You know, how do I find an API? It's thinking about how to import an open API spec in and register it so that everybody kind of knows what everybody else is doing and becomes a central communication hub. It's generating a mock API. So that gives rapid feedback. That's one of the steps in in the refine phase. That last bit is Once you've kind of gone through and understood what the requirements are and you start to shape that into an API, how do you get feedback quickly? You don't want to start writing code to get the feedback on the API because that's going to spend a lot of time and resources to make it happen. So using the mocking and capabilities of Blackbird, you can import your open API spec, generate an api mocking in just a few seconds. You have it up and running. You can give it to a team member or to a partner, whoever's going to be using this API.
19:03.36
James Higginbotham
maybe be a front end developer and say, all right, start putting it through its paces, start integrating it in. What do you think? How's this working? What do we need to tweak? Before we start spending a lot of time coding up things and the cost of change becomes so high that we say, well, we'd love to incorporate that change, but we really don't have the time to do that. So we're just going to have to live with it as is. There may be ways that we can improve the developer experience of the API and make it more useful, more robust.
19:28.93
James Higginbotham
so That's really interesting. The other thing is taking the ADDR side of things, and I wrote about this in one of my articles, is taking some of the insights we get, the jobs to be done, those outcomes we're trying to solve with our APIs, and then using that Gen AI capability black built into Blackbird to generate the open API spec. so I can take all of the things that I've captured and then be able to produce a prompt that's really rich about what the operations are going to be and What kind of resources and what the properties of the resources are figured those things out. And, but I don't have to sit down and write a bunch of YAML. I can just use the gen AI, give it a great prompt. It gives me a really great starting point, gets me 80, 90% of the way there. I go in and and tweak it and add some examples. Maybe you have that prompt, add some examples in for me. And now all of a sudden my mock becomes richer. I can give feedback quickly and figure out what did I miss? Uh, you know, what, what kind of gaps might I have?
20:24.46
James Higginbotham
What kinds of things do I need to tune? I can tune that and then generate code off of it. So it's it's really, really powerful how that's how that's set up.
20:34.48
Steve Rodda
Oh, that's great. And I, my favorite thing about open API files I've been hearing forever is like developers always like, oh, that thing that we do to update our documentation, you know, and it's like, no, it's supposed to be bigger than that.
20:43.61
James Higginbotham
Yeah.
20:48.12
Steve Rodda
Right. Like, so it's, uh, you know, it should work into every fabric of your api development moving forward, you know, so.
20:54.05
James Higginbotham
Absolutely, yeah, absolutely. I mean, it's it's the central artifact that drives all communication. And if you build open API out and you detail it out and you get buy-in, you mock it, you get feedback, that becomes that central artifact the front engineers can start working with and using that mock for.
21:11.74
James Higginbotham
it So a lot of people get.
21:12.54
Steve Rodda
yeah
21:13.71
James Higginbotham
They get frustrated by APIs. They're always holding us back. The front end can't start until the back end is done and then they complain. The front end complains at the back end doesn't deliver everything they need. and So then we jump through hoops trying to make that work. And the open API spec is that central artifact. And so if we invest in that, now we can all run in parallel. And that becomes our central source of truth for how things are going to work. And so it can be really powerful if used if used thoughtfully in an organization.
21:44.68
Steve Rodda
Yeah, one of my ah the hard parts usually is trying to get you know the upper management. I could say this now that I'm in upper management, but you know the the getting the upper management to buy off on something like ADDR upfront. but it's And i want I want to know if you're seeing this in your clients where where they have that buy off too. But for me, it was always about um you know engineers are the most expensive people in your organization usually, that might not be industry-wide, both in cost cost and opportunity cost, right?
22:15.02
Steve Rodda
So, you know, how could something like Blackbird end coupled with the ADDR process, like, you know, help prevent incurring those costs down the road?
22:15.30
James Higginbotham
Yeah, yeah.
22:25.64
James Higginbotham
Yeah, my conversations, every once in a while we'll start with ADDR. Someone picks up the book or they catch an article or an interview like this or something. And they'll say, hey, I'm going to check this out. Most of the time, my conversations start with a question that they ask me. Why is it taking me so long to create APIs that can be reused? They're scratching their hand going, why can't my APIs be reused?
22:52.25
James Higginbotham
Why is this not working? Why did it take so long to get my partner on board with my API? Can you tell me that? And usually what it'll what the first thing that I'll do is I'll say, well, let's look at your portal and see what it offers. And their open API spec will be anemic. It's the one or two sentences on that the description. It doesn't help paint the picture. It doesn't educate ah their operations are no different than generated Java doc for Java developers where you know you get these code generators and they go,
23:20.96
James Higginbotham
ah returns the color, sets the color, you know or or something, and that's it.
23:25.56
Steve Rodda
Yeah.
23:28.15
James Higginbotham
And it doesn't say anything about how, why, what's the context, what are the ramifications of using this this operation. So then they wonder why things aren't being used or are being found, ah being discovered, or maybe why their account managers can't sell an organization on using an API and say, hey, we have this API, and they hand it off to the developers, and developers go,
23:50.31
James Higginbotham
I don't know, I really can't use this and that's sure what I'm doing. So maybe they take that step to engage and have a phone call, you know have that Zoom call that says, how do I use this? And they go, oh yeah, yeah, here's an example or or whatever the case is. So usually it's not about I need a process to design my API or I need a tool like Blackbird to get my developers optimized through the life cycle. It's building awareness of the need for design first, thinking shifting the thinking to a jobs to be done approach of what's the problem to be solved, what's the desired outcome, and then what that API will do in the middle to take you from the problem to the to the solution or to the outcome. And and how the API, if if designed thoughtfully, one or more APIs in combination will get them there. And when you shift that, then they go, oh, OK, the light bulb comes on and they see it.
24:42.40
James Higginbotham
And I just had one of those light bulb moments for my clients. We were, I was facilitating an ADDR process, you know, it's going through and saying, okay, let me ask you some key questions. Let's get those jobs to be done. So we designed or found the, the unifying job story. What is that kind of big picture job story that's, if you were to summarize in a, when there's a problem, I want to, ah you know, get a job done so I can and the outcome. If I, if we frame it like that,
25:10.56
James Higginbotham
What is kind of that begin and end state? And they realized, oh, wow, okay, now we know this, but we haven't really phrased it into this kind of three-part sentence. And then we started digging into, well, how can we design an API to support that? And what operations do we need? What's the workflow? What's the steps? They sometimes have that curse of knowledge. They're so close to it that they can't really get away from it to think about what is it like for someone outside of organization to go through this workflow?
25:37.41
Steve Rodda
There.
25:37.65
James Higginbotham
because everybody in the organization probably knows the workflow and they use all these acronyms and shortcuts and they talk about this system has this data and that system has that data and they probably name their systems and they're like pets or something, you know they've got names and personalities in those systems and they either like them or they don't they put up with them or whatever, they take lots of feeding and care, ah but they don't really think about from the outside in, what is it like for my partner to work with me as an organization? And we shifted that mindset in this case And all of a sudden they went, oh, wow, OK, so we have this platform API. Right now it has three operations. Over time, it'll probably have about a dozen or so. It handles this full workflow. We have operations that our partners will call. And then we're going to have other services and back end operations that are going to support that. But we don't want to let them know that. they don't this This is the software engineering encapsulation idea of let's hide the implementation details and let's just get a really
26:35.35
James Higginbotham
good interface where they can submit things in, follow up on the status, pull stuff up later to get into their systems, whatever they need. And we nailed that and all of a sudden the the product leader said, wow, okay, what we've really done is not only nailed down this API, we've nailed down the definition of this resource that has this whole lifecycle in this part of the organization for this particular type of partner.
26:58.75
James Higginbotham
And now we can use that across all of our other systems. So now we have a very clearly defined domain concept that we can use in other places. And they it blew their mind. And I said, well, we just used ADER to walk through that process. you know and And then by the end of it, then we generate the open API documentation, and we get them on their way to starting to implement the solutions. And they have an architect that's figuring out what systems they need, where's the data flow going, all of those details.
27:26.45
James Higginbotham
that comes later, not first, and most organizations start with that first. And they miss that opportunity that I described of really thinking about things from a partner and ecosystem perspective.
27:38.09
Steve Rodda
I mean, you don't just start coding. know
27:40.64
James Higginbotham
Yeah, well, i that's not what I'd recommend, but it's what I see a lot. ah Yeah, I mean, I get in there and the and the developers are worried about the data, and then they're figuring out how they're gonna, they'll design the JSON,
27:48.12
Steve Rodda
and
27:55.71
James Higginbotham
But they won't think about the operations and the workflows. They just think about pushing data over the network. And sometimes we need that. But and but yeah, so it it it takes a little bit of of retraining the mindset and expectations of everybody involved. Oh, you're spending time designing first. Well, aren't you wasting time? Don't we need hands-on keys? Which is the worst phrase I've ever heard. And if you're hearing this and somebody's is using that, please stop. It just it just doesn't and give the value involved of all the people applying their domain expertise and their skills to turning the reality, the physical world that we deal with into something virtual that can be automated with an API. It just it's it doesn't give the value, the do the due value to the the people involved. But that's what they think. you know We're just not coding yet. No, we're going to design first when I think about this.
28:53.32
Steve Rodda
Well, and it, you know, like it's one of those things, like there's got to be some ratio, like, yeah, you can put hands on keys, but if you don't design it first, then you're going to be putting four times the amount of hands on keys down the road.
29:03.58
Steve Rodda
Right. Like, so there's some efficient.
29:04.35
James Higginbotham
Yes, absolutely. and And we've lost, yeah, absolutely. We've lost, I get on the soapbox all the time and I won't do it too much here, but there's been this missed opportunity where Agile was meant to improve the communication and the number and the times of communication between business, product, and users, everybody together with the developers that are usually isolated in the room. I mean, we remember,
29:29.98
James Higginbotham
When I first started, I was writing 600 page ah SRS documents, software requirements specifications. You would take months and months, maybe over a year, to write that thing, get it approved by all the right people. You don't start coding until two, three years in. By five years, the world has changed so much that none of it matters anymore. The the purpose of Agile was to get rid of that, not get rid of design, not get rid of feedback and communication and and those kinds of things. So being able to,
30:00.27
James Higginbotham
uh, you know, build a prototype or deal with a technical risk. Hey, I'm not sure if we, if the data that we're going to need to deliver this API is quality data. Okay, great. While we're designing the API, let's go assess the viability or find out if we have a risk here of the data not being right. And we need to get a data quality team involved and we need to source the data from somewhere else. We need to do something else to make this API valuable. And, uh,
30:28.24
James Higginbotham
you know, that's different than let's start coding the solution. And and so, as you said, you know, do I want to spend four times as much? Do I want to use the eraser on the drawing board or the sledgehammer on the construction site?
30:40.20
James Higginbotham
You know, what what do I need to do?
30:40.87
Steve Rodda
ye
30:42.34
James Higginbotham
What kind of level of work is it going to take to make this change that we just discovered? Can we bring that discovery earlier? in And APIs are really a good opportunity to re tool the culture for that, because they bring all those things together.
30:56.35
James Higginbotham
They bring the data, they bring the systems, they bring the documentation. You're putting something out that's our digital front door to your organization. So now all of a sudden, you, you know, you're, you're, you're going to be building an asset that's going to represent your organization.
31:04.84
Steve Rodda
Yep, yeah.
31:12.01
James Higginbotham
Are you doing the best you can to deliver the best thing possible? And, and that can help shift that culture a little bit in the thinking.
31:20.36
Steve Rodda
Yeah, you were talking initially and I was just thinking Agile, Agile, Agile in my head when you know talk about being a keyboard before and and the things that that's kind of removed from myself.
31:31.09
Steve Rodda
But, you know, but back to Blackbird, you know, I'm a product person at heart.
31:34.24
James Higginbotham
Yep.
31:35.82
Steve Rodda
So I have to ask, like, what's what's your favorite feature and so far?
31:40.18
James Higginbotham
Yeah. I think what's really interesting to me is something that is in the early stages, but I think working really well, which is the idea of having the API catalog and a central place where everything is registered. There are a lot of tools that you could, you can grab different tools for different aspects of what Blackboard does, but there's nothing that puts them all together so that it's a seamless flow.
32:02.73
James Higginbotham
And it works with a developer by getting command line tools as well as the web interface. So you can kind of work the way you like to work. But the idea of having a central location where teams can start to register their APIs, because if you register aoppa APIs, you get a benefit from it. And that's where a lot of the gaps are. I can go grab an API catalog, like, you know, backstage or anything kind of similar to it and start registering my APIs there. But if it's not driving my developer lifecycle all the way through,
32:32.28
James Higginbotham
then it's just going to be something off to the side and people are either going to forget it or they're not going to keep it up to date or whatever the case is. So I, that kind of excites me. The idea of having that catalog created by virtue of registering your API and then running the rest of the life cycle through it makes the catalog valuable and updated rather than forgotten. It becomes like a write once read never Wiki that a lot of organizations might create, whether it's one of the commercial offerings or a open source offering that they've installed to capture their knowledge. You write it once, no one looks at it, and you never update it again. It's off to the side. It's not in your day-to-day workflow. And Blackbird's giving that opportunity to take other areas of the API lifecycle and put them into that overall workflow so that they're not lost and you can take advantage of them.
33:20.45
Steve Rodda
Yeah, there's a big pet peeve of ours that ah you know lots of people say they have an API catalog that's out there, but are you are you building from it? Are you you know making it a central part of your development? So it's great great to hear you say that. Thank you very much.
33:34.19
Steve Rodda
so we are We're about two weeks away from launch. um I don't know when this podcast is going to air, but right now we're about two weeks away from from launch that's there. So I got to ask so we can we can get it in there for you. but what's the Are there any any areas for improvement or things you'd like to see us do better?
33:50.25
James Higginbotham
I think it would be great just to see um a couple of things. One is making sure that that catalog that you're building by nature of of registering these APIs is searchable, but it's going to help drive discovery. One of the challenges I see in organizations, particularly as their API portfolio gets larger, is that teams will ultimately end up building an API that they already have without knowing it because they don't get a consume first build when necessary mentality. So Blackbird is here to help you when you need to build, but it should also you know help support that time of how many lines of code do we not have to write because we're able to find that API and and start consuming it.
34:31.91
James Higginbotham
So that search, the discovery, maybe the ah you know its a little bit on the consumption side of helping people use that API as well after the development cycle is done. So I think that would be really interesting to see as Blackbird ah grows and and and starts to think about that, as well as maybe thinking about the overall just kind of what's that flow like when we have a we start coming around, we start adding more enhancing that API.
35:01.03
James Higginbotham
So we're going from a V1 to a V1.1. What's that flow like? um you know seeing I'm seeing some really good opportunities and and things that are there to support that.
35:11.97
James Higginbotham
So maybe getting some guidance out there. That might be more just documentation and and guidance for the users to say, here's how you can use Blackbird to kind of get around to that V1.1.
35:19.51
Steve Rodda
Chair.
35:26.11
James Higginbotham
How do we see our versions and how are we mapping that in? And then maybe also just a third one I thought about is linting, getting linting in there so that organizations that have invested in that linting logic can drop that right in and they don't have to drop out of the tool.
35:41.54
James Higginbotham
So those would be great things. I think the product itself has got a great foundation and has a lot of those pieces there. And so it's just connecting those dots as you start to mature and grow that and see it, see it take off.
35:53.22
James Higginbotham
So.
35:54.29
Steve Rodda
Agreed. um Yeah, and thanks for that. We'll get that over to the roadmap.
35:59.49
James Higginbotham
ah great
36:00.13
Steve Rodda
The yeah and just actually interesting thought that came to my mind, he you know there are AI elements inside of Blackbird, right? So potentially the AI could help you out with some of those things. If you're creating a specification or even generating code for something that already exists, it should kind of be able to tell you we already have this in this place you sure you want to you sure you want to do this kind of thing so it might be able to help along those lines so it'll be good.
36:26.67
James Higginbotham
Absolutely. That's a great idea.
36:29.56
Steve Rodda
So yeah what do you what do you think is going to be the biggest game changer?
36:32.88
James Higginbotham
Uh, well, I, I, I would see definitely, I would love to see, um, you know, Blackbird really being a game changer from the perspective of pulling these tools together. So I think if you say, if you said, okay, well, we're going to support. Two or three of the most popular linting tools, you know, there's kind of usually one that bubbles at the top. Maybe there's a couple others people are using, um, you know, getting those things in place, bleeding the market and saying.
36:57.90
James Higginbotham
Yes, we have a solution. We have a differentiating feature set, and so we're investing in Blackbird as a product, but we're also recognizing that we have a a market ecosystem out there of tools, and we don't want to reinvent things. ah one and I saw another vendor invent their own linting tool, and their goal was to try to keep you from having to write code when you do the linting tool, which is great, but now it's all the sense that, well, now I've got to point and click and turn my style guide into a bunch of linting rules. And that's pretty difficult too. So maybe there's some ways to do that. And Gen AI, I'm seeing some people experiment with that too. If it knows what your linting rules are, what your style guide is, maybe you can build those linting rules or it can import things in for you or whatever the case is. So there I think there's an opportunity for Blackbird and your team to lead the market in showing
37:50.00
James Higginbotham
What is it like to build a tool that's differentiated in the marketplace, but recognizes that a lot of hard work has gone into open source and closed source tools that are making people's lives easier and we don't have to own every piece of it. And that's, I think, sometimes where the, going back to our earlier earlier question of, you know, where tools are really struggling is they feel like it's not, if it's not invented here, then it doesn't, you know, then we can't, we can't use it.
38:18.47
James Higginbotham
But there's a lot of great work going out there. So how can we balance that? To me, I think could be a huge game changer for the API space. Because we need the leaders like that. Everybody's kind of been in their own little islands for a while. So I'm excited to see where that could go.
38:32.47
Steve Rodda
Yeah, one of the things that frustrated me as a developer right was like when you would bring a new tool on and it kind of forced you to change your workflow, right, or the other bits and pieces that were between there you know so we we really tried hard with Blackbird to give you, give you the major pieces that could help you move along but then play nicely in that ecosystem, as well as your workflow so it's great to hear you say that.
38:56.63
Steve Rodda
And you you talk about Lenting a lot. um Lenting is definitely on our minds and ah a place we're going to go to. Actually, one of the major contributors and people who wrote Spectral, which is a pretty and popular linter.
39:09.71
Steve Rodda
He works here now. so um so and so So definitely on our minds and and you know especially on his too to see what we can do with with that and Blackbird in there together.
39:11.56
James Higginbotham
Oh, very nice. Yeah.
39:22.76
Steve Rodda
So glad to hear you say that for sure.
39:24.97
James Higginbotham
Great.
39:25.25
Steve Rodda
So obviously, you get know you work a lot with the a d ADDR process that's there. you know How have you refined that process over the years? And how can you see Blackbird kind of fitting into that?
39:37.29
James Higginbotham
see Yeah, it it's been around for about 10 years now, actually. It's been under different names and looked a little bit different, but I've been training on it for for a a full decade. It's hard to believe. I wrote the book about three. It's coming up on its third anniversary of of publication.
39:55.98
James Higginbotham
So it it started off where it just said most people are using REST APIs. I think a decade ago, we didn't really have GraphQL. It was just early in and not really that many people paying attention to it. Google was working on gRPC, but not a lot of people were really using it at that time. So REST was predominantly what everybody used. So the design process was set up to think in terms of REST. So we were thinking in terms of resources and URL paths and HTTP methods. So we would kind of model and design and deliver the API. And then over time, what I found was I was encountering teams that would say, okay, can you review my API and look at it and say, okay, great.
40:32.98
James Higginbotham
What are you trying to do? What's the big picture? And they're like, well, I'm just taking data out of here and I'm sending it over here. You know, whatever it was, I'm making this capability available and they didn't really understand the context by which they were building. So it really was just more of like define and design and that was it. So we expanded it. We expanded to include a line at the front end to say, let's take all the hard work you've done to understand the problem space and let's put it into a format that can drive your API design.
41:00.97
James Higginbotham
And oh, by the way, if you don't have that yet, then stop and go figure that out so that your API will benefit from it. And then the refine we added on as we tried to figure out, well, what are ways that we could in the design phase with minimal effort get feedback on our API before we've written the code and someone's banging against an actual implementation and trying it out and going, yeah, that's not what I need at all. Can we get that earlier? So that's been, that's been a lot of addition. So.
41:30.57
James Higginbotham
When it comes to Blackbird, Blackbird is not really there to take in the requirements and discovery. The product folks are not going to really dive into it there, but but they've done that work. So what it allows us to do is when it comes to the design phase, if we've done the align and define, we figured out what we need and we sort of sketched out what operations our API is going to have and what resources you're going to be interacting with without thinking about what style of API you're going to be using.
41:57.19
James Higginbotham
you have that captured, you can now feed that in. And so that's where it really that ti it ties into that design phase. So the first first two phases, figure out what you have and what you need and what APIs you already have in your inventory. So Blackbird can start supporting that. What APIs do I have in my catalog? And what can I use and leverage? And then what do I need to build? Whatever I need to build, I need to design it. I can take what I have, start to design it in Blackbird, then start to refine it with the mocks, get feedback.
42:26.81
James Higginbotham
and then start to develop and I can even code generate to speed up my delivery process that comes. So it's a really nice compliment to that design first approach and the way that ADDR has been kind of grown over the years to make sure that we're taking all things into consideration, but doing it in a rapid way so that we're not spending you know months trying to design an API. It just takes a few hours to a few days, depending on the scope and the people involved in their availability.
42:55.32
James Higginbotham
and you have an API design that's really thoughtful and a nice addition to your API platform. And now it can be cataloged in Blackbird and then mocked and co-generated and and then you know have that full life cycle going through. So it's pretty exciting.
43:09.87
Steve Rodda
Nice. That's great to hear. All right. Well, anything else that you'd like to have yours to know before we wrap up?
43:17.12
James Higginbotham
ah Yeah, just if if you want to reach out to me, if you have any questions, um You can reach me on LinkedIn. I'm pretty active on LinkedIn these days. I also curate content for a weekly newsletter, apideveloperweekly dot.com. So you can sign up for that and stay up to date. I hand curate articles and look for things that are interesting and send it out every Thursday. And then of course I'm writing on launchany.com, ah insights on kind of the enterprise API platform world. And then finally, I just launched recently, apicoch.io, ah starting to put training content out there. So I've been training a lot of corporate
43:51.62
James Higginbotham
companies and giving them videos that they can train their staff at scale without me having to deliver live workshops. And so now I'm making that available for individuals. And so starting to put some content out there as well. So I've got a couple of courses out there now for developers or for product owners at apicoch.io. So you can find me there.
44:10.39
Steve Rodda
That's great. Thank you, James. I appreciate you taking the time today.
44:13.49
James Higginbotham
Yeah, thanks, Steve, for having me. Appreciate it.