[0:02] – John Burke: [music] Hi, I’m John Burke, CTO of Nemertes, here with my co-host…

[0:07] – Scott Robohn: I’m Scott Robohn, CEO of Solutional and host of Total Network Operations, a sibling show here on Packet Pushers.

[0:14] – John Burke: And you’re listening to Heavy Strategy, the show that tries to ask the right questions, not give the right answers. Joining us today is Andrew Wertkin, Chief Strategy Officer at BlueCat Networks. Andrew, thanks for joining us.

[0:25] – Andrew Wertkin: Thank you for having me. I’m looking forward to it.

[0:30] – John Burke: And on today’s show, we’re going to be talking about just what a network management company is going to talk about: the challenges of using AI for enterprise network automation. Because we all know IT folks are bending AI to the task of speeding up network automation efforts. Why isn’t that as simple as it sounds? Why can’t we just take Claude’s word for it 99% of the time?

[0:50] – Scott Robohn: Yeah, you know, just put it in a permissive mode and click go. [laughter] Done.

[0:55] – Andrew Wertkin: Yeah. You know, it’s interesting, because I’ve been developing software for as long as I can remember. There’s a reason I can’t write: I’ve been typing my entire life. And I’ve enjoyed the craft very, very much. But it’s been interesting on the network side, because the teams have been doing a really good job. And by “the teams,” I just mean network engineers out there driving automation, pre-code generation and pre-LLM, and really trying to mature the methodology of developing software, akin to how software development companies develop software.

[1:37] – Andrew Wertkin: And with AI, and with LLM-driven generated code, without those best practices, it’s kind of scary to think about what might happen on the network. So it probably comes down to a further transformation in those teams toward more sophisticated processes around software development, because the faster stuff can be created, the more stuff can probably break.

[2:04] – Scott Robohn: You have a thesis that really resonates with me, right? I would say one of the other hats I wear is co-founder of an organization called the Network Automation Forum. And as of recording today, I’m coming off our last meeting, AutoCon 5 in Munich, Germany. We started that discussion on the attenuation against the adoption of network automation before AI entered the room, right? There’s always been a certain level of resistance to letting automation go full throttle, and now the bots and the agents are walking into the room, the eye rolls are happening, and the skepticism is strong.

[2:55] – Scott Robohn: I would love to use that as part of our conversation here, to say I agree with you. We need to see great best practices develop in software engineering and software development, because a lot of what we do in network operations is downstream from that. I know I’m maybe taking a little too much time here up front, but that’s my perspective, and I’m really interested to have this dialogue with you.

[3:20] – John Burke: Yeah, super, and I think you’re spot on. The distrust of automation in the network shop runs 25 years deep. We have been hurt badly by trusting automation too far, too fast, many times.

[3:41] – Andrew Wertkin: Yeah. What I always hear is trust, more so for repeatable, templated actions.

[3:46] – John Burke: Yep.

[3:46] – Andrew Wertkin: If it’s outside of simple, repeatable, templated, then that’s where the lack of trust starts coming in pretty heavily. And as we know about our brethren, a vendor coming by and saying, “Just point and click, simple, easy automation,” is probably the worst way to gain trust with the end customer. The more opaque it is, the more concern there usually is, which accelerates that potential distrust in the world of AI. I don’t know. We can talk about ways to approach it and drive more trust, but it’s not just in networking. It’s obviously across the board.

[4:44] – Andrew Wertkin: Many of us have lived in environments where source code control wasn’t being used, where reviews weren’t done appropriately, where code was copied and pasted from somewhere else without being scrutinized for the current environment, and it could just go on and on and on. And you can trip ten of those major issues within a day if you’ve only accelerated it.

[5:11] – Andrew Wertkin: It does bring a tremendous amount of promise, but it’s not just software development, right? It’s debugging, trying to figure out what’s going on in live environments and why it’s not working. In some of those areas, as long as you have somebody with the right expertise and you stay critical of what you’re being told, the amount of work that can be done in a short amount of time is just amazing. Just absolutely amazing. As long as you’re not just going, “Oh, you said it’s that, so it’s that. Okay, I should do this. I should do this.” That’s where the concern is, because we know LLMs, however hard you prompt them otherwise, tend to get pretty black and white about thinking they’ve found the root cause.

[5:58] – John Burke: What I like about the idea of accelerating automation is the idea that you’re going to be able to help people accelerate better practices. If they’re using better practices with AI, they’ll get to the end of their automation projects more frequently. They won’t leave them half finished or three-quarters finished, never fully debugged, never fully documented, right? And then move on to the next emergency. There’s more chance that in a single day, or two days, or a week, or two weeks, they’ll be able to get all the way through and leave something behind that they can actually use again confidently, as opposed to with some fear and trembling.

[6:39] – Andrew Wertkin: Yeah. Yeah. A lot of it’s just about architecture. A lot of it’s about, well, one is the appropriate developer mindset, which is: I’m writing this for the people who will maintain it in the future, so let me keep that in mind.

[6:58] – John Burke: Which is automatic, right? Every developer thinks about that from day one.

[6:58] – Andrew Wertkin: Yeah. Exactly. [laughter] Yeah, especially when it started with, “Oh, we need a quick script to try to solve this issue,” and then somebody finds it six months later.

[7:15] – Andrew Wertkin: So a lot of it comes down to architecture. A lot of what is going to be in that automation will be repeated, right? How do we authenticate? What are the standards around logging, or how do we want to log? How are we going to interface with our devices? How are passwords vaulted, and how do we get them out of the vaults? How do we want to test, or how should we think about backing out changes, or whatever the case might be? Almost everything I just listed is something that is repeatable in this appropriate methodology. Then you just need to go add your business logic, not necessarily all these other pieces, and therefore all the code stays fresh, it’s being tested, and so on.

[8:01] – Andrew Wertkin: But it’s really easy to build something quickly. And everything I just listed also sounds like it’s going to take longer than just having eight people reel off eight different fully functional, A-to-Z scripts or applications, whatever we’re building. So it’s probably more important than ever to start off on the right foot and think about how we’re going to make this sustainable, where humans will be in the loop and where it’s critical that they’re in the loop, and what practices we’re going to bring forward to do this safely.

[8:50] – Andrew Wertkin: Many of these are the same things we’ve always considered or been concerned about while building software over the last several decades, right? Some of it’s just how rapidly it can be done now. And it’s not just people copying and pasting stuff off of Stack Exchange; anybody can have code generated that works in that environment. That’s easy to do, and that was not the case two years ago.

[9:28] – Scott Robohn: Well, I think we’re in the middle of this fast-changing and experimental time, right? If you go back just a couple of years, people had their initial experiences with chat-based tools and got widely varying results. The whole non-determinism of LLMs thing, that was our first experience. And then we saw the advent of vibe coding and what an enabler it is for prototyping, but also what a spaghetti mess it can produce for an enterprise code base, and now we have emerging methodologies like spec-driven development and test-driven development. I think we’re seeing the emergence of, “Okay, here’s how I use the tools, and here’s how I can actually build trust in the technologies,” versus my first ChatGPT 3.x experience, right? What are you seeing on those fronts, with the emergence of these strategies and repeatable tools that are coming up?

[10:30] – Andrew Wertkin: Yeah. No, we’re seeing them for sure, and we’ve been experimenting with and adopting a couple. I think where we, my company and also me personally, have had the most success is, interestingly, the part I spent probably the least time on in my career (not the company, but me personally), which is upfront spec development and working with the LLM on trade-offs. That’s where I can bring in my experience: how should we approach this? Spending that time up front, breaking it down into reasonable chunks, and then putting the appropriate guardrails in place, that sort of stuff has been transformative, versus trying to type out a prompt describing exactly what you want.

[11:27] – Andrew Wertkin: It’s the sort of iterative spec and test development that really starts with, “Okay, I want to create a high-speed eBPF logger,” right? I’ve never done that before, right? And so I don’t even know what the trade-offs are, so how much can I trust whatever comes back? But I can start at a very high level: I want to do this. What’s your intent?

[11:57] – John Burke: You got it. Yeah. I think there’s a really important point sort of one level underneath that, which is that stating your intent and need very clearly is crucial. When you’re having software twiddle the settings on hardware out in your network, twiddling the wrong settings shuts down the traffic flow, or overburdens the processor so much that you get terrible performance drops as it maybe devotes all of its time to generating logs and sending them. So you’re in a space where infrastructural mistakes can happen, and can happen at automation speed, and have really huge consequences.

[12:47] – Andrew Wertkin: Yep. Yeah. I mean, in our world of DNS, just on the public side, if you look at the last several major outages that were announced by huge public corporations, I think 80% of them were automation-driven changes to DNS that took everything down. And I’m not going to remotely blame an LLM for that. But the faster you can come up with the solutions, and especially the more certain your coding partner or your debugging partner or your performance partner is, whatever the use case might be, the more likely you’re going to be like, “Yeah, okay.” And then everybody suffers from permission fatigue, and your fingers over-enter and you just keep pressing it. So that also comes down to how we appropriately supervise the behavior and make sure those things don’t happen.

[13:46] – Andrew Wertkin: But yeah, so the more successful expression of intent includes those things. What do you know could potentially go wrong? What are you concerned about? What do you make sure is actually tested? What does load actually mean here? How should it behave under load? You don’t need all that stuff up front, but having the right experience to know the categories of things you should probably be considering is good.

[14:21] – Andrew Wertkin: But what you don’t need to do, and I think this has really matured in both tooling and process over the last six months, an insanely small period of time, is start by writing a four-page prompt on exactly what to deliver. You do if you’re using a less expensive, more run-rate type model rather than a frontier model, but then just have a frontier model write the spec for the run-rate model. You’ll never be as good as an LLM at generating prompts, right?

[14:57] – Scott Robohn: Well, I’ve layered in a technique where I basically ask the LLM to interview me. I’ll bring a page and a half of intent that’s reasonably detailed, and if you’re using the process to develop all the right markdown files for SDD, number one, it’s cheap. I know there’s token cost here, but I’m creating human-readable documents that I can validate and verify after I’ve gone through an interview process. And I heard a great comment last week: the code is free, in a sense. We’re used to thinking about ourselves laboring to get the code just right, but now we’re asking agents to write the code, and we can iterate, and we can throw away stuff that looks like garbage. And you still have to have enough domain knowledge to know that it’s actually garbage, right?

[15:52] – Andrew Wertkin: Exactly. And that last point is, on the personal side, sort of my fear of what everything looks like in 10 years, but it’s also the most critical thing now. Without the domain knowledge, and the experience and expertise of how things can fail, how things should work, how they should gracefully fail, and on and on, you’re asking for trouble. But yeah, I like that, and I do that too, probably in a less regimented way than you do, but that sort of, “What am I not thinking about here?”

[16:29] – John Burke: Exactly. What else could go wrong here? And when the LLMs are just as happy to bring you the deadly poisonous mushroom as the tasty, edible mushroom, and they look the same [clears throat] to a casual inspection, that kind of domain expertise becomes irreplaceable and absolutely necessary.

[16:50] – Andrew Wertkin: Yeah. And here’s what happens, and why process is so important here: people sit down and they think they’re on the same page with the LLM, and over a couple of weeks it seems to be true. It seemingly remembers stuff. And then on day seven you start a new session, and it seemingly forgot everything it ever knew, and it’s been sort of degrading over the week because you haven’t been documenting this. You haven’t been saving the appropriate memories and making sure you’re updating your prompts and everything else. And then it makes a decision that is unbelievably naive, and because we humanize these things, you have this thought of, “Am I working with a doppelganger? Who is this person I’m working with? How is it possible they forgot this?”

[17:34] – Andrew Wertkin: So there are a lot of errors that occur in those moments when the operator, developer, network operator, whoever is using it, is unclear about the state of the session’s memory and assumes that, not necessarily something deterministic, but something at least informed by things we’ve done in the past is about to happen. And then, surprise. And what do we call that? Part of it is just a rediscovery tax. I’m going to spend a lot of money, as in tokens or credits or whatever, rediscovering the same thing over and over and over again because it’s not appropriately documented.

[18:22] – Andrew Wertkin: And these are things that the LLMs in general, depending on the coding tool, are really good at. I tend to use Claude a lot, but regardless, I’ve used several. Every time I end a session, I ask: What did we do? What did you have to rediscover? And of what you had to rediscover, what should we appropriately document so you don’t have to rediscover it again? And that’s not everything, because experimentation works. Sometimes you learn a ton when you make mistakes.

[18:54] – Andrew Wertkin: And maybe going back to the personal, but still professional, side of hardened software: software that works, as we say, in anger. It doesn’t just work in the lab, it doesn’t just work in the happy cases. It works. Put pressure on it and it still works. Getting to that point takes experience from having done it, but specifically from having failed at doing it.

[19:21] – Andrew Wertkin: It’s like something smells bad because you once made that error before, or you were around when that happened. And that kind of learning is very specific to the very large context sizes of our brains. You don’t even have to go review your notes. You’ll spot that pattern immediately if you’ve had the experience of failing. It’s just wired in. And I just don’t know how those things are going to happen without purpose. Without purpose.

[20:08] – John Burke: And I sometimes hear people saying it won’t be too long now before we won’t even be having AI develop these scripts or these programs for us. We’ll just tell it what we want to have happen. It’ll spin up a program in the background, send it off, and get the thing done. And the next time we need it done, it’ll generate a program and send it off to get executed, and we’ll be done. So it won’t be creating automation for us; it’ll be the automation.

[20:34] – Andrew Wertkin: Sure.

[20:34] – John Burke: And for me, I think what you’re saying right now is the pushback on that. It’s like, okay, but the second time it sees this problem and it’s time to generate a program to solve it, is it going to remember how it solved it the last time? Is it going to remember what went wrong and how it got fixed? Maybe, maybe not. I think until that problem is resolved, and resolved by stuff that works in anger, as you say, so that no matter how mad I am when I type the prompt to the AI, it’s still going to give me the right answer and the good answer, then it’s not solved.

[21:08] – Andrew Wertkin: Yeah, then it’s not solved. And the only thing I was going to add to that is that you run into the opposite problem, because the LLMs are basically matching patterns. And so if something looks like it fits this pattern, it doesn’t mean that’s the answer. And ironically, if you only have a couple of cases of this sort of thing, like, you know, something failed, here’s why, I know the pattern, then it’s more likely that something is going to get force-fit into that. They’ll pound the round peg into the square hole if it almost fits.

[21:52] – Andrew Wertkin: And I think there’s still a bit of a chasm, especially in the world of brownfield, between “Right, I’m just going to state my intent, and the scripts will be written, stuff will be done, I’ll never have to look at this twice” and that actually being done in an enterprise network, where you don’t have all the tools today to get that done. You don’t necessarily have the budget today to get that done. And you have history, and that history includes things that are not good in the world of AI, which are things like tribal knowledge and one-offs. And, you know, this was done for a very specific reason, but there’s yellow tape around it. Nobody knows why, but we just know that if we change it, everything breaks, so we’re not changing it anymore. This was never documented. That wasn’t documented.

[22:43] – Andrew Wertkin: So I just go back to one of the really well-known foundational books in software development. Tools and tactics have changed, but this book is as true as it’s ever been: Martin Fowler’s Refactoring. I think in the foreword, in the first couple of paragraphs, it says if you can’t test, put this book back on the shelf. I’m paraphrasing, but it’s something close to that: you can’t change it unless you can test it. And in this world of tribal knowledge and one-offs, and not everything following a pattern, how are you going to approach that? Especially if there’s nothing to test against. Your lab doesn’t have those one-offs. With your lab, it’s: how do we actually test this appropriately?

[23:39] – Andrew Wertkin: And that’s what causes all of this longer change management process. The organization has learned that if we touch that, it’s going to break. So that’s only going to happen in this type of change window, where we have three and a half hours and nothing else can be scheduled during that change window. They’ve never fixed the underlying problem; they’ve wrapped process around it. And so companies, enterprises, are also going to have to look at where to start with this stuff. And stating the obvious, net new is built this way to begin with. Great. Changing something that exists, whether that’s software or network architecture, is way harder for humans and LLMs. But at least the humans hopefully have some of the tribal knowledge.

[24:33] – Scott Robohn: So another exciting thing that I think is in front of us here, to your point about everything you just laid out: if I have an LLM, everything looks like a prompt, right? And I think many of us are figuring out that not everything is a problem for an LLM. We have this really interesting and potentially useful set of new computational techniques in front of us, and we haven’t gotten rid of all the others. Machine learning is still really useful for other things in the AI space. Statistical regression, last I checked, doesn’t really cost me any tokens, right?

[25:11] – John Burke: Right.

[25:11] – Scott Robohn: So I’m adding to the tools in my toolbox. And the really fun puzzle that’s going to be in front of us all is using the right tools for the right job here: LLMs where they make sense, ML where it makes sense, regression where it makes sense. Maybe for the problem you called out, of reinventing the wheel every time the question is asked, part of my constraints could be: okay, I’ve solved a problem and I’ve put it in my IT service catalog. And if there’s something in my service catalog that is a 90% or better match for this prompt, use what’s in the service catalog and don’t spend tokens on creating another solution for it. Right? And I’m riffing here, right? But I think these are all approaches we need to put on the table as we collectively figure this stuff out. And I’m much more positive about it than I am cynical about it. Check in with me in a year and see if I say I feel the same way.

[26:05] – Andrew Wertkin: So no, it’s interesting on that service catalog side. I mean, the good news is you can just have the LLM check to see if you solved this problem before, and again, they’re super good at matching patterns. They’ll find something. And actually, of all the techniques I’ve developed over the last year, let’s say, that tight link between documentation of what I did and what I actually did is [snorts] super valuable, both from the perspective of…

[26:43] – Andrew Wertkin: Quick story. Years and years ago, I was CTO of a company in the application lifecycle management space. So we built software to help build software, and part of our ideal customer profile was in embedded software that was safety-relevant, where a defect could cause harm to the operator, for instance automotive, or you name it.

[27:08] – Andrew Wertkin: And so in that world, there are all sorts of standards, like ISO 26262 and Automotive SPICE, and on and on. And part of the standards is that there must be traceability between requirements and code, right? And if the requirements change or the code changes, that trace becomes potentially problematic, and I’m going to have to go in and look for any of those impacts. I’m going to have to say, in this change, by the way, I changed the code, but the requirement is still correct, the test case is still correct, and the architecture is still correct. I’m going to have to go do that for all these suspect traces.

[27:38] – Andrew Wertkin: And you’re not going to convince somebody building B2B software that they need that level of traceability, but I do that when I’m doing LLM-based development, because it’s amazing. One, well, I mostly enjoy it, but also because the LLM then goes and traces, and the LLM can quickly figure out why we did something the way we did it, because it can trace back to the documentation. And the LLM is writing that documentation, and the LLM knows to write the documentation for itself.

[28:14] – Andrew Wertkin: That’s something that, even if… Sometimes I will say, write this for a human. Sometimes I’ll say, write this document for a customer who may or may not be aware of how software development works, or may never have installed Python before, whatever the case might be. But oftentimes with those docs, I’ll say either include an addendum just for an LLM, or just write this for an LLM. And one, it’s terser, but two, LLMs are pretty good at writing documents for them to read, both from an efficiency and a cost standpoint of reading it, right? The human version is more expensive.

[28:57] – Andrew Wertkin: But regardless of that, it also goes to this: okay, now, in addition to writing software for the next person to maintain, I’ve included writing software for the next LLM to maintain, and giving it, obviously, the capability to pull in and parse a lot of text rapidly. Yeah, I’ve never had better documentation in my code or outside of my code. I would never have done this much documentation as a human, ever, with the assumption most humans have while they’re writing it: “Yeah, I’ll remember this. Yeah, this is pretty easy to read. I’ll just read the code, it’s obvious,” or “Anybody would understand what I meant by that.”

[29:46] – John Burke: Yeah, exactly.

[29:46] – Andrew Wertkin: Yeah, I said “sorting.” “I’m sorting here,” you know. And those things lead to a tremendous amount of defects, but so does, even worse sometimes… What’s the old adage? The only thing worse than no internet connectivity is crappy internet connectivity.

[30:05] – John Burke: That’s right. Yes.

[30:05] – Andrew Wertkin: Yeah. It’s the same thing with documentation.

[30:05] – John Burke: So in a way, you’re both mentoring your AI to improve its domain expertise, teaching it more about what it means to run a physical network of physical devices, what the risks are, what the limits of experimentation are and so forth, and at the same time you’re mentoring it on being a good team member by doing things like documenting its code and explaining itself.

[30:42] – Andrew Wertkin: For sure. No, it’s a good analogy, because that’s what I usually advise people, especially if they’re senior: just imagine you’ve got four junior to intermediate software developers working with you who are pretty self-assured, who are convinced they’re correct. So if one of them said to you, “Now, this is the best way to do it,” you would say, “Why? What evidence do you have? Do we have enough evidence? What alternatives did you pursue before you came to the solution?” If you think about your interactions like that, then you’ll always think about the right question.

[31:32] – Andrew Wertkin: In terms of its ability to generate code that works rapidly, this is not a junior or intermediate software developer. But in terms of thought process, in many cases an intermediate software developer has a better thought process. In other words, it’s thought process. It’s not pattern matching and the other magic of LLMs.

[32:00] – Andrew Wertkin: I think that’s the biggest mistake. Whether it’s bias, confirmation bias or otherwise, people are looking for that sort of positive “this is how we’re going to do it.” And if they say, “Hey, I was thinking about this. Is this a good idea?”, we all know that’s the worst way to interact with an LLM, because it’s going to happily come back and tell you, “Brilliant. Wow. Yeah, you are so smart. That’s the best way I’ve ever heard.”

[32:33] – Scott Robohn: Just include “no sycophancy” in every one of your prompts.

[32:38] – Andrew Wertkin: [laughter] Yeah. No, 100%, do that, because I don’t need that from my peers, my employees and my parents, so I definitely don’t need it from an LLM. But I do like it from my wife every once in a while, and from my kids, definitely. But regardless of that, yeah. That idea that you are the expert here, and you’re working with something that has less knowledge than you do of what you want to create, how it should work, what success looks like and how it’s failed in the past: just keep that mindset. Keep that mindset. Keep that mindset.

[33:12] – Andrew Wertkin: And then at some point you feel like you’ve got the four best interns in the world working for you, because to me that’s what they all are. Maybe five, sometimes seven. But it’s the acceleration of being able to get this done tonight: “Please launch 10 parallel agents.” I wouldn’t say please, by the way. “Launch 10 parallel agents and run through our blitz testing protocol.” And then I wake up in the morning and a whole team has been doing work all night, and I don’t feel guilty. I have my coffee and read through the results. It’s very powerful.

[33:51] – John Burke: Yep. And I think you’re sort of saying, by implication, what vendors like you can do to support this kind of work in enterprise network shops, and that is basically building the power tools that those AIs can wield, with appropriate safety features. So the circular saw has the automatic shutoff, so you can’t cut your own fingers off as easily as you used to be able to. Things like that. You want to help them not crash the network by failing to do the obvious things with your power tools.

[34:29] – Andrew Wertkin: Yeah. No, it’s interesting, because like most software vendors today, one of the things we produce is MCP servers for our back-end products, and we have several back-end products. And I think, like a lot of vendors out there, initially that was just, “Okay, let’s wrap up our OpenAPI tools in this new protocol and we’ll just expose that, and the LLM will figure it out.” And you realize pretty quickly that that’s not the right approach at all. You’re just going to waste a ton of tokens. There’s going to be a ton of guesswork. You just sit there watching the LLM guess and guess and guess.

[35:03] – Andrew Wertkin: Yes, an LLM can pretty quickly figure out how to use a REST API, and if it’s wrapped in MCP tools, even faster. But that doesn’t mean it understands your domain. And yes, the frontier models especially have been trained on not just your domain; they probably understand more about your product than you might realize.

[35:33] – Andrew Wertkin: But part of what we deliver is not just tools that are more domain-specific than an OpenAPI. It’s having more conversation between the MCP server and our back-end server than the LLM sees. Take a packet capture, for example: there’s no reason to send the LLM a 20-megabyte packet capture. That ain’t going to do anything. Or to send it a whole time series that you should be sending to ML, not to AI. So how do I get it the data it needs? Summarized data, maybe even opinionated data, because we know our systems well, so with sort of opinions built in.

[36:15] – Andrew Wertkin: What does the LLM need to answer the user’s question, which might have been, “Why doesn’t this work?” Think through that stuff, as opposed to just… I’d use the word lazy, but naive is the better word. It’s naive just to assume the LLM will figure this stuff out well, especially if you want this stuff to be remotely repeatable. So yes, we do that, but it’s way more than that.

[36:39] – Andrew Wertkin: Now, we just went through the software development stuff, and our customers can now pump out tons of automation scripts and otherwise against our products. Super. How do we encode the best practices for doing that, so our customers don’t automate themselves into downtime? So that they know. And that comes out in things like network advisors and other things, whether through prompts or specific code or capabilities or training material, that help our customers succeed at automation. Because in our industry, on the DDI side of our industry, in the world of DNS and IPAM especially, the tailwind of this industry has always been automation. You have to change this stuff faster. And so we want our customers to be successful.

[37:30] – Andrew Wertkin: It pains us. We had a customer a few years ago, well before LLMs, and this goes back to an example of the harm that can happen if there are no processes around the way you develop software. They were sort of teaching themselves how to script against our product, and they had an administrative user. They wrote a script, went to test it, and deleted the entire DNS environment inside this company, which immediately locked them out of systems. Active Directory was down, and they were using that for LDAP, and yada yada yada. Glass had to break.

[38:05] – Andrew Wertkin: And they’re sitting there, and I can imagine. I’ve had that experience before. I think once in university I wrote an endless loop in an application running on an old IBM PC, where you couldn’t Control-C. Three hours of work, and the only thing I could do was reboot the computer. That’s one of several examples, some of them professional, of that sort of sinking feeling of “oh crap.” [laughter] Yeah. And I can imagine what was going through that guy’s head.

[38:42] – Andrew Wertkin: And so, yeah, obviously that’s an extreme example, but my point is, we always get asked in software development about metrics and measurements, and somebody always goes, “Well, you guys just use lines of code or something,” and that’s like…

[39:00] – Scott Robohn: That’s right. Yeah. The idea, for anybody in software engineering, that the number of lines of code they wrote, the more the better, is an appropriate metric is insanity.

[39:13] – Andrew Wertkin: Right. So we don’t do that, and nobody suggests it. But my point is, when you start thinking about the right metrics, certainly in the world of SaaS, but now also in the world of these scripts, it’s not just about that. The question is, did it work the way we expected it to? Was this a successful automation? Right? And what did we learn from what didn’t succeed, and how do we bring that back in and do a feedback loop? I mean, the fewer lines of code to solve a problem, the better, but mostly: did it actually solve the problem?

[39:52] – Scott Robohn: Well, and going to fewest lines of code as the other metric could cause other problems, right? And again, one of the things I’m really jazzed about in this whole environment and conversation is that the art of specifying our constraints is becoming much more important, probably more than it ever has been in our careers, right? We’ve got power tools. Where are we going to put the right blade guards on, and the grounding plug? My grandfather made power tools for Porter-Cable, and I actually have some of his old prototypes that I would never use to build a deck, because there are pieces missing that keep me from losing digits.

[40:27] – Andrew Wertkin: Right. Yeah.

[40:27] – Scott Robohn: So the systems thinking, and there’s tribal knowledge somebody else is going to…

[40:34] – Andrew Wertkin: [laughter] For sure.

[40:40] – Scott Robohn: John, this could go so many ways. Where do you want to take this?

[40:40] – John Burke: Well, I think just to round it out, I want to follow through on this idea that folks in the business now need to be thinking about their software portfolio as power tools that will ultimately be wielded by robot hands, not human hands, and how that’s going to change the enterprise software landscape. We’ve talked a bit about how it changes process inside the enterprise for using it, but what about the rest of it? Does it change licensing? How else does it change things?

[41:18] – Andrew Wertkin: For sure. I think part of it is what you’ve seen in the stock market, and in the private markets in general, with the devaluation of some software companies, which, well, we all should know the stock market is its own thing.

[41:33] – John Burke: Yeah.

[41:41] – Andrew Wertkin: But outside of that, for sure it’s going to change licensing models. If your licensing model is just based on per user, and I’m not saying that’s because everybody’s going to fire everybody, I’m just going to say, okay, what’s an agent? Is an agent a user? Companies are going to have to figure out what the right metric is going to be. A lot of companies are switching to, okay, it’s going to be credits, and the real value is how much you’ve pushed through this LLM. But enterprises don’t like surprising bills every month.

[42:20] – Andrew Wertkin: They like consistency. And I think early on, especially the LLM companies themselves, or the AI companies themselves, are obviously very focused on an opaque, credit-type model where we all know the price is going to keep going up and up. We won’t be able to do that. Networking vendors won’t be able to go in there and say, “Oh, sorry, your bill this month is twice as much, because we’ve changed the ratio between credit and token. And by the way, we improved our stuff, so it’s better, so you’re going to pay more.” It doesn’t work that way in our world. So yes, I think licensing models are going to have to change.

[42:57] – Andrew Wertkin: But it’s so much more than that. You know how we always go back and forth between platform and best of breed, platform and best of breed? I think we’re going to be heading back towards best of breed, because interoperability between different products has become much simpler to solve, especially with things like MCP. I don’t necessarily think I need a specific integration to ITSM systems anymore, because all the ITSM systems have the ability to speak MCP.

[43:43] – Andrew Wertkin: That makes picking between a platform and best of breed easier. So in certain areas, it’s going to be disruptive to businesses whose only goal was to put as much stuff in their platform as possible, and nobody would be able to compete with them. That’s going to change, and I think… Should I launch into this?

[44:05] – John Burke: Yeah.

[44:05] – Andrew Wertkin: I’ll do the 60-second… the 30-second version.

[44:10] – Scott Robohn: 30 seconds. Yeah.

[44:10] – Andrew Wertkin: Yeah. It used to be that in the world of big, ugly central systems that nobody could change, like the big ERP systems, companies would say in their earnings reports, “We missed it this quarter because of a bad upgrade to this massive internal system.”

[44:29] – John Burke: That wasn’t that long ago.

[44:29] – Andrew Wertkin: Yeah, that wasn’t that long ago. And that was the whole Salesforce marketing campaign initially, with the “no software” and “we’ve got that for you” and all this greatness about SaaS.

[44:40] – Andrew Wertkin: In that world, how those systems started getting disrupted was all these new companies bringing SaaS-based systems that were easy to use. The big systems were still the system of record, but here’s this new system of engagement for HR, for travel management, for purchasing, for whatever part of that system. And then of course the large companies in that space would just go buy those companies, one after the next after the next after the next. To some extent, I’m not quite sure acquisition is going to happen; there’s going to be way too much to acquire. You’re going to see a lot of companies coming up with system-of-engagement-like value propositions for existing platforms out there, to slowly start taking user engagement or system engagement away.

[45:28] – Andrew Wertkin: And that’s going to happen way faster than it did with travel management and goals on the HR side, or purchasing, or whatever these systems of engagement were that started doing this to large internal systems. So in a world where it’s simpler to disrupt, or at least do better, a small part of an existing platform, with the integration almost laid out for you, I think that’s going to drive us back to best of breed.

[45:54] – John Burke: And I can even envision taking it really far down that path. Only the AIs that work for us really understand what the software portfolio currently is, because a new service pops up and they see that it can do half of what they need to do in functional area X better, faster, cheaper. So now I’ve got two things in that area, and the AI is the one managing which work goes to which one. It’s like a redundant array of software vendors kind of approach. I’ll just arbitrage wherever it works best against the criteria that my AI understands matter the most to me: saving time, saving money, better performance, whatever.

[46:36] – Scott Robohn: Yeah. Interesting.

[46:42] – Andrew Wertkin: Yeah. Because go to some expo floor in tech these days, especially in networking, but pretty much any tech-related area, and you’re going to see company after company after company selling their platform for AI. No matter where they came from, they now have a platform for AI that’s going to be multi-vendor. Why not? Everybody’s got MCP servers. So what are you going to have as an enterprise? Multiple platforms for agentic operations? A single platform? One meta agent that manages a bunch of other agent platforms? What if I put the wrong one here, and how quickly can I change?

[47:25] – Andrew Wertkin: And seemingly, and I don’t understand this part because it’s not the way I work, people do have easy bias as well: “Oh, yeah, they said they can handle this all for me, so I’m just going to buy that.” And it comes down to this theme. It’s funny, earlier I gave a real example: I had never written an eBPF in-kernel-space high-speed logger, and now I have. I still couldn’t write one. I used that as an experiment: what if I follow this process in an area where I’m well aware of how the stuff works, but I’ve never actually written software there? What will I learn?

[48:05] – Andrew Wertkin: What I learned was how rapidly I can do something that I didn’t know how to do ahead of time. Just by establishing the things we were talking about before, like criteria and exit criteria and the things I’m concerned and worried about, I have something that works. I don’t know if it’s the best way to solve the problem I started with. All I know is it’s maintainable code that works. I mean, I know more than that: it’s really well documented. So I guess my point is, people still need to learn this stuff, to bring that experience forward.

[48:48] – Andrew Wertkin: And as much as I appreciate this technology, that’s my biggest fear. The worst mistakes always start when somebody believes they’re right, and people are either too intimidated, too starstruck, too awed, or just too lazy to question the person who for sure knows how to get something done. And the end result is things that could have been prevented that cause problems. We see that across everything from tech to social environments to everywhere else; groupthink, or…

[49:27] – Andrew Wertkin: But that’s what I rely on my experts for. Even if it sounds right to them, in fact, the more right it sounds to them, the less likely they are to take it at face value, because there must be something wrong with this. What is it? It’s a puzzle. These are engineers, in many cases. So as much as I appreciate the technology, use the technology, push forward with the tech and create value with the tech, there’s part of it that just makes me uncomfortable.

[50:12] – John Burke: A solidly cautionary note on which to end the conversation.

[50:12] – Andrew Wertkin: Yeah.

[50:18] – John Burke: Thank you, Andrew, for joining us today. This has been fantastically interesting, and there’s lots for the enterprise strategists to chew on as they think about how things go next in their IT shops. Scott, thank you so much for joining us today as well. And as always, thanks to everyone watching.

[0:03] – Host: [music] Hi, I’m Johna Till Johnson, CEO of Nemertes, here with my co-host, John Burke, CTO of Nemertes, and you’re listening to Heavy Strategy, the show that tries to ask the right questions, not give the right answers. We’re here with Ronny Wolf, Field CTO for EMEA at BlueCat, to talk about why open platforms matter in network operations.

[0:20] – Host: And Ronny, network operations is such a huge space, and I know this is the space that BlueCat operates in. I know many folks are familiar with BlueCat, at least from a couple years ago, but some listeners may not be. Can you give us a quick overview of the space in which BlueCat specifically operates?

[0:40] – Ronny: Oh yeah, for sure. I mean, BlueCat Networks traditionally comes out of the core DDI business. So DNS, DHCP, IP address management. So basically all that boring stuff, right? What everybody needs to deal with. However, we’ve seen in the market the demand, or the requirement, to expand that platform. So not just the core network services. I mean, network operations is all about keeping the lights up, right? So not just providing the service, but also knowing what happens within the network.

[1:20] – Ronny: And through a couple of acquisitions over the last couple of years, we expanded our portfolio in network observability, in network packet capture, in infrastructure assurance solutions, and we built a platform around that, which we are calling right now intelligent network operations. Which basically combines both sides: providing the core service, and really not just keeping the lights up, but knowing exactly what is within the network and what is the root cause behind that.

[1:55] – Host: Got it. So it’s expanding beyond the core DDI to understanding what’s actually happening in the network. And before we talk about how you do that, just a quick bit about what does the field CTO actually do? What do you do day in, day out?

[2:06] – Ronny: Yeah. I would define a field CTO here at BlueCat as a bridge between the customer and our strategy office. So I’m not aligned to a sales office or something like that. So yes, for sure we also have a sales motion within BlueCat, otherwise we are not able to earn any money. However, we are there to listen to the customers, to really understand their requirements, and not just on what we provide as BlueCat, but also what drives them. What drives the different entities or the different business units: security, again, network operations, the architects, and things like that. We try to listen to that and basically then try to get that into the strategic direction within BlueCat: where our products are heading, what we need to change, and how we can help our customers.

[3:05] – Host: So your job basically is to understand the challenges your customers are facing and encourage the company to develop solutions ahead of those challenges becoming super acute.

[3:13] – Ronny: Correct.

[3:19] – Host: Okay. And I know we talked a little bit during the planning sessions that one of the key components to open networking is using APIs and being API-first. And you had mentioned that internally, while you were integrating those acquisitions that you made, BlueCat began to use APIs for modular development, so that you could develop behind the APIs and keep everything glued together. And you’re going to talk a little bit about that for network operations. So how did that work within BlueCat, and what were some of the lessons learned from BlueCat that you’re actually taking to your customers now?

[3:50] – Ronny: Yeah, I mean, especially our strategy office was for sure a big part of that initiative. When we listened to our customers… I mean, we started as well with some kind of a siloed approach. Think about that: we are providing a core service, our bread-and-butter business, our customers were happy, and so on. However, we recognized that their requirements were changing, with additional initiatives. So security, automation, integration. I mean, there is a huge portfolio of what customers are looking to integrate into, especially if we want to be a single source of truth, if they want to follow a platform approach, and so on.

[4:38] – Ronny: And what we recognized within BlueCat, even if the solutions were proven and customers liked all of these functionalities and features, we got to our limits. Where we’re not able, first of all, to act fast enough to turn that into products or into integrations. And on the other hand as well, we limited ourselves by having this kind of house divided. There is a user interface, there is an automation or an API, different platforms, different usage, different APIs, different user interfaces, and stuff like that. There was no corporate identity we could enforce, because everything looked like a puzzle which doesn’t really fit together.

[5:27] – Ronny: And we started that initiative, I would say, three, four years ago, round about that. I mean, we started planning way before, but then we really looked into our products. What do we need to change? Do we decouple front end from back end, for example? So that everything the end user has, a business process in mind, how our users are using it today, how can we turn that into an automated approach to help our customers get that into their asset management, into their IT service management, into all of these adjacent platforms they have in use. And from then on, we did not develop the API platform just with ourselves in mind, to develop a user interface on top of it and that’s it. We also developed it with in mind that customers really can use it to integrate and to automate much faster.

[6:25] – Host: So how do you differentiate between having products with APIs and making APIs the center of development internally? What’s the difference between having an API and being API-first?

[6:47] – Ronny: Yeah. [clears throat] So having an API basically comes when, hey, you want to have a new button in a user interface, or whatever new functionality, and then in development the requirement is written down, a certain service ticket or Jira ticket is created, we have the user story behind it, and then they start to develop an API. Does that really fit into some kind of standards, or a really combined, unified approach? No. There you have an API, and you have a little bit there, and maybe, okay, we need to combine that, and, oh, we cannot turn that into an API, so let’s have the user interface go directly to the back end, and things like that.

[7:33] – Ronny: And that is really the difference, because for a customer, even if you can say, hey, potentially there are developers, or at least someone who can write scripts or something like that behind it, they need to know the programming language and paradigm and models and things like that. It gets really hard to understand and also really hard to maintain. We are not talking about a one-time approach, right? They need to keep that basically over the whole life cycle of a product, of their platforms.

[8:03] – Ronny: And with that, an API-first approach is basically to really develop APIs. Everything you see, everything you can do with the product, is an API, and then we build the front end on top, whether it’s a user interface or a command line or whatever it is. And can a customer really see that difference directly? That’s difficult, right? Because everybody says at the end, hey, we have an API, for sure you can connect to it. And that is for sure also a challenge we see quite often when we discuss with customers, because the automation, the integration approach, yes, it’s maybe a small part. “Hey, can you do that with the API?” “Yes.” Check mark, and that’s it. But quite often that is overlooked, or not really looked into in detail: can we really do that? And if you have bought the product, if you have deployed the product, and then you see how you hit the limits, you’re not able to integrate, then it gets to workarounds and stuff like that, or we need to pay consultancy quite heavily to get something done that we really required from the business.

[9:19] – Host: It sounds like it might be a difference that’s most visible over time, then, when you see: does the API stay consistent? Does the use of the product in a suite with its other products stay consistent? Things like that start to show up. Okay, that makes sense to me.

[9:38] – Host: Talk to me a little bit about APIs not for integration but for automation. We’re hearing a lot about that from network teams these days.

[9:51] – Ronny: Yeah. Yeah. Automation is nowadays a key, maybe a key requirement, at least, as already mentioned, it’s somewhere in an RFP or in whatever requirement or initiative within the customer’s environment, right? Automation is all about automating our business workflows. And also here, as mentioned before, if a customer has a platform like BlueCat, or it doesn’t matter which kind of platform they have in use, they know their business process. There are multiple different platforms involved. As an example, IT service management: a ticket gets opened. Then it gets into the platform itself to turn that into some kind of action. And maybe it’s not a single action; maybe there are multiple actions that need to be done. As an example, on the BlueCat side, a network needs to be created, plus the virtual machine needs to be provisioned, or something like that, on top of it. And these kinds of business processes need to be turned into an automated fashion, with as little manual interaction as possible.

[11:08] – Ronny: If I think about it, I mean, 10 years ago, when I was an IT administrator and things like that, when we created a service ticket to get a change done, it easily took 24 to 48 hours until that was turned into action. And is that really what users and customers expect today, in the era of cloud, of getting capabilities on demand? So it needs to be automated, to change faster, and also to enforce some kind of standardization.

[11:48] – Host: Right. Well, and also, what I’m hearing is part of the benefit of doing automation this way is to not just do the one thing, but any one change is going to have a bunch of ancillary workflows that need to get done to make sure that change is done correctly. So even if it’s something very basic, you make a single change and then test that it worked, or test that it didn’t change anything else. And in a lot of cases, it’s not so basic. There are a lot of other tests that have to happen. And having APIs present makes it easier to do that constellation of processes when you make a single change. Am I getting that right?

[12:28] – Ronny: Absolutely. You get it absolutely right. And especially here you see the difference between an API-first platform and “yes, we have an API in a platform,” which you then automate to a certain extent. And as we’ve also seen with customers, it’s not just the team we are talking to. It’s different teams who have different requirements. This workflow is not, in our business, from the DDI administrator or network administrator. It’s the security guys, it’s the business itself, the application owner, whatever, database, front end, web shop, whatever it is, right? They have that requirement. A DDI admin is not able to oversee completely how that process is working. He knows his discipline, and everything surrounding it he is not aware of. But the platforms need to support that. And if you start with that and then you reach a limit where you say, oh, our platform cannot do that, we need to do that in a different way, first of all maybe it’s costly, or maybe it harms us to really automate end to end.

[13:39] – Host: And it sounds like, then, you’re positioned well with a full API for everything [laughter] to deal with, as a customer, your own organization evolving, and roles changing or workflows changing. It’s easier to tweak automation that’s got access the way you’re providing access, in that event.

[14:04] – Host: How do you at BlueCat distinguish between the APIs that you want to expose to your customers versus the APIs that only get used internally, you know, product to product or module to module?

[14:22] – Ronny: To be honest, there is no difference. Really, everything’s exposed. Everything is an API call. So it doesn’t matter what you see. I mean, there’s one thing we need to clarify a little bit from an API perspective. Everything is exposed to the customer. Do they want to use it? That depends. For sure there are APIs which most of the time are used by our user interface, or for platform-to-platform connectivity and things like that, but they can use them for a certain use case we are not even aware of, right? Or a requirement they have. But what we differentiate, for sure, is we have our back-end system, where a database is, or any kind of back end, which is abstracted from the customer, and that is exactly where the API comes into play, right? We give the guardrails for what they can do with the product, that’s definitely there. However, everything we do is also exposed as a public API, and they can use it.

[15:26] – Host: Which I think comes back to that whole API-first idea, because if you’re saying, “Oh, we have APIs,” that just means that you slap APIs on things that you’re guessing will be customer-exposed. But API-first means you’ve thought through the entire system and its modularity, and you’re comfortable exposing all the APIs to a customer that may wish to use the modules of your system differently.

[15:57] – Ronny: Correct.

[15:57] – Host: And the picture I… oh, go ahead. No, no, that’s fine. The picture I keep getting in my head is of the BlueCat system working as a catalyst for the rest of network operations, because if the heart is correctly engineered, then everything that you layer onto that continues to be correctly engineered as well.

[16:15] – Ronny: Yes. I mean, for sure there are sometimes challenges to do that, because we have all of our user stories, automation and integration stories, what customers potentially want to use, right? Where we also need to introduce additional back-end systems and stuff like that. That’s definitely still a challenge. But this is where the field CTO and the strategy office are there to listen to our customers and to drive that forward, to also be some kind of innovation player in that market, at least.

[16:55] – Ronny: But yeah, I agree with that. The modular approach also helps us tremendously in our own development. We develop a new product, and it automatically registers to our API stack. It gets immediately exposed, because we are using it ourselves, and the customer can use it. So it’s much faster. We have developed so many additional modules in our products, so not the core platform, but additional functionalities on top, or maybe specific use cases for customers, or a specific area we want to address right now, and that is immediately exposed by API.

[17:38] – Host: And something we think about a lot in this context is security, and specifically zero-trust kind of security. So I assume identity and role-based access management of who gets access to which API calls is built in.

[17:54] – Ronny: Oh yeah. Yeah. I mean, that is, I would say, the basics, right?

[18:06] – Host: I mean, you always hope that’s the basics, but sometimes it’s a bolt-on at the end.

[18:06] – Ronny: Yeah. So the basics, in regards to: if you’re turning to an API-first approach, where a front end like a user interface is just a consumer of the API, then the user interface, the front end, basically does not have to deal with authentication or authorization. So it needs to be built within the API itself. So yes, the full API has role-based access. It has all the different authentication mechanisms, from external authentication like IdPs you need to keep in mind. I mean, enterprise customers are using identity platforms like Azure Entra ID and so on, right? They are not using your local authentication anymore, or at least not all of them.

[19:01] – Ronny: You also need to think, not only from the security of your API-first approach, about what happens if someone is misusing your API. Not just a user, an authorized user, because you give them the freedom to basically also break your system. So we need to have guardrails in mind. Rate limiting, for example. We need to make sure, if someone fires a million API calls, because maybe they are not experts, right? Our customers, especially in that area, a network admin, they can script, but they are not developers. Maybe they put something into an AI agent, and a script spits out, and they fire that, and our whole platform goes down. So yes, we need to have guardrails in mind. Again, rate limiting, security posture, behavior tracking, and things like that, to make sure that our platform is still resilient and stable.

[20:06] – Host: And all I could think of was, like, the network operations version of Clippy. “It looks like you’re about to send 10 million calls. Are you sure you want to do that?” [laughter]

[20:16] – Ronny: Correct. Exactly. I mean, even if the platform, or at least our platform… and I also recommend thinking about scalability if customers turn to an API-first approach. But yeah, we have seen that with customers as well. When we released our first iteration of the API-first approach, that was also a learning curve for us: how they use the API, what kind of ideas they get. Because now they basically have all this freedom, right? Where before we had these limited APIs. I mean, we had APIs since the beginning, but it was limited. It was a house divided. And now they had the full freedom to do whatever they want, basically, in the manner of what we are doing, right? And that was interesting to see, and we adjusted.

[21:18] – Host: “Interesting to see,” I think, is a euphemism for “really freaking scary.”

[21:18] – Ronny: Yes. Yeah. I mean, keep one thing in mind. At BlueCat we are focused on network operations and DDI core services.

[21:36] – Host: Right. Otherwise everything goes down.

[21:36] – Ronny: Yeah, yeah. That is important. Absolutely. But we have also seen that customers are using it as a CMDB. They are using it as a monitoring platform. So the DDI platform was used as a monitoring platform, because they pushed information from other stuff into it. So we were not even aware that customers were using the platforms like they do.

[22:01] – Host: Well, it makes sense, because to an extent that’s not true for other CMDB-type systems, what’s in your systems has to be correct, [clears throat] you know? [laughter]

[22:15] – Ronny: Sure. Sure. In the area where we can understand it. So it was not like they turned it into a calendar or something like that. However, it was interesting, where we had not even thought about how they would use it. And with that, the API-first strategy has not changed, but we adjusted it by putting more guardrails into it. Making sure that these critical core services are still able to run, even if someone is hammering it with, as in the example, a million API calls.

[23:01] – Host: Well, and so you’ve talked about sort of defending your core functionality against AI, at least in the benign misuse case. How have you tried to make it friendlier to, let’s say, the professional, informed use of AI to help run a network? What kinds of modifications or additions have you made to make it more AI-friendly and supportive?

[23:28] – Ronny: Yeah. If we start with that: API-first is much easier for AI, and especially, we are talking here about AI agents, so not the LLM behind them or something like that. It’s much easier to consume proper documentation, so an OpenAPI specification, some kind of standards. It’s much easier for an AI to read and understand. [snorts] But do you really want to let an AI agent fully into your platform without really understanding it? Because just by reading specifications of how an API is working… yes, AIs are nowadays quite good at understanding it, or at least interpreting it. But the difficulty is you have no control around that.

[24:27] – Ronny: So what we provided is, I mean, this is now a very technical term, an MCP server. So, Model Context Protocol. I hope our listeners understand. This is basically something… we’ve talked about this… an MCP server is something that sits in front of the API, which moderates where an AI, or an agent, can ask to a certain extent, and gives additional context around how the model works, what it is, maybe also combines certain things the API can do, including additional guardrails.

[25:06] – Ronny: For example, we started the journey of integrating and helping AI with the MCP servers and the API in a read-only mode. So just to gather information, just to learn from our customers, as well as from our internal persona profiles that we basically created and designed, and then testing out how that can work. So we started with read-only first, for reporting purposes, for example, to gather information, to maybe help the end user integrate it into their platforms.

[25:56] – Ronny: But on the other hand, now we have opened that up, during our learning curve, to also be able to make changes. Because keep in mind, the idea of the intelligent network operations platform is also to provide a self-healing network, and a self-healing network is not there for read-only, right? If we need a manual interaction when we see something and some alarm pops up, that is traditional network operations, right? We want to be intelligent, or customers want to have a self-healing network at the end. And with that, we also need to allow an AI to take action, and the MCP servers basically provide the context and also the guardrails for the AI.

[26:40] – Host: [snorts] And sorry, this is a subject we have sometimes talked about in other contexts. Is there a way inside the BlueCat stack to say, for this thing that you’re trying to do, always force some kind of human acknowledgement that this is about to happen, or approval to allow it to happen? Is that built into the stack, or is that in the MCP layer for you?

[27:02] – Ronny: Yes. So what we have, and the MCP servers expose that as well, so that an AI agent, or the model, is able to understand it, is what we are calling change management. So for certain actions, the AI can only recommend, and a human needs to approve. We also introduced something like a two… the two-person principle, sorry, the four-eyes principle…

[27:43] – Host: Person principle. So it’s actually three. It’s like that old science fiction, John… you know, “tell me three times.” Human one, human two, and AI.

[27:53] – Ronny: Correct, correct. So we have certain things, especially when it comes to deleting core network services, or making significant changes on a switch or something in the network, where customers can still overrule that if they want. But by default, BlueCat products ship with that guardrail. The AI shows that in its reasoning: “Hey, I’m not able to do that. Please approve it,” or do the manual step now and click on approve, or do the approval through an API call again.

[28:34] – Host: A nice adjunct to the rate limiting and other guardrails that you’re slapping in there. That’s good to hear. You don’t always hear that.

[28:46] – Ronny: Yeah. I mean, one thing is the guardrails on workflows and whatever the customers intend to do. On the other hand, there are the more technical security parts, with API rate limiting, access control, and things like that. So these are two separate things we are doing in parallel.

[29:03] – Host: Well, and it also sounds like one of the benefits of using that, you know, two-humans-in-the-loop scenario is that it can bridge those silos we talked about. So, you know, maybe the network operator thinks it’s fine, but we have to get sign-off from security here as well, or something like that. So it allows you to get some of that broader context in here.

[29:26] – Host: I’m going to circle back to something you said earlier, because I’ve been chewing on it since you said it. You mentioned that when you first rolled out this API-first approach, you were sort of surprised to see how your customers were actually using the core as a CMDB, for example. And I thought, of course they were, and of course I would be very surprised if I were you. What are some of the things that are surprising you right now that your customers are doing? Like, when you go into a customer site and they’re doing something and you go, “Wow, we hadn’t thought about that, but we really want to consider that downstream as part of our roadmap.”

[30:01] – Ronny: Yeah. So what I’m surprised by is really… if we go now into the core service networking, so DNS and DHCP, traditionally BlueCat is focused on providing its own BlueCat DNS and DHCP service. So customers deploy these kinds of services within their environment. However, with our DDI platform’s API-first approach, and also when we released the MCP servers and what we are calling LiveAssist, but it doesn’t matter, it’s our AI agent, which is focused on the platform itself, customers then turned that into: “Hey, why not also manage other DNS and DHCP servers within it?” So, “I have Azure, or AWS Route 53,” or, “I recently had an acquisition, I want to integrate my Microsoft environment,” or, “Hey, I have a Meraki box over there. Can I integrate that as well?” I mean, I mentioned a couple of vendor names right now, but these are just examples.

[31:24] – Ronny: What was interesting to see then: we see on our bill of materials what the customer has bought, but these environments were much bigger, because they used it for managing third-party platforms, and we were not aware of that. What turned that directly into action, in one of our products, is that we took it and collaborated with the customer and with the vendor. We reached out to the vendor, in that case it was Meraki, and said, “Hey, what are you doing there? It sounds interesting. We want to learn more.” We took that and turned it into the product as an integration, which is now available.

[32:08] – Host: So it’s your Meraki integration, Meraki management capability.

[32:15] – Ronny: Correct. And that was basically from a discussion with a customer who tried to get that done. Again, the platform was able to do that, but it would be nicer if it worked that way out of the box.

[32:34] – Host: Yep. Yeah. And that gets back to the whole API-first idea, because while you were talking I was thinking about the advantages that you were spelling out, and it comes back to when you architect something properly in the first place, a lot of things fall out of that. One of them is that you can add new capabilities much faster than if it was badly designed. And another one is that it can do things you never intended it to do, and do them well and resiliently. That’s actually one of the measures of a good architecture: can it do things you didn’t plan for it to do? It’s one of the great things about TCP/IP. They used to talk about how, you know, TCP/UDP would never transmit video because it just wasn’t designed to do that. But it was well enough engineered that in fact it did. And so I think that’s one of the challenges when you say, “Well, we’re API-first.” It’s kind of like saying, “Well, we did it right,” and the benefits of doing it right you will only see downstream. And I think, John, you even alluded to that: it’s not invisible, but it only shows up later.

[33:37] – Host: Yeah. Emergent properties of a well-designed system.

[33:43] – Ronny: Absolutely. Absolutely.

[33:43] – Host: Yeah. Oh, I love the way you said that. “Emergent properties.” [laughter]

[33:49] – Host: Well, is there anything else you wanted to point out, Ronny? We’ve gone through quite a lot. We’ve talked about the benefits of an open system in network operations and the benefits of API-first. Anything else you wanted to highlight?

[34:01] – Ronny: Yeah, if I have a wish for the audience, and again, this is from experience with a lot of customer discussions and within the customer environments we are in: think about it when you evaluate products and platforms. Think about it not just in the silo you’re responsible for, where you maybe have that requirement right now. Think a little bit broader: what kind of business units, what kind of other audiences within the company do I need to bring in, to really understand how they use it and what additional requirements they have? And then take a deeper look under the hood at how the platform really works. Not just tick the box: “Oh, it does the job.”

[34:51] – Host: That’s… [clears throat] I’m listening to you and thinking exactly in parallel, because it’s easy enough for any vendor to say, “Oh yeah, we’re API-first. Check that box.” What are some good questions that would uncover the difference between someone who’s truly API-first and someone who’s not and is just claiming to be? I mean, when I open the hood, what am I looking for?

[35:15] – Ronny: Yeah. So first of all, I would ask them if they align with certain OpenAPI specifications or something like that. The second one, for sure: if it’s a discussion, not an RFP or something like that… it’s a little bit different with RFP process sheets and things like that. But if you’re in a discussion, challenge the vendor or the provider: “How would you approach integrating with platform XYZ? That is my use case. How can I do that?” And if they just say, “Oh yeah, we can do that,” ask how. “Show me step by step what the process looks like.”

[36:05] – Host: Yes, that makes a lot of sense. And also, if you back up one step, you may have, as a kind of selection criterion, “integrates well with other platforms,” which is fluffy. You may not even have that as a selection criterion, because you may believe that it’s not necessary. But it’s still a good idea to ask about, because everything you believe is necessary or not necessary may change if your company buys another company, for example, or is bought by another company.

[36:37] – Ronny: Yep. So, exactly.

[36:42] – Host: Okay. Well, this has been really informative, and thank you for taking the time to walk through all of this, because I think it’s very helpful to us as well as to our listeners. Ronny, where can folks find you if they want to reach out to you personally?

[36:55] – Ronny: The easiest one is to go to LinkedIn and search for Ronny Wolf, BlueCat Networks, and for sure it will be the first search result, the first match. You will find me there. Yeah, connect with me, write me a message, and I will try to reply as soon as possible.

[37:16] – Host: And come with your biggest challenges, because that’s what you do for a living, is understand customer challenges.

[37:23] – Ronny: Exactly.

[37:23] – Host: Okay. And everyone else, please do check out bluecatnetworks.com to learn more. And BlueCat has requested that you fill out the contact request to schedule some time to speak with a team member about your network and learn a bit more about BlueCat. That’s again bluecatnetworks, with an “s”, .com. Fill out the contact request to learn more. [music] Thanks very much.