Network Automation Maturity: Evolving from Limited to Task Automation

Rich Martin • 00:00

Hello, everyone. Welcome to another Itential webinar. Today, we will continue our series on the network automation maturity model. For our session today, we will discuss evolving from limited to task automation. My name is Rich Martin, Director of Technical Marketing at Itential. For today’s conversation, I am definitely going to draw upon my previous experience as both a practitioner and a little bit of a programming experience as well, to help communicate some of the thoughts around what a practitioner going through this evolution from the limited to task automation stage would look like. And of course, as always, I am joined by my esteemed colleague, Mr. Morgan Stern. Morgan, why don’t you introduce yourself and start us off?

Morgan Stern • 00:45

Thanks, Rich.

Morgan Stern • 00:46

So my name’s Morgan Stern. I’m the VP of Automation Strategy at Itential. And the perspective I will be bringing to this session is really more around strategy, leadership, more about the manager’s perspective than Rich presenting the practitioner perspective. So just to ground everybody in the conversation, and this builds on the intro webinar that we did previously, and there will be subsequent webinars that are built on this, but during the first webinar, we introduced the network automation maturity model. And there are four stages here. Today, we’ll be talking about the transition from the first stage, which is limited or no automation, to the second stage, which is task automation. So, really, the things that we’re going to be thinking about are what are the considerations, what are the constraints, what are the opportunities that folks have in front of them as they think about getting started on this very first step of their automation journey.

Morgan Stern • 01:49

In later sessions, we’ll talk about the other transitions around moving from test to process automation, and then ultimately moving from process orchestration to self-service networking. So, Rich, can you tell the audience a little bit about some of the limited automation characteristics?

Rich Martin • 02:07

Absolutely. So, as part of this, we’re trying to help everyone assess where they’re at. And this might be the easiest one to assess where you’re at. Some of the common characteristics that you’re going to run into is, really, you’re just getting started. So, what is automation? I’m kind of unfamiliar, or maybe I’ve heard from some colleagues, either at where I work or other colleagues at other places that are part of the network engineering team about how some of the things they’re doing with automation, some of the things they’re tinkering with. But really, at the end of the day, you’re kind of unsure of where to get started.

Rich Martin • 02:42

Unfortunately, it becomes more of what we call an aspirational goal versus something that’s a necessity like we have to do this. This is something that’s like, we are really nice to automate certain tasks because they’re tedious, they’re things that we have to do all the time and ultimately, they end up being a backlog and maybe some of the stuff that’s not so fun. But it really just starts as an aspirational goal. It’s so funny too because I’ve run into a lot of folks, and maybe they’re part of a smaller network organization. Where doing things manually is still acceptable in the sense that, hey, we can get our workload done on a day-to-day basis. I still have time to do some of the other things around engineering the network and optimizing it. things like that, fixing things.

Rich Martin • 03:27

But they still are looking more towards, but I know I need to grab these tools. I know there are a bunch of tools out there that can help me do this better. So that’s really good. And it’s an aspirational goal. Eventually it turns into something that’s like, we really, really need to do this. But you’ll see a handful of engineers starting to leverage scripts for themselves. This has definitely increased in the last couple of years with the proliferation of so many tools, so many scripts, so many success stories of folks that have started down this road and are sharing some of the work to make it easier for the next generation to get started.

Rich Martin • 04:04

But you also see it’s very much a single user environment where you might have a couple of practitioners on the team, network engineers that are picking up some scripts and those assets are their own. They run them and they execute them in their own environment maybe on their desktop or their laptop. And they’re kind of still siloed out. And unfortunately, a lot of this is not part of an overall strategic plan that’s been led by the leadership. And that could be that there is an overall strategic plan for automation that’s just not been communicated because some misconceptions around how hard it is to automate or maybe they don’t think it’s possible to automate. or maybe it’s just not on the radar at that moment. But those are some of the common characteristics you’ll find there.

Rich Martin • 04:47

Along that, you also see tools that coincide with that. Some of your tools are probably more on the basic side, like SolarWinds for some network monitoring, some basic telemetry information. A lot of your process is maybe around spreadsheets, which is definitely more of a manual tool versus something that can be automated through APIs and things like that. And maybe a lot of your process change is still driven through email. I mean, I don’t think it’s going away, but there are a lot more mature ways to go through doing change and incident requests and response. But a lot of times you’ll still see some of these older tools that you’ll need to mature into some new tools as you move from limited automation into more task-based automation. So let’s talk a little bit about what might keep you in this stage one limited automation.

Rich Martin • 05:42

The common belief perhaps that automation is too difficult to adopt. Any thoughts on that Morgan around that particular point?

Morgan Stern • 05:51

Sure, sure. I think the landscape certainly has changed in the past eight years or so where we saw folks in the very early days I think, struggling with the complexity of some of the automation pieces. That has, I think, gotten a little bit more complicated in that there are more tools, there are more things to learn, and for teams that have been operating in sort of business as usual mode for a long time, they don’t necessarily understand how to get to there from where they are at the moment, right? The teams have a specialized skill set that isn’t optimized around software development or things like that, and subsequently, they look at it as, this may be just something that’s going to be a little bit too complicated. I think that ties into the second point, right, of there are many situations that we encounter where we’re talking to teams that are saying, hey, this would be great, but I have my hands full. I’m just too busy.

Morgan Stern • 06:51

We have too many things to get done. I don’t have enough time. For me to think about automation means I need to take a step back from the work that I have to get done today and that my team has to get done today, which means that work isn’t going to get done, which is an interesting position to find yourself in, that recognizing that there’s some real potential benefits, but I can’t really realize those benefits because I just have too much stuff on my plate, so it’s a bit of a catch-22 there.

Rich Martin • 07:18

It is, there’s a bit of an irony there. And I’ll just be honest, I think a lot of the belief around automation is too difficult to adopt, really comes from historic problems with trying to automate with really, really crude tools way, way back in the day, causing network practitioners, network engineers who may have tried those things to really get some heartburn from them and then hold on to those negative experiences for far too long, not really paying attention to the advancement of all the tools and the better ways to do things. I mean, I can tell you, I’ve run a couple of expect scripts a long time ago that blew things up, which made me feel, ooh, maybe network automation isn’t here, isn’t the thing I should be doing right now. But how much further have we progressed from expect scripts, right? So it’s a way now to take a look at what that ecosystem looks like out there and just how many success stories are out there as well. And there is a bitter irony to the fact that you can still hear network engineers talk about, look, I’d love to automate, again, aspirational goal, but I don’t have time to. Why?

Rich Martin • 08:24

Because I have too many things in backlog. I have too many things that I have to do to fix the network. I’ve got to bring this up. I’ve got to bring that side up. And it’s like, well, that is the key. That’s the red flag that says, hey, automation really should be more than just aspirational. Now you’re starting to think, no, actually we really need this.

Rich Martin • 08:42

That’s the solution that gets us out of this. And there’s an entire ecosystem of stuff out there that can get us quickly started down that road.

Morgan Stern • 08:51

For sure, for sure. I agree. And I think it’s, you know, some of these points kind of tie into this next thing around cultural resistance, where, where we will see, in a lot of situations, we’ll see groups and teams where the leadership is very excited about maturing in their automation capabilities, but for whatever reason, the team isn’t able to get there. And we look at that and we say, okay, there’s clearly something more than a technology challenge here, that there’s something about the ways of working for those teams and the way the cultures are that make it a challenge for them to evolve. So in some cases, it’s reluctance to walk away from or to think about the work differently than the way you’re doing it today. And in a lot of cases, the best opportunities for automation are being able to look at your work and think about how could we do things differently, not just I’m gonna run a script to replace this task, but how could we orient around some of the things that we’re doing so that those things that make the most sense can be automated quickly. So this is, we will find folks who pick a tool and still aren’t able to really evolve. In a lot of cases, it’s just because culturally, they’re trying to figure out how do I fit this new way of working in with the things that we do today?

Rich Martin • 10:13

Yeah, yeah. And as a network practitioner too, we see a lot of, on the next point, a lot of solutions that are provided by our network vendor of choice that allows us to do, I mean, it is a form of automation, right? If I’ve got a GUI interface and I can click around and, you know. overcome some CLI changes that I would normally have to do with an older solution or with a solution that doesn’t have some sort of front end. That is a form of automation, but at the end of the day, it’s probably what we found as practitioners, it doesn’t do all the things we need it to do. In fact, it really does a very small subset. And so you don’t get the kind of flexibility that you would get when you start going down the road of really investigating the tools that lets you express through those tools or those programming languages, the use cases, the technology you’re using, and eventually the processes that you can automate and build through those tools.

Rich Martin • 11:12

So QlikOps ironically can keep you in a situation where you’re still in that limited bucket and you don’t really progress further, even though in your mind, it’s like, no, this is automation, right? And that’s what we hope to kind of dispel that is like QlikOps, great, your GUI dashboard’s great. Maybe they’re even intrinsically tied to the solution like with SD-WAN and a controller to manage that. But then you need to really say, okay, what part of this application am I still manually involved with? And is there a way to automate these processes within that and the processes outside of the application itself? And of course we’re moving forward, but these are the things we wanna unlock in people’s minds. And then finally, misconceptions on how costly it is to invest in these skills.

Rich Martin • 11:56

Any thoughts on that, Morgan?

Morgan Stern • 11:59

Yes, this is a space that we’ve done a lot of work with teams around understanding how best to optimize around investment in that. Once you start to think about how to scale a team for automation, you pretty quickly realize not everybody is going to be doing the same thing. Ultimately, not everybody is going to need the same training path. What you can start to do is think about what are the skills, how do the skills best align to the team that you have? Start to identify, pencil in certain individuals for certain tracks, and then build that around that. What we end up finding is that you’ll have a small team that’s typically going to have the most advanced skills in automation tooling and everything else. You will have then a larger audience that is more a consumer of those pieces, which means they still need to get some training to learn how to do the things, but not to that degree.

Morgan Stern • 13:00

I think that we’ve seen a pretty healthy evolution in the way people thinking, that it isn’t like I have to re-skill my whole team in order to get the benefit from automation, that I can think about this strategically, and think about this in a way that makes sense, make targeted investments, and reduce the total overall cost around skill development.

Rich Martin • 13:26

Yeah, no, those are great points. And I, and from a practitioner’s perspective, I know there’s, you know, I’ve heard this and you’ve probably heard this too from folks in networking practitioners in the industry. I got into networking so I wouldn’t have to write code. You know, you’ve heard that. And, you know, that’s, you know, that may be true for some but here’s the thing, you don’t have to write code to automate, right? There’s a lot of solutions out there or how much code do you want to write necessarily? I think the misconception that a lot of network teams make is that they’re incapable of, and they don’t want, therefore they don’t want to, and that’s not true at all.

Rich Martin • 14:02

There are a lot of different tools at different layers and different levels of not only where you want to go, but, you know, what you may already be used to doing. And one of the things that really annoys me, and I’m just going to kick the door down on this misconception, is that networking teams that think they can’t pick these things up. And I’m just going to tell you, as a network practitioner for many years, I have seen over and over where history has shown me that to be completely and utterly false. How many technologies do network teams have to pick up on a year by year, month by month basis in regards to new protocols, new features in routers and switches, new interface technologies, new ways of thinking about routing and, you know, going from physical routers to virtual routers to, you know, there’s all kinds of things. And then on the layer on top of that, other adjacent technologies that now have become part of the network engineer’s responsibility. Here’s a great one. Remember the days where you used to have phone systems run by PBXs and entire staffs around those PBXs to keep that network and that system running?

Rich Martin • 15:06

Those things don’t even exist anymore, right? Because they were kind of voiceover IP became the thing. And now, you know, but did network engineers initially resist and say, we can’t, we don’t know how to do that stuff. Yes, they did. But what happened? The tools evolved to make it easier for them. And then, you know, you had people going, hey, this is actually.

Rich Martin • 15:25

this is actually something we can do. And not only that, this is actually something that we have fun with because there’s a sense of accomplishment, being able to understand these things, build them into the network and make them successful, which is exactly what happened. And I could name a number of these things throughout the years that network teams have been able to do. So getting automation tooling as part of your knowledge set and something you can invest in and actually find fun in is something that we ought to be thinking and get kind of busting down those misconceptions on how costly or how hard it is to do these things.

Morgan Stern • 16:00

Yeah, my general rule of thumb is if you can decode a CLI, output of a CLI, you can learn to do automation.

Rich Martin • 16:07

Absolutely right, absolutely right. In many cases, multiple CLIs, right? That’s right. Different types of CLIs. Great. Well, that takes us now to that next stage, stage 2, task automation. Let’s talk about those common characteristics so that you can identify where you’re going. If you’re in limited to none and you’re going now to task automation, what are the things that you’re going to see around you?

Rich Martin • 16:31

What are the characteristics? One of those things is you’re actively looking for these routine tasks, these repetitive things that go on. Again, the backlog of things that happen, the pattern recognition that we’re doing a lot of these things all the time, this would be a great way to automate this task. We need to take this tooling now, and that’s the next thing. You’ve got this set of tooling that is available to you that you’ve invested in, you’ve picked up maybe some scripts and you’ve learned it by backward engineering it. You’re saying, here’s a script that’s been posted on DevNet or some other forum or site. You’re looking at it going, hey, this is not too hard to understand.

Rich Martin • 17:13

In fact, I get the structure of it, whether that’s Ansible or whether it’s an Ansible playbook or a Python script, and you’re starting to decode this, you’re actually learning this, and now you’re seeing how this is relevant and applicable to these use cases. Now you’ve got this set of tooling you’ve invested in, and now you’re saying, this is where we ought to capitalize, at least initially, by automating these particular tasks. The thing that you should also look at is, how are these automations being run? They’re typically being run by you, so manually triggering these automations. While you are definitely running scripts to help alleviate some of those steps, some of those CLI configurations, maybe a little bit of pre-check and post-check, you’re still doing some manual work in the form of logging into a system or opening up a terminal, running that particular script. Even before you run it, you’re really probably doing some eyeballing on the network to make sure everything’s in place. Probably working through some dashboards as well for monitoring and ITSM systems, tickets, things like that.

Rich Martin • 18:19

But when it comes to running the scripts, you’re the one that’s running them, or somebody on your team is running them, and then overseeing what the output looks like. Then your tooling when it comes to the process is progressing. Now you’re seeing more of this work being initiated or requested from ticketing systems. You’re still going to have e-mail probably as a form of communication, but primarily you’re probably switching over to a ticketing system of some sort to help document this process, to help keep people accountable, keep process accountable, and then knowing the amount of time it takes before something is requested and delivered. And with that, you’re also starting to see an advancement in the tooling. So like we said, you’re probably reaching for something like Ansible or Python. And what’s interesting about that is we’ve seen over the years that Ansible has definitely been one of the tools of choice, but we’re actually seeing now a lot more folks are gravitating towards learning some Python.

Rich Martin • 19:17

And that, I think, is just a natural evolution of some more of the libraries that have come out to support task automation for networks. And so you’re starting to see people gravitate towards also learning Python or moving from Ansible to Python, or actually using both. because you might have people on your team that want to, you know, do things in Ansible, but then you might have other people gravitating towards, hey, I can do a little bit more with Python, you know, so, and so you’re starting to see that. You’re still going to run vendor solutions as well. I mean, that’s just a part of it, especially, like I said, if they’re intrinsically part of the solution itself, SD-WAN and with controllers, that’s going to come from your vendor as well. But then you start to investigate some like execution environments and so maybe some ways to share scripts and things like that with your teammates. Around your use cases, they are still going to be very task-oriented in case of, you know, probably revolving around your most critical backlogs, because these are the repetitive things that quite honestly network engineers would rather automate and get off their plate so that they can focus on other things. So things like port or interface or VLAN changes. And then the one that’s always the, you know, that’s on everybody’s list is software upgrades or firmware upgrades for your network devices. That one also is a big one that always pops up as a use case. All right, Morgan, talk to us about the opportunities for evolving.

Morgan Stern • 20:45

Sure. Sure. One of the things that we do a lot is work with teams to say, hey, we’re here, we want to be here. Right? So we spend a fair amount of time helping folks understand what are the things that you really need to be thinking about in terms of helping your leadership be comfortable with making the investment and supporting the change that you’re going to make around evolving. So for here, for limited to task automation, one of the key things for IT leaders is this will give you a pretty significant improvement in resource allocation, meaning your network engineers who are very task oriented today will see a pretty dramatic improvement in their productivity, meaning they will be able to execute more of those tasks more quickly by leveraging some of the task automation techniques that we’ve talked about and being able to transition more of things you’re doing today that are purely manual into things that can be automated. Great.

Morgan Stern • 21:51

Thank you. We also think that one of the opportunities as you’re making this evolution is starting to prioritize your use cases. Because what we’ll see is when you start to think about what I’m doing today manually versus what I want to do in an automated fashion, people will gravitate in different areas. Sometimes they’ll say, well, I hate doing this the most, so maybe I should automate this first. Or hey, this is taking the most amount of time, but it’s complicated, but I still want to automate it. I always advocate taking a balanced portfolio approach around defining your priorities for automation. Meaning, if you know that there are some very big bets that will have significant benefits, but they’re also going to take a lot of time to develop and refine and work the kinks out, that’s okay to pursue that.

Morgan Stern • 22:41

I wouldn’t necessarily pursue that first as the only thing you’re working on, because that gives you some challenges in being able to show outcomes to your leadership and to your teams pretty quickly. On the same side, sometimes some of the easy use cases don’t have the best impact, right? And so you want to be able to look at things and say, where can I get the best mix of investment in terms of effort of development and learning versus outcomes? And start to either stagger things or try to do a couple of things in parallel so that you’ve got this sort of good cadence of being able to show out good outcomes. Sometimes some will be small, some will be big, but you’re not waiting six months to see any output. At the same time, you’re not underwhelming your leadership by showing things that are interesting but not necessarily useful to the business. Tied in with the productivity increase, we also see pretty significant amounts of improvements in efficiency.

Morgan Stern • 23:42

The way I like to communicate these and think about these, productivity is about how many units of time or how many units of effort an engineer can get done in a certain amount of time. If they could do two upgrades in a maintenance window, now they can do 15 upgrades in a maintenance window. The productivity went up by a factor of seven point something. Efficiency is how much effort does it take to do a task? They are related, but there are times when you’re looking at an efficiency play of being able to say, we really need to reduce the cost per task of this. That’s typically an efficiency metric that you’re looking at to say, if because of the amount of time it takes to execute a thing and the average cost of my resources, maybe it costs me $150 to do a task. If I can become more efficient, meaning if I can do this in the equivalent of $25 worth of time, well, like that’s a 6X increase in efficiency.

Morgan Stern • 24:40

So depending on the business and depending on the way leadership thinks about business value, you’ll always want to be thinking in those two terms of saying, Do I need to be able to show outputs and results that will show better productivity for my engineers or do I need to be thinking about better efficiency? Rich, do you want to talk about some of the practitioner opportunities?

Rich Martin • 25:08

Absolutely. That’s great feedback too. For the practitioner, look, there is a huge morale improvement. We can get through these we call it toil, but a lot of the work that’s just consistent and constant, and it doesn’t require a lot of brain work, but it requires a lot of manual effort, it can be toil regardless of what industry you’re in. If you can get through all of this quickly, and you can help your colleagues do so through automation, morale improves because this frees up a lot of time for engineers to now focus on some of the other things that we’ll talk about in a minute. But there’s also an increase in accuracy and quality. Automation helps, you know, we make human errors. That’s it.

Rich Martin • 25:55

Even the best copy and paster or the fastest CLI keyboard jockey is going to make issues. Errors occasionally, right? And maybe more than we want to admit. And sometimes we can catch them before we hit enter and apply them, but sometimes we don’t. And sometimes the results are pretty bad and we can quickly correct those things. But wouldn’t it be better if we didn’t, if we just avoid that at all? And I think that’s really what we can start to encapsulate here with our automations is the ability to increase our quality and the accuracy of what we’re doing.

Rich Martin • 26:30

And of course that ultimately means that frees up engineers to do the fun things. So what are the fun things that network engineers like to do? Well, unfortunately in a lot of organizations that aren’t using automation, they don’t get enough time to do those things and they are quite critical. there is, you know, the need to optimize networks, the need to secure networks, the need to make sure they’re performing right. And I’ll, correctly, and I’ll be honest too on this, there’s a lot of band-aids on networks. A lot of times, you know, we’re fixing issues because something is down. We know what, we know we can apply a band-aid to get this thing rolling.

Rich Martin • 27:12

We apply the band-aid, and then we have to go back to, the issue was resolved for the moment. In our minds and in our hearts, we’re gonna go back and fix that the right way. I just need time. And unfortunately, backlog creeps, more things are happening, emergencies pop up, life happens, and despite our best intentions, we don’t get to go do those things. So, wouldn’t it be great, every network engineer would say, wouldn’t it be great if I had the time to go and fix this, do that, make that better, increase this, deploy this new protocol to make this better, give them the time to do that. That’s what automation can help you with, giving them that time. And again, more consistency, reducing network downtime.

Rich Martin • 27:53

Every time the network goes down, network engineers, network teams are involved, it becomes red alert, all hands on deck. If we can remove that, you know, a lot of that through automation by not having to break the network due to mistakes or errors or inconsistency, that’s always a good thing. That helps the practitioner so much. And then avoiding burnout by manual effort. As much as we love to do CLI, as much as we’ve invested in CLI, and CLI quite honestly is not going to go away. We’re still going to have lots of CLI if that’s what we love, but we have to have a better way of managing and automating things and configuring things. Sometimes it’s going to be CLI.

Rich Martin • 28:34

Sometimes it’s going to be through some other management methods. Like I said, I refuse to believe network engineers are incapable of learning all these things. They are more than capable. They just need to be willing, and that helps to avoid burnout as well. Learning new things and seeing a sense of accomplishment as a network engineer, being able to accomplish something, to fix something, to learn something new, that definitely helps us as a team individually and as a team as well.

Morgan Stern • 29:03

Okay. So now that we understand the opportunities, let’s talk about what you need to do to evolve. For the leaders, we’ve already talked about this a couple of times. It’s really about investing in skills development and Providing the right access to resources to your team in some cases You can get you can get access to information resources that are free There is a ton of content out there available on the internet to be able to learn Networking scripting all of those kinds of pieces I think part of it is really making sure that you recognize it’s not just about pointing folks to the To the content. It’s really about giving them Some flexibility in their time to be able to to dedicate some specific Concentrated effort to learn it if it’s purely an off hours or on the side You’re not going to see the necessary like the results that you want to see Because the best people will do what they’re going to do and they probably were probably already learned this stuff and the goal here is To really skill up your whole team. So working around the investment of developing the skill set part of it is Dedicating some time part of it is coming up with a plan part of it is Putting in some mechanisms so that so that you can help folks Measure and monitor their own success and their own development and understand how to set goals. I Think the other part is around support and this ties in with the cultural change thing that this in many cases when we see folks get stuck it isn’t because of technology it’s just because of the way that the culture of the engineering team works the culture of the larger company works and being able to say now for this really to get the right results we need to think about making this a priority we need to change the way we think about things and we need to change the way the ways around kind of how we value contributions to some extent. Obviously you know that you want to value technical expertise but also start to think about how can we build team recognition of the value of getting these these ways of working shifted. We think generally for folks who have great success in getting their evolution from no automation to task-based automation as part of a larger big picture, right? When we talk about the maturity model, we’re showing four phases. Not everybody is going to get to phase four. Not everybody needs to get to phase four. But I do think that when you start to think in terms of phases, it gives you the opportunity then to think in almost like sub-phases.

Morgan Stern • 31:49

So that the jump from nothing to task-based automation isn’t just one project. You can think in terms of pieces. And how you phase that ties in with what I was talking about earlier of saying there are ways to start to characterize the activities that you want to automate. You can use t-shirt sizes, large, medium, small. You can think in terms of effort. You can think in terms of impact. What you can then do is start to organize those to say, some of these are going to have big impact, but they’re not too complicated. These are things that we could probably tackle very early on in our education. Then you can table some of the things that are more complex to say, okay, this will be maybe phase 3, phase 4 of our efforts to get from no automation to test breaks automation. I do think that a lot of what I think about and talk about and help folks to do, is to start to do that workload analysis to say that not every task is equivalent, and that the ability for folks to be successful is in part dependent on their ability to really understand what those different work pieces look like, and to be able to decipher the ones that are more complicated from the ones that are less or the ones that are maybe things that need to be deferred to later so that you can think about how do you want to maximize the impact.

Rich Martin • 33:24

Yeah, that’s excellent points. I can tell you, Morgan, the fact that if as a network practitioner who’s just entering into this world of automation to get air coverage and support in such a way from my leadership goes a long way in helping me down this road where I might be a little bit cautious. I’ve got leadership over this that’s helping me. It’s not just throwing me in, but it’s helping me and allowing me the time to guide myself and to guide me through this new world. That helps tremendously to sit down and work with your leadership to identify those use cases. To a network engineer, obviously, we’re going to be focused on what’s most painful for us. But I think it’s also important for them to understand just like what you said, Morgan, what would be more impactful for the company?

Rich Martin • 34:18

Because here’s the thing, I think if you can tie the network engineers effort into automating these tasks to real value for the company, and you can show them and celebrate this with them and the team, that you were able to automate these tasks which had this profound or this impact on this particular process that now allows us to deliver services faster. To a network practitioner, you can’t imagine how important that is to hear those kind of, you know, those kind of celebrations to the work, because they don’t get a lot of that, honestly. And so that can go a long, long way. So not only working with them on selecting those use cases, but then as they start to accomplish those things, tying it back to the real benefit that it’s had on the company, and allowing them to see, wow, this is really working. So it’s not just about us, it’s about what we can also do for the company. And those things go side by side. And then eventually, maybe you get, you know, maybe you’re focusing on the things that have the biggest business impact. Um, and eventually that gives you more confidence to start tackling the stuff that now might be the, the, that has the most personal impact. I really dislike doing these changes, but I think these things can go along side by side, uh, and, and really, really help inspire that team and give them a lot of confidence. And of course, choosing the right tool, find the right tool for the job. Again, uh, I think now more than ever, there’s not only a lot of tools out there, but a lot of people using those tools for the use cases that you’re already starting to target as you get into task automation.

Rich Martin • 35:58

So you’re going to find a lot of preexisting content that’s going to help you get jump started. And again, this kind of goes back to the myth of how long it’s going to take or what the cost is to learn, because you can accelerate your learning by using a lot of the things that have already been tested and proven, uh, that other people are using and then applying, you know, that, that now that, that, uh, that ability to learn that your leadership’s giving you a little buffer room to say, Hey, take some time. We’re going to cover this much time in your day per week so that you can learn how to use Ansible or use Python or use that tool. And now you can really start working on that with, uh, you know, and figure out those right tools. I always tell network, uh, network engineers as they get started, they, they identify, um, at least in their education period, if they’re trying to learn how these, you know, how these tools work or how to write some code to, to be able to do some network automation, start simple. You can still personally derive a tremendous amount of impact with just a series of show commands because we get it making changes to the network, which, which cause which is really what we need to do in order to enable certain services we need to make network changes, or, you know, or implement certain things. can have an effect, a negative blast radius, if done incorrectly.

Rich Martin • 37:09

So you need to work your confidence up. So start with show commands. You can derive a tremendous amount of value from a script that pulls a bunch of show commands together and organizes it in a way that helps you do a pre-check or a post-check or troubleshooting, things like that. And there’s really the blast radius of that is small because they’re read commands, not write commands in that sense. And now you can start to build your confidence, not only in your tooling, but in yourself and your ability and your skill set as you start going on this road. And now you can script more complex things that require changes. And then, again, tackling that backlog.

Rich Martin • 37:48

That’s always going to be on the minds of the practitioner. So whether that is the first phase of the project or whether that comes down the line, it’s always going to be on the minds of the practitioners and they’re always going to want to do it. And when they do it, it’s going to be a lot of a great day for them because, again, it helps them get kind of that toil part of the work out of the way. It gives them confidence in their tooling. They can now express that tooling across the team to help everybody else remove that. And then that frees up a tremendous amount of time to continue to do the fun things with network engineering. All right, so now let’s talk about a real-life example of where we’ve seen this benefit within our own customers.

Rich Martin • 38:35

You’re going to hear this, this is pretty typical use case, we’ll call it data center port turn up. But really, that’s more of a general statement. If you’re providing some new service in your data center, there’s really a series of changes that are going on, both on a single device or it could be on multiple devices. You’re doing things on your top of rack switch, you’re doing things maybe on your transit router, you’re making changes in ACLs. And so really, when we talk about data center turn up, you’re not just talking about one command on one switch, you’re talking about a series of things that needs to be done. And as networks, well, as companies and enterprise organizations continue to grow, invest more in their technology, invest more in their networks, you’re going to see a rise in the amount of requests for changes in the datacenter.

Rich Martin • 39:25

For perhaps whether it’s a customer turn-up or whether it’s an application turn-up of some sort, that’s going to require some order of events, of changes that need to be made in that infrastructure, and it could be across multiple infrastructures. But in the case of a datacenter turn-up, you typically start to see a backlog of work. If you’re in the limited-to-task automation stage, you’re starting to go, hey, we’re starting to see this backlog as a practitioner. It’s taking us quite a bit of time to do this manually. And while in the past it was manageable, now it’s becoming unmanageable because, well, we’re operating at a faster clip where we need more and more applications on the network or we’re turning up more and more customers. And so, we need to start doing something because what we’re noticing here is because of network complexity and all the changes that need to be made, it’s taking us two hours to get through one of these change request tickets.

Rich Martin • 40:20

And what used to be maybe tolerable through manual process has now become intolerable, and it’s really having a negative effect on not only, like we said, the team, the morale, but even bubbling above that, the company itself, the company’s ability to deliver on services at a rate that’s acceptable, like instead of hours or weeks, we should be able to do this much faster. And so now we’re turning to automation and saying, can automation help us here just by automating some of these repetitive tasks to alleviate this workload and this backlog of work for the team? And that’s exactly what you do. You start to reduce that backlog by investing in Python, in this case, a Python script, again, Ansible or whatever that tooling is. Once you get that investment in and you start learning it, you start leveraging some of the pre-existing work out there, which is what this customer did. They were able to put together a Python script that helped to reduce that two-hour window of getting things done for this particular change request to about 30 minutes. And of course, this is great, right?

Rich Martin • 41:31

And I always say your task automation is a great first step. It’s an excellent first step where you can see meaningful benefits that not only help the networking team, but again, they bubble up to the greater organization and their ability to deliver on services as they are requested. And not only that, I think when you take a look at something like a two-hour window to make some changes, not only, like Morgan said earlier, you’re more efficient and you’re more productive, but As a network engineer in a very chaotic environment, especially as you have a big complex network, a two-hour window of trying to get something done, usually includes a lot of interruptions. Things are broken, your colleague needs help, they need a set of eyeballs on something, customers down, something you were working on that wasn’t a priority is now a priority. A two-hour window in order to make a change, gives you a lot of opportunity to be distracted. I think that this competes with your ability to be able to get things done in an orderly way.

Rich Martin • 42:40

Even reducing that window to 30 minutes, which still may be, it’s definitely a benefit to go from two hours to 30 minutes, but there’s still more work to go. But there’s the additional benefit of, hey, if this only takes 30 minutes, not only can I get things done, I can get things done quickly without the potential for more interruption, which tends to happen, especially if you’re one of the network engineers that’s been there a while, and you know everything on the network. Ultimately, the results are pretty predictable, just like we’ve talked about as you move from one to another, but you’re going to see the efficiency and productivity go up both for the team and for the end-users. Whether those end-users that are requesting this new network service are internal to you or your external customers, they’re going to be able to see that, hey, they’re delivering things much faster than before. This is awesome. Look, we are all preconditioned now to instant gratification and being able to order something and immediately get it. And so that’s not going away, so we need to be able to deliver things as quickly as possible.

Rich Martin • 43:45

And by doing that with automation, we’re also getting the benefit of less human error, and automating these repetitive processes now gives network engineers a morale boost and a lot more time on their hands to actually engineer the network, which is the fun stuff for network engineers. So going from limited to task automation really, in this case for our particular customer, really did show some substantial benefits for them.

Morgan Stern • 44:11

So Rich, before we go on, I do want to kind of emphasize something that you’ve mentioned here, right? This notion of if it’s a two-hour manual process, there’s a lot of room for interruptions. There’s also a lot of room for manual errors to creep into things, right? So for some of the projects that folks are undertaking, the improvement in accuracy is as big as, if not an even bigger impact in terms of the overall outcomes. That if they don’t have these opportunities for manual errors to creep up means they get it done right the first time. And so we had one team that we were working with, and granted it was a very complicated process, and they said, you know, our rework factor is 2.5. And I said, what does that mean? That means for every one we do, we have to go back sometimes two, sometimes three times because of errors that creep in. Again, very complicated activity, which means that there was a lot of opportunity for errors, but by automating that, they took that down. So it was right the first time, which immediately improved customer satisfaction, but also gave them way better velocity in getting things done. Oh, absolutely. And again, for the practitioner, not having to go back and backtrack, being reminded of the mistakes you made and having to backtrack and fix those. I mean, that’s awesome. You know, even for the practitioner, that’s amazing. For sure. For sure. Okay, so just to kind of ground ourselves again, as we’re wrapping up today, we talked about that transition from from limited automation to task automation. In the subsequent next section, we will be talking about task automation to process orchestration and then finally we’ll wrap up the series with the process orchestration to self serve networking. I think what you will see as we deep dive into each of these is you’ll see that focal point of, of what do I need to be thinking about will shift, the kinds of outcomes you can expect will evolve, the kinds of business impact will grow.

Morgan Stern • 46:25

But as business impact grows also your ability to navigate, not just your own team but across multiple teams becomes important. So we’ll talk more about that in the upcoming sessions. So, as we’re wrapping up rich I want to say thank you for, for, for your contribution to this, it’s, it’s always fun, because you bring a little bit of a different perspective but complimentary to the things that I’m seeing and experiencing in the field. And so I’m looking forward to our to our next sections where we go even further.

Rich Martin • 46:59

Absolutely. You’re very welcome. Thank you. You’re very welcome. Okay, folks. This wraps things up. If you have any questions, as always, we will respond to you from the chat window. We’ll follow up with you via email or other methods. And we look forward to seeing you for the next section. Thank you.