Why Open Platforms Matter in Network Operations

[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.