William Collins • 00:10

Greetings, everyone. Thank you for joining us today. I am William Collins, Director of Tech Evangelism at Itential. And I am beyond excited about this conversation that we are about to have. So as many of you probably know out there, we’ve been hearing about network automation for what seems like decades at this point. Yet despite the urgent need and the business imperative really to make network automation a first-class citizen in the broader IT ecosystem, most organizations today, they seem to be stuck in a cycle of… Oh, ad hoc scripting sort of meets open source tooling with maybe a nice DIY bow wrapped around the whole package.

William Collins • 01:03

So, in this session, we hope to shed some light and some understanding on why this is happening. And we’re going to do that by presenting real independent research and also having a discussion with a technologist who was stuck in that cycle and figured out a better way forward. So, without further ado, why don’t we begin with some introductions? Do you want to start us out, Seamus?

Shamus McGiIlicuddy • 01:29

Sure. My name is Shamus McGiIlicuddy. I’m the Vice President of Research at Enterprise Management Associates. I’m an industry analyst. I specialize in network infrastructure and operations research. So my mission as an analyst is to understand the lives of professional lives of network infrastructure and operations professionals. That means I look deeply into what they’re doing with their tools for network automation, network monitoring, and observability, things like that.

Eric Anderson• 02:07

Yep, I’m Eric Anderson. I’ve been in the technology space for close to 20 years now. I’ve been in Armstrong for about 10. I started out in network architecture and then managing the network and telecom teams. And I’ve been focused on network automation, infrastructure automation for about the last three to four years. Awesome. I can’t think of two better individuals to bring in to have this conversation, really.

William Collins • 02:36

So I guess let’s go ahead and get this party started. So let’s start with you, Seamus. Do you want to begin taking us through your research and the findings?

Shamus McGiIlicuddy • 02:50

Sure. So as a preamble, I am continuously surveying enterprise network professionals about their approach to network automation in general. And that research often finds a lot of homegrown and open source tooling. So this year, I decided to go from quantitative research into qualitative research, where I interviewed about a dozen people with network automation engineering or architecture in their job title about their Homegrown approach to network automation. I found people who were doing Python scripts, using Ansible, writing software, using Netbox, using all kinds of homegrown and open source tools without any sort of vendor engagement to build out automation tool sets for their users. And my goal was to, across all these in-depth conversations, I talked to these people individually, one-on-one for 60 to 90 minutes at a time, just everything about their motivations and their experiences with these homegrown tool sets, so that I could find some common themes and answer some questions that you see on the left-hand side of this screen.

Shamus McGiIlicuddy • 04:13

On the right, you see the actual cover of the research report I wrote, but on the left, you see, you know, the goal was to say, explore: like, okay, you have a homegrown network automation approach. Why did you choose this DIY strategy? What are the biggest pain points associated with that approach? And what value could a vendor possibly bring to you? Like, you know, whether you believe in working with a vendor or not, like, what could they do to actually help you improve your overall approach? And so the report, you know, found some key, like highlighted the key themes I was hearing across those dozen plus conversations and just came up with some recommendations, lots of quotes from the people in the interviews as well to sort of give you context of what they’re talking about. So that was the gist of the report.

Shamus McGiIlicuddy • 05:11

So this slide isn’t necessarily from the report I was just talking about. It’s actually from the most recent survey-based research I did about 10 or 12 months ago, which found that 57% of people who were engaged with and responsible for their network automation tool sets were using open source software with no vendor support. And 64% were using custom code, meaning scripts, but also they’re writing software. So that shows you that. Most enterprises today have some kind of DIY network automation going on right now. There may be some vendor solutions at play in those environments, but the ubiquity of DIY network automation made me want to explore why they’re doing this. I mean, in surveys, I would ask them why they’re doing it, but I wanted to get deeper into one-on-one conversations with people about why they’re doing this and what could change their approach towards more of a vendor-supported solution that, you know, reduced their administrative overhead and allowed them to sort of benefit from a support model from a vendor, things like that.

Shamus McGiIlicuddy • 06:33

So that was my, that was this, this, this was basically the trigger for the research, just the, the, The absolute ubiquity of homegrown automation. There’s a whole conference dedicated to why is this happening? If you’ve ever been to AutoCON. And yeah, so I wanted to sort of provide answers to enterprise decision makers. Why is this happening? Should I let it continue to happen?

Shamus McGiIlicuddy • 07:07

Is there a better path forward? So you see here some of the reasons why the status quo may need to change. Scripts rule the trenches, but platforms hold the future, as this slide says so boldly. There are challenges and inclinations in the data that sort of told me that I needed to dig deeper with the new report that we’re talking about here. 61% of network teens who have DIY network automation in place today said they are spending six or more hours each week just maintaining and debugging those homegrown tools. So that’s a lot that’s a lot of overhead. I mean, you consider the fact that a lot of the the skill sets for this kind of DIY automation

Shamus McGiIlicuddy • 08:02

Is hard to hire for. You need to have less overhead around those tools, I think. For instance, in doing this research, I talked to one network automation engineer who told me that she was hired as part of a team of three people to write Python scripts, right? And just tackle different use cases for network automation with Python. And then two of the other two people were laid off or quit. And management was like, we’re not filling empty seats right now. So now her job was not to write new Python code, but to maintain the code that was already written.

Shamus McGiIlicuddy • 08:45

Not great, you know? And then on the other side of the slide, you see 64%, the IT leadership view, as it says. That’s the number of IT organizations that are seeking low or no code network automation solutions to drive standardization and scale. So like. You’ve got situations where every time you need a new feature in a network automation tool set in a DIY capability, in a DIY environment, like that requires more coding. Oh, yes, we’d like to be able to do this. Okay, I need to go build it.

Shamus McGiIlicuddy • 09:20

I’ll see it in a few weeks. That’s not a scalable approach unless you have lots of coders available to you who know both coding and networking, which is in itself hard to find. The dual hybrid skill set is very hard to find. So you see this recognition from CIOs and director-level people that they want to have low, no-code options for network automation so that they can scale, they can standardize, they can empower people who don’t have coding skills to build automation and workflows and automation platforms so that new use cases can be tackled with less overhead and less delay. There is definitely a desire for change in the data. So now we get into the details of the quantitative, sorry, the details of the qualitative research that I was talking about at the outset. These are the insights or some of the highlights of the insights.

Shamus McGiIlicuddy • 10:29

If you wanted to get all of them, download the report from my Tentral’s website. But these are some of the highlights of the insights that this research found. Automation budget requests is an argument for DIY. So network automation is often new to IT budgets, and justifying that automation spend is difficult. You see a quote on the right-hand side from a network automation engineer from a large collaboration solution provider, someone who you probably use for, you know, video conferencing or phone calls, whatever. So he said, you can make a claim about risk reduction and future efficiency improvements, but it’s very hard to put a dollar value next to that, which means it’s very hard to justify a $50,000 spend on a tool because network automation as a line item in IT budgets is new. It’s a new concept.

Shamus McGiIlicuddy • 11:28

Maybe they had a configuration management solution that was from their traditional network management tool stack vendor. But a tool that enables modern network automation, there’s no history of spending on that kind of thing. It’s kind of like a chicken or egg thing. Like people, when they needed to automate stuff, would write code and they would write some scripts and just automate tasks. And those scripts would live on their laptop and they’d use them when they needed to. But the idea of formalized approaches to network automation where you’re not just like maintaining some scripts on your laptop for your use as an individual network engineer, but actually like delivering network automation as a solution to teams and organizations is new. And so IT management is not used to providing budget for that.

Shamus McGiIlicuddy • 12:24

And the argument for that is difficult to articulate and put a dollar value on. So that’s the number one argument for DIY. Number two, customizability and control. See a use case, build a solution for it. Don’t wait for a vendor to deliver it for you. I can build it the way I want it, and it’s going to work, and it’s going to do exactly what I want it to do, but it’ll take some time. And I don’t have to depend on vendors.

Shamus McGiIlicuddy • 12:51

Like, I don’t need to depend on an individual vendor to automate their tool, their hardware, and then depend on another engineer to automate another vendor to automate their hardware. I can interact directly with those vendors through Python. As this network engineer at a large multinational pharmaceutical company noted, what’s appealing about using just straight Python is that we’re able to interface with different vendor systems and we’re not at the mercy of what the vendor gives us. So, like, I’m using this switching vendors tool, I’m using that switching vendors tool. My ability to automate across those vendors is inconsistent and doesn’t suit all my use cases. I have control, I have customization, I can do it the way I want to across vendors. And then another big one is often the DIY approach is a de facto industry standard.

Shamus McGiIlicuddy • 13:44

Like Python is very much community-driven. There are a lot of libraries with Python that are oriented towards network automation that are shared. There’s a community around it. And then there’s all the open source tooling like Ansible and Terraform and Netbox and other things, Batfish. So there’s no barrier to accessing Python and open source tools and learning about it. There are a large community of users, large communities of users engaged with this and adding value to it. And you can join that community and lean on that community and make friends.

Shamus McGiIlicuddy • 14:25

It’s easier to hire people with these skills because it’s. Because there’s such a large community working on it, usually, it’s just easier to find people that have like Netbox or Ansible on their resume than it is to find a specific vendor that’s only been around for five years or something or 10 years. And then you can build solutions without enterprise licenses. So, no budget, but battle-tested open source software may not be as easy to use as a vendor’s product, but you know. It’s been through the ringer and it works, and you don’t have to pay for it. And then there’s no learning curve associated with a proprietary solution either. As the person on the right, a senior network engineer with a mid-sized financial technology company said, he said, like some vendors have their own proprietary things, like a query language for querying data on their platform.

Shamus McGiIlicuddy • 15:25

They’re trying to create a proprietary walled garden that you have to plant yourself in to really leverage the tools. He was complaining about this one particular vendor, and he’s like, well, I’m just not going to renew my license on that. I just don’t like the query language and also a little expensive. And so I’m just going to continue on my homegrown path as a result. So these people, like, it’s a de facto standard, but also a career builder. You know, like, I can build stuff with no money up front, just pay my salary, and I can use all these open source and standard software components to put it together. And there’s a whole community behind it.

Shamus McGiIlicuddy • 16:04

It’s a good resume thing as well. So homegrown tools aren’t without their challenges. The first one is human capital gaps. I’ve alluded to this already, but it’s really hard to find people that have both network skills and coding capabilities. A lot of network engineers are teaching themselves how to use Python and write code in Python, and that’s great. And it’s a great career builder for them. But it’s still really hard to find those people as a hiring manager.

Shamus McGiIlicuddy • 16:36

Vice versa, it’s really hard to find trained software developers who know anything about networking. As this network automation director at a large university in the eastern United States, you know, think like tens of thousands of students. He said, My most recent hire is an amazing software developer, but it took about a year for him to grasp some of the networking knowledge and understand what the heck he’s doing. Now he’s like, now he knows networking. Like he’s kind of like the point man on all network automation moving forward. And all the network engineers who are writing scripts and sending the scripts to him to sort of plug into the system of APIs and front-end software are kind of following his lead. But it took a year for him to get up to speed.

Shamus McGiIlicuddy • 17:25

Project complexity can be inevitable. Is this network automation engineer in a mid-sized energy company, renewable energy company? He said, He’s a sooner or later, these tools turn into this Frankenstein’s monster. Before you know it, if you got 15 Frankensteins running around with a lot of overlap and a lot of distinctness, it’s kind of a hassle to build functions and make sure you can recreate them in different environments. His was like kind of specific. He’s like plugging automation into like industrial control systems so that like the people that are like spinning up new sites for like electric vehicle charging stations or like solar arrays and stuff can like provision and manage those sites with network automation plugged into it for this connectivity. So he was having a lot of problems sort of like recreating automation for different sites.

Shamus McGiIlicuddy • 18:12

And then security risk is a big issue. Mistakes happen and governance is not foolproof. This network automation engineer at that same renewable energy company kind of nailed it. He says, You have to be mindful of not exposing secrets in the code or in logging, especially in logging. Oftentimes, we have pretty verbose logging to improve processes or eliminate bugs, and you have to be careful not to expose things in logging, like secrets, like, oh, this login failed. Here’s the password for it. Try it again.

Shamus McGiIlicuddy • 18:42

You know, things like that. But yeah, like everyone I talk to, they’re like, Yeah, we try to be very careful about never putting secrets into code, you know, but it happens because some people just haven’t established best practices for it and they mess up and then like something gets exposed. It’s also important to make sure that the automation you build isn’t exposed to external malicious actors as well. Sometimes people will put their code on a server and they accidentally leave it open to anyone, you know, as opposed to making sure there are role-based access controls in place to ensure that like insider threats don’t emerge or just like people who don’t have any business driving automation through your network don’t accidentally expose something to the outside world. It’s always a risk when you’re using DIY. So, I asked every single person in these 90-minute interviews, like, what could vendors offer you that would help you improve DIY, platformatize it, operationalize it, in some cases, replace it. Some of them are open to replacing it.

Shamus McGiIlicuddy • 19:51

Others are like, no, I want to hold on to it, but I need a vendor to sort of bring me into the future. In my sense, in my experience, like most network automation vendors these days aren’t really asking you to throw out your homegrown stuff. They are looking to sort of help you bring it into the future and just build capability around it and sort of integrate you into their platform the way you are, which I think is great. So, the things that appealed to them were like, build automation your way from no code to high code. So, they’re like, I’m not opposed to no and low code automation. It definitely will empower certain people in my organization, but I always want the option to go into high code when I need to. Meaning, like,

Shamus McGiIlicuddy • 20:37

My philosophy is 80% of use cases can be delivered by a vendor, but the other 20% I don’t think can be because I have very specific needs and a very unique network. And so I want the ability to go into code whenever I want to, but have that code live in the same platform as the low-code environment. Number two, logging, reporting, dashboards, like just having visibility into what’s happening, being able to understand if things went wrong. And governance and security. As I mentioned, security risk around it, just like having controls around who can access your automation, who can create automation, what they can put in that automation, that you know, ensuring that secrets aren’t exposed. And then you have some color here from a senior network engineer at a mid-sized financial technology company who says, I would like a platform to onboard my scripts, stitch them together, and wrap them in a nice package. I don’t want to have to tell people to log into a Linux server and run an Ansible playbook.

Shamus McGiIlicuddy • 21:33

Instead, they get this nicely named workflow with a nice GUI, and you see little boxes turn green as it progresses through the steps. That sort of speaks to multiple pieces of what you see on the left: the no-code to high code, the logging, reporting, dashboards. And then this other network automation engineer and a large collaboration solution provider saying, you know, putting my code together and making it into something that like workflows would be very valuable, especially if I could say, run this if this happens, and run that if that happens, like if then that, do that. So, those are some of the things that resonated with these DIY experts in network automation.

William Collins • 22:14

So, Seamus, that was fascinating, by the way. There’s a lot of great insights there. And I think later on, we’ll probably do some back and forth and dig down between the research and kind of what’s coming next here. But again, thank you for laying that out. And it does hit different when you just kind of zoom out a little bit and you really take a look at the sum of like all the parts at this more macro level. You know, this research really tells a story about what’s happening across the industry. Because a lot of those, you know, some of those things you laid out, I’ve definitely heard from many others.

William Collins • 22:48

You know, so I think it’s an industry-wide thing. But In my mind, what I was thinking about when you’re going through all that, what does it actually feel like when you’re the engineer in the trenches? And this is exactly why we have Eric with us. So, Eric, do you want to just kind of take us back to the beginning with your journey and talk us through your experiences? Yeah, sure can. So I guess I’ll just start out level set with Armstrong.

Eric Anderson • 23:22

So as the slide shows here, we have roughly 3,500 employees, about 20 plus manufacturing sites. And then by the numbers, you know, 1,000 plus network devices, close to 1,000 servers, data centers to manage, cloud footprints to manage and connect as well. So I think our automation journey started in the DIY world. We had our focus at the beginning was we have service now requests for things like DS names or to take a VMware snapshot, right? Those were kind of the OGs in our DIY space that we went after first. But how do we use code to be able to fulfill those service now requests in a way that an engineer doesn’t have to touch them, right? We don’t have to get the ticket assigned to us and then run a script and then it’s closed out.

Eric Anderson • 24:23

All of it’s handled seamlessly. So we started out with a Python solution that we called our Maestro Orchestrator and really was a library of Python modules and REST API calls and things that work with ServiceNow and check ServiceNow every X amount of minutes to see if there were any tasks that were flagged for automation that we can go automate. And it worked well. It gave us a good base of knowledge. And it allowed us to really get our feet wet with how do we interface with REST APIs? How do we use SDKs from different vendors to automate certain tasks? And so it worked well.

Eric Anderson • 25:06

And we were able to get a good amount of value and show some value and be able to say, hey, look, here’s the service now request. I’m going to hit request. And if you wait a couple of minutes here or 30 seconds, you’ll see the task is closed with an update and a work note. And it’s good. It’s fulfilled. And I think that really spoke volumes to folks that were watching and actually saw the potential of what we were able to deliver. Yeah, I think so.

Eric Anderson • 25:37

Piggybacking on what Seamus had mentioned about the limitations with DIY, these are ones we really hit. The scalability challenges. So we had built a good foundation for being able to scale out the homegrown orchestrator, adding different additional modules, things like that. But when you talk about scalability, you also got to scale out to role-based access control. Who has access to be able to do things in this system? Managing a database behind it. Yeah.

Eric Anderson • 26:11

Yeah. Security, governance, those sorts of things. And also for Armstrong, there was like two of us that were actually able to bridge the gap between knowledge of infrastructure, knowledge of networking, and the coding skills. And we went down the path of, okay, if we want to scale this out, there’s a couple of different options. Do we take specific time and train up our network engineers, our infrastructure engineers to learn Python and learn how to code to get up to speed in the infrastructure environment? Do we talk to our software folks in the application team and see if they can throw us a bone and help us out with their knowledge of coding and then get some network skills, infrastructure skills on top of that? Neither one of those really panned out too well.

Eric Anderson • 27:00

I think the third option we looked at was: okay, do we hire a software developer, as Seamus had mentioned with a different customer, do we hire a software developer and train them up in networking to be able to accelerate what we were doing with that homegrown orchestration module? None of those really seemed like a great idea and just didn’t really scale well. And on top of that, like I said, there were two of us in the platform. So there was really a high dependence on me and one other person to deliver, right? And we only have so much time. And not only that, we each had our own day jobs, right? Network engineer, network architect, infrastructure engineer.

Eric Anderson • 27:45

So we were doing that plus, you know, the automation as like a hobby, right? Just to say, hey, we can do this well. And I think we should put more money, time, and resources in this. But those were definitely challenges that we ran into as well. So how did we get to Itential? So I think. The path was a curved road.

Eric Anderson • 28:10

It wasn’t a straightforward approach. In similar conversations in other areas of IT, we had already been talking about RPA, like robotic process automation, platforms like UiPath, Automation Anywhere. We gave those a good look to see if they could help us with what we were doing. And they were a bit too generalized of platforms for what we were looking to do, specifically in infrastructure, networking, things like that. We also looked at, like we said, open source tools. We looked at the Nautobot partnering with Network Decode. And really, good options, it really just perpetuated the need for Python skills, right?

Eric Anderson • 28:55

We still needed that Python expertise to be able to build and manage those platforms successfully. After a while, we started talking with some other industry analysts, and they told us about different infrastructure-focused orchestration tools. And this is where we learned about automation, low-code, no-code platforms that are specific to infrastructure. And really, really what we came out with was Itential for several different reasons. One of the main ones was just the ease of use and being able to leverage our existing Python that we had already built as part of orchestrators within a workflow in the Itential platform. It really opened the door for us to be able to springboard the existing automations that we had already built and be able to really level up using Itential as a platform to be able to move on to other more complex workflows and build reusable workflows that can be used for not just one use case, but many use cases depending on what we’re trying to do. Yeah, so we’ve in the three years since we’ve gone with itential, we’ve automated a lot of different things.

Eric Anderson • 30:19

What I really wanted to highlight here was really just the ability to go from low code to high code as you want, right? So there’s a bunch of different ways to do a bunch of different things within the itential platform. Whether you want to go full low code or have some low code as part of a workflow, kick it down to a Python script to do some sort of data analysis or interface with NetMiko or something like that. Or if you want to use REST APIs to connect to a different system, Jinja templates, JSON schema transformations is transforming JSON and the different schema that goes with that. It can all be done within the same workflow. So depending on who’s in the platform, how they like to code, how they like to stitch together an automation, the sky’s the limit for how you want to put that together, right? And we’ve seen that.

Eric Anderson • 31:13

And we’ve gotten good use out of not only infrastructure and network automation focused tools, but interfacing with platforms like SAP Success Factors or other ones that you wouldn’t think of. But as long as they have a REST API, you can hook an adapter into it through Itential and be able to hit that REST API and grab data and use it as part of a workflow, just as you would any other tool that exposes a REST API. Yeah, and to Seamus’ point about the money aspect of this and network automation not being in the budget, what we found at Armstrong was from the beginning, we wanted to be able to quantify the success that we were having with automation in our environment. So we built out a Splunk, a dashboard in Splunk, where every time the automation ran, this started out in our homegrown Python orchestration. Every time an automation would run, it would kick a little webhook over to Splunk and say, hey, this ran, this used to take us this long to do. Now it’s this long because it’s automated. So we were capturing those metrics from early on.

Eric Anderson • 32:25

And that allowed us to really quantify the success we were having. I think the top number here on this slide shows the amount of time that we’ve saved Armstrong engineers, architects, analysts from having to do the manual work that we have now automated in Itential. Which is a pretty big number. A number that really gets shared a lot within Armstrong is that second one where we have a time to delivery improvement. This is specific to service now requests. So, say somebody requested software and prior to it being automated, it took maybe three days for the request to be fulfilled. Maybe it only takes a help desk technician 15 minutes to fulfill that request once they pick it up.

Eric Anderson • 33:15

But because of queues and everything we have built up, maybe it takes three days to actually get assigned or completed itself. So, that 10,614 days is the amount of time we’ve saved customers by allowing them to receive those services in an automated fashion. So, if something used to take three days from start to finish and now it takes five minutes, well, that delta is what gets mapped to the Splunk dashboard and calculate for that time to delivery improvement. So, that’s been a fantastic improvement. Yeah, and I would be marissed if I didn’t have a couple of lessons learned on here. Not everything should be automated, first and foremost, right? It’s easy to get down a rabbit hole or have a squirrel moment, right?

Eric Anderson • 34:02

And just kind of go at things just as they come and try to do everything. It’s definitely best to think methodically about automation and have some sort of intake process that outlines: hey, here’s all the things we could go automate. What are we spending the most time on? What takes the longest to do when we do this manually? And be able to quantify that and rank them and use that to be able to prioritize the work. Next would be building reusable code, templates, and functions. In Itentual, you could build out a workflow from soup to nuts and then rebuild that same workflow and tweak it one way and have it do something completely different.

Eric Anderson • 34:48

But we’ve learned it just like writing functions and classes within Python. There’s a good way to build reusable code and templates and child jobs within the Itentril platform as well. And once you do that, it really accelerates your automation to be able to reuse those things over and over. Third, automation is only good as the data relies on. We found this out from using ServiceNow as a CMDB, right? And the data in ServiceNow that we use to fulfill requests, that we use to generate reports, that we use for X, Y, and Z, if it’s not good, the automation is not going to be good either. So putting guardrails on formatting for different fields, validating an email is an actual email, a telephone number is a telephone number, things like that.

Eric Anderson • 35:42

Like I touched on with the homegrown automation and capturing metrics, start small, start with something that you feel is something that could be automated easily. Prove that value, show off that value, and scale gradually from there. The way we actually were able to get funding for the Itential platform and for automation in general was because we were able to show through lunch and learns of what we had automated with Python and with that Splunk dashboard that kind of showed, hey, here’s how much we’re able to automate with just some homegrown things on the side. Imagine what we could do with a platform. So start small, prove value, scale gradually. I would also say when you’re probably year one, year two, maybe year one and a half, you’re really just automating everything you can get your hands on, right? Working through that priority list, banging out new automations, and you get to the point where you realize: okay, the things that I built require care and feeding, right?

Eric Anderson • 36:46

Feature requests. Hey, what if this could do this? Why did this automation stop running? What is going on? It started airing out for some reason. API tokens expired, right? You name it.

Eric Anderson • 36:58

But you need to have some flex in your time to be able to maintain the automations you have currently and not just budget for new automations all the time. It definitely requires some care and feeding to stay alive. Same with the documenting, the logic, and the decisions. I think Naming standards, whether it’s how do we, if you run a child job, what data should this expect, right? And have some sort of agreed-upon schema so that everybody’s working off the same sheet of music. Because it is easy to grow your own way.

Eric Anderson • 37:34

And then at some point, you’re like, man, we need to come together on this and kind of reevaluate what we’re doing and agree upon some standards. And the last one there, plan for security and access controls. That’s one of the things that really Itentual brought as part of the platform is the ability to do RBAC out of the gate. Right. And we’re able to tie in with Azure single sign-on. There’s a lot of things that are on top of the automation capabilities of Itentril that make it a holistic system that we would have had to build out on our own, separate to actually automating things, but building that architecture around it to make it a secure and governed system. So I wanted to just, you just painted a great picture, by the way, that I think is going to resonate with a ton of folks out there.

Eric Anderson • 38:29

Kind of starting off, you start with a few scripts. Hey, they work great. Everyone loves you. You automated some things. And then suddenly you find that you have this whole ecosystem of automation that’s gotten like way bigger than maybe you ever imagined. And you. You said quite a few things about one of the hardest parts of making it like an operational enterprise level change, you know, taking that value beyond just you and your team and, you know, bringing it to the whole organization and selling it to the business, getting the business to understand why that, you know, hey, this is such an important thing that, hey, we need real funding behind it.

Eric Anderson • 39:13

You spelled that out great. And it actually kind of mirrors an approach that I took several years back. I actually presented about it at AutoCOM. It was really oddly similar to what you just went through. But there’s something interesting, I thought, from Seamus’s research that, like, even when you’re that engineer and you’re in the trenches and you hit these scaling problems, there’s this. There’s this real resistance to break out of that DIY, my tools, own it within my team, like not take that platform approach. You know, I guess a resistance to platforms.

William Collins • 39:50

And, you know, Eric, as someone who just lived through this, we, you know, again, we talked about the business side, but is there any light you could shed on like why do you think engineering teams are like very skeptical sometimes when you know someone mentions automation platforms and kind of like what what ended up uh I mean I guess you kind of answered this to a degree but was there something singular in your mind that um where you made up that decision of hey it’s time to jump to adopt this platform centric approach Yeah, so to address the first one about the teams, I think, you know, it’s hard to get everybody on board with automation, just let alone a platform, but just using Python or any automation tools out there to do certain things, right? You know, you definitely have the, you definitely have the folks who like their CLI, right? They just, that’s where they live, right? And there’s people that really just, at the end of it, they just aren’t interested in automation. They’re comfortable where they’re at. They love doing their job the way they’ve done it for the past X amount of years.

Eric Anderson • 41:03

And that’s the way it is. So I think to. There’s that. And then there’s, okay, we have this base level of automation platform that we’ve built ourselves, homegrown, taking that to an enterprise platform. I would say for our team, it wasn’t too bad because, like I said, by that time, it was probably three of us that were working in there. And we all saw the challenges, right, of being able to scale and all those things that we talked about, the peripherals that we would have need to build around this platform to make it a production system. And so that itself was not hard.

Eric Anderson • 41:43

I think by the time we were able to lay out the business case to leadership and say, hey, we’re kind of at the point where we need to hire somebody. We need to partner with a company to keep helping us develop this, like on a time and materials basis or project-based or however we do that. Or, hey, there’s these platforms over here that we could really bring in and accelerate our journey and hit all the security controls, access roles, et cetera, all the wickets we need to make this a production system. And I think once we were able to lay that out, the platform approach really sold itself to leadership once we were able to show the different pieces. So I wanted to ask, I didn’t ask it at the beginning, but I was actually really curious about just so Seamus presented and then you, Eric, presented, but like, did you all, were there any surprises, Eric? And, you know, as Seamus laid out his research, did anything he said or laid out, was it a surprise at all? Or did it just kind of make sense with all of your experiences?

Eric Anderson • 42:51

I think it it definitely made sense. I definitely had to sit there and smile on a couple, you know, that just like, yep, been there, right? And I and I think, you know, one of the pushbacks to the vendor piece was the flexibility and vendor lock-in. And that’s. One of the things we’ve seen, you know, with itential, and like I mentioned, you can really just do it however you want, right? Itential is just really the glue that’s putting everything together. You’re using standards-based APIs.

Eric Anderson • 43:21

You’re calling Python PowerShell scripts, and you’re using Jinja templates, right? So, really, itential is the glue that brings this stuff together. Yes, there is some low code that you build in there. But in terms of vendor lock-in, it’s really accelerating the use of standards-based tooling, right? And that’s what we’ve sewn. And how do we expose a workflow as an API, right? It’s really easy within the Itentril platform.

Eric Anderson • 43:50

That can be easy to homegrow yourself, but it can also be very difficult to build an API that’s secure and scalable yourself as well. So I think Itential has really done a good job of making it simple and meeting the engineers where they’re at in order to automate the way they want. Gotcha. Thank you for that. And what about you, Seamus? So, as Eric was kind of laying out his journey and talking through everything just from the beginning to getting to where Armstrong is today, did that kind of mirror the discussions that you had in your research? Was there anything different that stood out?

Shamus McGiIlicuddy • 44:27

No, I mean, Eric’s journey was pretty much could have been plugged into the report as one of the conversations I had with his peers. I guess one thing that kind of resonated with me, which I didn’t necessarily talk about a lot in this research or explore a lot in this research, was automation is only good as the data that you have. I continue to have conversations with people who are focused on network automation. And the first thing they do is, well, they basically say, I can’t automate something if I don’t have a standard. And I can’t have a standard if I haven’t documented what’s on my network and decided what the standard is. And so people don’t have like a lot of automation projects that go beyond like just scripting individual tasks is like having good data that powers the automation. And that’s something that Eric mentioned in the lessons learned that resonated really.

William Collins • 45:37

Yeah, that’s super big. I mean, even in my experience years back working in enterprise, I feel like sometimes in our industry, we tend to take extremes. Like we’re either on one side of the extreme or the other. And this actually happened to me where in a project I had a very long time ago, I said, Hey, we’re going to get all of our data in order, and we’re not going to automate anything. We’re not going to touch the network until we get all of the data, the processes, and all this stuff figured out. And guess what? A year later, we hadn’t automated much of anything.

William Collins • 46:12

So. Going from that extreme to being able to show like small wins. And hey, I have a lot of brown fields out there that were deployed at different periods of time. I have two new green fields coming in. Maybe we’re migrating our data center to a new SDN fabric or we’re doing different things. And, you know, that presents challenges. So, like, being flexible and being able to understand the risk tolerance of your business, I would say, and keeping in mind that you don’t have to have all the data in order before you touch anything.

William Collins • 46:43

But at the same time, you don’t just want to go, you know, you’re clicking your spurs together. You throw on that cowboy hat and you’re like, hey, I’m going to go and just start doing things without having any plan, without looking at data, without naming standards, processes, and all this stuff. You know, those are like two very different extremes. And, you know, a lot of times, like most things in our lives, it’s somewhere of a balance in the middle. I just want to thank both of you. Like, this has been fantastic. I learned a lot from this conversation.

William Collins • 47:13

And for, you know, everyone who joined in today, you can download Seamus’s research at itential.com/slash EMA report from scripts to platforms with hyphens in between everything after the slash. There is a ton of valuable intel that you can find in that research that we obviously didn’t wouldn’t have enough time to cover. And if you want to connect with any of us, we’re all, all three of us are on LinkedIn and we love continuing these types of conversations because I think that’s what. Brings value to the community, to the industry, to networking, and ultimately to businesses is actually having the conversation. If vendors aren’t doing the right things, what can they be doing? What do they need to focus on? And part of that is just having the conversation in the first place and not living in our own little vacuums.

William Collins • 48:04

So thanks again to Seamus, Eric, for sharing your valuable insights. And thank you to everybody that joined in to listen. Until next time.