Introduction to the Network Automation Maturity Model How to Assess Where You Are

Rich Martin • 00:00

Hello, everyone. Welcome to another ITential webinar. We’re super excited to really kick this one off. Today, we will start this series on network automation maturity model, something that we’ve come up with working with customers and our own experience working with customers and prospects over the years. You’ll notice that I am joined by an esteemed colleague, Mr. Morgan Stern, for this series. Morgan, why don’t you take a moment to introduce yourself and give some perspective on what you hope to cover in this, and then I’ll catch it after you’re done.

Morgan Stern • 00:34

Cool. My name is Morgan Stern. I’m the VP of Automation Strategy for Itential, very closely with folks in the industry to help them craft out how they’re going to deploy automation and orchestration in their environments. I am thrilled to be co-presenting with you today, Rich.

Rich Martin • 00:52

Oh, thank you. Thank you. And as far as this series is concerned, some of the perspective that we definitely want to provide here is Morgan can help with the leadership. He’s going to take more of the leadership perspective. And myself, I’m Director of Technical Marketing at Itential. My background goes back to a practitioner’s background, a long, long time ago, a network practitioner’s background with a programming background. So I’m able to, from my own personal experience, understand and relate to a lot of this that networking teams are going through as they’re starting this automation journey, but at the same time, bringing in perspective from talking to prospects and customers as well. And so with this, we want to start this off with how to assess where you’re at in this network automation maturity model.

Morgan Stern • 01:41

So, Rich, one of the things that is real helpful for folks to understand is the whole notion of maturity models. And I first became aware of the capability maturity model some years ago. It was originated in the 80s, before my time, but it was originated in the 80s because they recognized that there was the need to be able to measure and talk about different levels of maturity in the software development space. And it’s evolved over time, it’s kind of gone through multiple iterations, but it’s become at least a good baseline for groups to be able to talk about where they are, and ultimately where they should be and where they want to be. And so this is something that can be used by leadership, it can be used by teams. But it really gives them a framework for being able to talk about their level of maturity in a couple different dimensions, but all around a particular topic. So the notion of maturity models has been around for a while. I think that as folks have become more comfortable with them, they’ve started to use it in ways to help identify gaps, to define strategies, to create frameworks, to talk about different choices that they need to make around tools.

Morgan Stern • 03:03

But then ultimately gives them something that they can say, okay, today we are here, the business needs us to be maybe here. Let’s use this as a mechanism to craft our strategy to help guide decisions that we need to make about the work, about the folks that we bring into the team, about the kinds of training we need to do, about the kinds of processes that we need. But it becomes really a better model for them to be able to identify gaps. today’s state and the required future state and what are the steps to get there?

Rich Martin • 03:40

Yeah, that’s fantastic. I think from a technical perspective, we were probably not as acquainted with some maturity models. I know around network automation, especially it tends to be very organic. And so sometimes it just feels like you’re stringing things together with bailing wire and whatever you have available to you. And so being able to step back and see a maturity model from the technical perspective really comes with a lot of benefits and we’ll unpack those as we continue.

Morgan Stern • 04:12

Cool. So Rich, with that said, now go ahead, you can jump back. With that said, let’s talk about why do we think it makes sense to apply a maturity model in the network automation space?

Rich Martin • 04:25

Sure. It’s interesting, our perspective, having spoken to customers for many, many years now, can be illustrated with a single question that we can unpack. The question is, are you automating? And depending on who you speak to, you almost always get a yes. But when you unpack what the yes means, it becomes really, really enlightening. So for instance, if I’m speaking to somebody on the networking team and they’re focusing on the SD-WAN part of the network, that domain, the answer is going to be yes, of course. We deployed SD-WAN last year. We’ve rolled out a lot of sites.

Rich Martin • 05:04

That controller that we use for the SD-WAN automates all these changes for me and anything that I need to change, I can push a button and it automates those changes to that subset of devices that we’ve deployed. That’s automation, right? we might talk to somebody else who says, we ask the same question, are you automating? And they say, of course, we’re automating. We’ve got a ticketing system or a service order system. And when that service order kicks out, it automates multiple tickets to multiple teams so that they can do their part. So that’s a form of automation.

Rich Martin • 05:34

We might speak to somebody on the datacenter team and say, hey, are you automating? And they say, yeah, absolutely. We found a couple of scripts on Cisco DevNet that we’re using. We modify their Python scripts and now we can do some of the more common networking changes. And then you might ask another person, are you automating? And they’re saying, yeah, we’re using some RPA software to automate some of our more common point-and-click tasks, those kind of things. And when you look at it, these are all forms of automation.

Rich Martin • 06:05

Yes, they are. And they’re all valid forms of automation. But does it actually solve the problem of automation in the world of network automation? No, there seems to be something more that needs to be done. Because if everybody answers yes, but there’s still a need for more automation, then obviously there’s maybe some misunderstandings, some misconceptions on what automation is. So having this network automation maturity model is going to help ground, and like you said earlier, chart a course and provide a framework so that you can put a strategy around it and know where you’re at and know where you’re going.

Morgan Stern • 06:40

I think what’s been interesting is, as we’ve been doing this for a while, and if you look back 10 years ago and you ask people, are you automating? Most people would say no. Nowadays, as Rich pointed out, most people would say yes. And what we’ve come to realize is that it is a much more nuanced and granular kind of thing than being able to say yes or no. That there are different dimensions of automation, there’s different technologies that people are automating, there’s different tools that people are using, there’s different areas that they’re automating. And so asking the question, are you doing automation or your boss asking you, hey, are you guys automating? And then everybody says, yes, yes, yes.

Morgan Stern • 07:20

It really becomes a not very valuable conversation when you think about it in those terms. And so as we started to look across the community and look across the different kinds of projects that people were doing, the different implementations, the different tools that people were doing, we started to see some pretty consistent patterns. And so the idea was, let’s think about these patterns and are there any kind of meta models that we can look at around clustering some of these patterns so that we can come up with something that gives people better guidance around how to answer the question, are you automating, then yes or no, but to be able to talk about it with some level of sophistication and some level of nuance so that people could then start to use those benefits of a maturity model, but applying it towards automation and orchestration so that they could use it to be able to say, today we’re here, the business really needs us to be here. Now, here are some predictable steps that we can use or some tools that we can use or some approaches and processes or scopes that we can use to be able to get us to where we are. So Rich, can you talk about the automation maturity model as we’ve defined it?

Rich Martin • 08:36

Sure. As a starting point, everybody comes from a place of limited to no automation. We’re seeing less and less people in this mode because we’ve just seen over the years, the importance of network automation really take hold. A lot of folks are being driven to look at, either through necessity or because of self-preservation, we’ve got so much work going on that I’m doing manually on the networking team, we have to have something. A lot of times, the focus starts with simply what is out there, how do I get trained on it, and in some form of enabling me to get started with my first network automation use case. The next stage typically leads to what we call task automation. Now, you’re starting to get a good hold as a networking practitioner of the tools that are available. Maybe you’re doing Ansible, maybe you’re doing Python, and you’re getting a grasp on the tools, and now you’re really starting to focus on the individual activities usually very much self-centered.

Rich Martin • 09:45

What are the things that I have to do on a daily basis that create the most backlog, take the most amount of time because of doing things from a CLI perspective. They’re looking at those types of tasks, and now applying the knowledge that they have learned from the previous step and the training and enablement, and applying that knowledge of these new tools, these automation tools to focus on resolving those things. It could be a configure. Every time I need to make a change at the data center to provide network resources to a new server that’s been requested, I have to make this bundle of changes, 20 different CLI commands. Now, I’m taking those tools and saying, let’s focus on that individual activity. Let’s use the tools to accomplish that. I now take that task and I minimize it to being able to run a script or a playbook or some automation resource on top of it that gets that done for me.

Rich Martin • 10:48

Now, as this progresses, what we typically see from our customers is task automation is a great starting point and gets your feet grounded in being able to build the confidence to automate certain things. In fact, you’ll also start to notice that there’s a realization that if I’m only doing automation in a certain network domain like the data center, a certain request like a database request for a new service might include the need to go into another network domain and do automation there. Now, there’s a starting of a broadening of a view that says, hey, these two things are linked together. These two automations tasks are linked together. How do we now start to automate across this? Now, what you’re really looking at is a form of orchestration, for the entire process.

Rich Martin • 11:46

And the focus now becomes what are the other steps that are kind of before a network change and after a network change that are part of the typical process. So this is the kind of the end to end outcome that they’re looking for. And now automation starts to take on a lot bigger form because you’re thinking about multiple network domains and the tooling that’s being used within those network domains and how we can orchestrate network changes across that. It could also be somewhat, you know, with security as well and security devices and services that also need to be changed. But at the same time, you’re looking at things like before a network change is made, we have to do some pre-checks and we have to do some post-checks. So that should be also automated. And then you also need things like part of the process like data gathering.

Rich Martin • 12:31

We may have a series of, you know, databases or IPAM systems or, you know, some sort of source of truth where we’re starting to pull information before we make a network change because we need that data. And so if that’s part of a process of, you know, a human going to that system, querying it, grabbing that information and feeding into a script. Well, that should be automated too. And then you start to look at the process, really the bookends of the process. Every time we make a network change, you know, obviously we need to open a ticket, we need to document what’s going on, the, you know, configs before, configs after, the changes we made. Those, and then when we’re finished, we need to do things like close the ticket, but then there’s also monitoring systems and telemetry and all these other systems that now as you start to expand your view of automation beyond just tasks, how do we string all this together?

Rich Martin • 13:25

And that’s the end-to-end outcome that you’re looking at accomplishing when you’re getting into the process orchestration stage of the maturity model. Then finally, we get to the self-serve networking, where the focus is how do we make this on-demand? How do we make this so that it’s not just networking teams that are running these automations, but we’re exposing them and publishing them in a safe and secure way, so that your DevOps teams could have the ability to call into through an API into your automations, so that they can request network resources, do unit testing or functional testing, so you’re fitting into their platform, or you’re also creating self-service catalogs, maybe custom-built or maybe in other platforms like ServiceNow. All of those automations that came from that process orchestration step are now being exposed so that they can be used outside of the networking team. Every step along the way, you’re increasing the efficiency of your automation from a single-user environment where they’re in task, where they’re finally getting their hands around automation and saying, I can make this task from 20 steps that takes 30 minutes to one step of running a script that takes two minutes. Now, you expand that out to the process, which gives you more efficiency because you’re automating more things, and then all the way to self-service, where you’re getting pretty much maximum efficiency by exposing those things to outside users, to end-users, or whoever it is, you’re looking to self-serve with networking resources and services.

Morgan Stern • 15:06

So, there are a couple of different things that are worthwhile to point out at this point. I think as Rich showed, as the scope increases, right, I go from doing a task to doing a process to doing exposure, I’m capturing more of the business process. I’m exposing it to a larger audience, so there’s a sense in which scope and complexity is increasing because I’m moving away from maybe I write a script to do a thing to I’m putting in an orchestration platform to I’m putting in an exposure framework, right? So, there’s some aspect of complexity that goes up, but more importantly, there’s a pretty big aspect of value to the business that the more that you can capture in automation means the less manual effort, means the less idle time, means you’re capturing more of those things that are happening as part of the automations, which means ultimately you’re eliminating idle time, you’re improving efficiency, you’re improving productivity for the team members in a way that scales much better than just adding people. You’ve got this aspect of cost and complexity, you’ve also got this aspect of business benefit. Now, one of the important things, and this is really a message that we want to communicate throughout this is, the right place for any given organization, any given team, any given company, isn’t to assume, I need to get to that self-serve automation stage. That may work for a given environment, and other environments may not be appropriate.

Morgan Stern • 16:39

One of the questions as a business leader, and as a technology person, as you’re looking through this, is saying, really, what is the right place for my company? What’s the right balance of cost, effort, benefit for this to be able to make the most sense? Don’t always assume, I got to get to stage 4, or if I’m at stage 4, I’m not doing the right things. Really take a look and say, what does the business need, and what does my team need, and what does the organization need for us to really maximize business value and be able to deliver on the requirements that are there? One of the things that we looked at was to talk about, what are the benefits as you’re transitioning from one phase to another? On the left, we’ve got, what if I go from limited to no automation to task automation? What benefit am I going to get from here?

Morgan Stern • 17:31

Then subsequently, what about task to process and then process to self-serve? The primary benefit from a business standpoint of moving from nothing to task automation is you’re going to see a significant bump in engineer productivity. Because they are the task-level workers, they’re going to start to see some tremendous bumps in their ability to get their work done. If they needed to do one upgrade in a day, now they can do 10 upgrades in a day, or if they needed to do one policy in a day, now they can do 100 policies in a day. There is a massive… opportunity at the engineer level to see that increase in productivity. Now, while that is super attractive and really starts to get people excited about automation, what they start to recognize though is, while it really has a great impact at the engineer level, doesn’t necessarily have a great impact at the process level.

Morgan Stern • 18:31

What I mean by that is, if that engineer’s task is one step of six or seven steps in an overall process, where let’s say an internal customer is asking for a resource, and ultimately that gets delivered to the engineer to execute, there may be other steps that happen through the ordering system, through some of the inventory systems, through some of the assurance systems. There may be multiple steps that happen before it ever gets to that engineer. When you move from task automation to process automation, it’s really about how can I impact that end-to-end process? The benefits are then on that end-to-end outcome. Can I deliver it faster? Can I deliver it more accurately? Those become the things that are really moving the needle with respect to the ability to close tickets faster, the ability to deliver a service product faster.

Morgan Stern • 19:28

The end customers then start to see the impact of being like, hey, I used to have to wait two weeks to get this change to a firewall, now I get it in 30 seconds. And so that then becomes an enabler for the larger business to be able to do the things that they need to do more quickly, more accurately, more effectively. The major benefit of moving from process orchestration to self-serve networking is now I’ve suddenly flipped the switch. So all of those capabilities that may be needed to be initiated by a ticket or an email or a phone call or whatever, all of those become things that the end user can request themselves. So, the primary benefit there is I went from something that I might have to wait to something I can get on demand, which then drives the consumption of those automations dramatically up. And so you start to say, well, if my outcome was that every time somebody orders something and I’m doing process automation and I can deliver it in a day, now I can deliver it much more quickly, much more repeatably without necessarily having to involve some of my network resource, like folks, but instead what I’m doing is taking their knowledge, their capability, their expertise, I’ve basically packaged it in a wrapper that anybody can use, which means instead of maybe running a hundred times a day, I can run it a thousand times a day for no incremental cost, right? So it becomes this way to really unlock a ton of value without any of the constraints of the engineering time or the people or the things like that.

Morgan Stern • 21:07

So you start to see it almost becomes this exponential curve of value because now you’ve packaged that value and you’ve made it usable by a much larger audience, which means every time they use it, they’re getting the value and you’re not incurring any of the additional cost. Rich, do you want to talk about some of the technical pieces of the perspective?

Rich Martin • 21:28

Absolutely. Technical benefits from practitioner’s perspective, going from limited automation to task automation, helps to reduce the work effort. I’m not saying get to a point of doing nothing, but what we’re saying is there’s a lot of toil in manual work. Even as good as network engineers are on the keyboard and on the console, there’s still a lot of repetitive, monotonous work. To be honest with you, that’s not the fun stuff of networking. Nobody goes into networking going, I want to do the same repetitive thing 100 times a day. Being able to get that first script done to reduce the amount of CLI work that I used to have to do, is a real reduction in work effort, especially when it comes to lots and lots of backlog that gets done on a daily basis. That improves morale, I’ll just be honest with you, because now that focuses me up to do fun stuff.

Rich Martin • 22:26

Just like on the business benefit, you can do more of those tasks in less amount of time as a practitioner, freeing up that time. Then the fun stuff is, how do we build bigger, better networks? How do we optimize the network that we have? Those things. That really brings a nice balance back to that role when you start to engage into more and more of that task automation. When you go from task automation to process orchestration, you’re increasing that benefit from a technical perspective because now, it’s interesting, task automation is automation. However, if you’re swivel chairing between multiple systems and what we mean by swivel chairing is, imagine I’m about to make a network change, right? I can use my script that I’ve written, but I need to feed it some sort of information, right?

Rich Martin • 23:19

I need a new IP address, I need a new host name, I need to update DNS, something like that. And then, so I have to go to each one of those systems individually and log into them. do a query through a form, copy and paste it back to our old handy notepad so that I can feed it back into my script, that’s swivel chairing. Now, as you start to unpack all of these systems as part of this process, you recognize that I’m doing orchestration manually now. I might not be doing CLI manually as much anymore, but I’m definitely orchestrating manually across all these systems, and there’s a tremendous amount of time-saving when you can start to build automations that can impact each one of those steps that are all relevant as part of that process to get things done. So steps like, that are often overlooked in the first stage, things like data gathering, things like opening tickets, updating tickets for documentation purposes. Honestly, a lot of times that doesn’t get done as often as it needs to when you’re doing manual changes at four in the morning, trying to run through

Rich Martin • 24:27

trying to get things done before the maintenance window closes or you’re troubleshooting something, you know, and trying to get right, you know, there’s a lot of pressure on you. A lot of these things kind of fall off, you know, fall off the table a bit because there’s so much pressure going on. So swivel chairing and all that, those processes are big part of it. And then that really helps not just technically, but the team and the business as well, when you can automate those things and have consistency in those automations. And then finally process automation to self-serve networking or process orchestration to self-serve networking. Removal of a lot of manual requests. So,

Rich Martin • 25:06

The not needing, you can start with certain services now that may not need the approval process or the amount of tickets that they use to generate in order to get started, because the automations that you’ve been building through these different stages are incredibly robust. They’re built off of the procedures that network teams have been doing for a long time. And so they’re very sophisticated in these automations so that when you self-serve them, there’s a high amount of confidence that they’re gonna work. And really this is useful because it does free up some more time for the network practitioner. It also makes that end user experience much, much better being able to get what they need when they need it. But at the same time, it helps networking teams also kind of focus more on oversight of the resources and allocation of the network. And this is critical because a lot of times there’s no time to do capacity planning in an amount of time that would be helpful to do it.

Rich Martin • 26:10

A lot of times it’s, oh no, we’re out of capacity here or there. Being able to now orchestrate all of these and then have the ability to see and oversee all of your resources and your allocation and having the time and the tools to do that helps with that a lot. So that’s another great technical benefit as well. And time for a quick commercial break here. I just wanna mention, watch the rest of the series. We’ve been giving you some exposure and some ideas and some thoughts around each one of these stages in the maturity model. Hopefully this is really piquing your curiosity.

Rich Martin • 26:44

So I do want to ask you to stay tuned and watch the rest of the series as we go through them coming up, where we will deep dive into each one of these stages. So you can get a better view of what that looks like and help to assess where you’re at, what you need done. And like Morgan said, ultimately what’s best for your business as far as where do we need to get to on this maturity model?

Morgan Stern • 27:06

So one of the questions that we get pretty frequently is folks saying, well, how do I figure out where we are? If you think, if you’ve got this four stage maturity model, I wanna be able to place my team or my company on that. One piece of this is to recognize that there may be a situation where you have teams at different levels of maturity. There may be organizations, a lot of times we’ll see a pretty good level of sophistication in the cloud teams because of the way that the tooling is set up for them versus other teams may be doing things more manually. So the one important point is to recognize that there isn’t one level of maturity that would cover the whole company. For example, you need to be thinking in terms of functions, teams, organizations, things like that. Once you drill down and figure out what the scope needs to be, there are a couple of things that you can look at that will be indicators of any given level of maturity.

Morgan Stern • 28:05

One is around the tooling. One is around the kinds of activities that you’re automating. So as Rich was talking through the different examples, if it is a situation where people are just writing quick scripts and they’re just using it to automate one activity, well, that’s pretty good indicator that you’re in the task automation space. However, if you’re starting to look at this and say, no, no, no, we’re chaining together multiple tools that don’t require physical interaction or human involvement, then you’re thinking more around process orchestration. Additionally, in the same way that there is this consideration that maybe you think about it in terms of teams or organizations, you want to take a look at what percentage of activities you’ve actually automated. So you may be doing scripting, but then when you take a look what your team is doing, you may recognize, well, we’re responsible for 10 or 15 things to the business, and maybe we’ve scripted two of them, right? So there’s a notion of what percentage of things have been done.

Morgan Stern • 29:06

And again, as we talk about the trade-offs to say, well, there are certain activities that aren’t well-suited to automation. Things that, for example, require a whole lot of manual labor, physical activities, things like I’ve got to install a device physically in a rack. That’s not necessarily something that you can automate, but you can automate around it. So you start to think about to say, what are the tasks we’re doing? What are we responsible for overall to the business? What percentage of those are things that we’ve done? Those start to give you the right framework for being able to then say, ah, okay, for this set of work or for this team, we’re at this stage.

Morgan Stern • 29:50

And when I take a look at the percentage that we haven’t done yet. Well, if there is a significant amount of those that are achievable, but you just need to evolve where you are, then think about, well, what’s the cost to do that and how do I get there? So, Rich, do you want to kind of talk about some of the indicators specific to things like tools and use cases?

Rich Martin • 30:11

Absolutely. Of course, the starting point for a lot of folks is limited to no automation. You’re going to typically find some probably, you know, tools around SolarWind, you know, some of their suites to help understand and maybe just do some basic troubleshooting or basic management of your network and your network devices and services. It probably does a, you know, a decent job for what it is. But as you step into automation, you really, you know, you start to see more tooling that’s focused on, you know, being able to be automated through APIs and things like that. But you start somewhere around there. A lot of your, you know, instead of having a source of truth that’s, you know, maybe accessible through a web interface or through APIs, you really start with spreadsheets, Google Docs, things like that for IP addresses and host names. Some of your, you know, your orders or your service requests may be coming in through email. And again, this is, you know, as the network becomes more and more critical in these organizations. that’s really going to start to push, hey, we should really be looking at our tooling, we should be looking at automation, and your use cases are really not there yet. I think you have some ideas, especially as the backlog builds and you have a lot of work that needs to be done that really could be done more efficiently with automations, then your use cases start to develop. But that really starts to now move you and shift you into task automation, where your tooling starts to progress as well. And you start to look at maybe Ansible or Python, those are the two big ones now. In fact, we are starting to see Python really take a bigger foothold.

Rich Martin • 31:58

A lot of folks maybe have started using Ansible, but then have now started to shift into doing a little bit more with Python for different reasons. Your tooling also is going to include maybe some vendor solutions in different network domains that provide automation within maybe task or multiple task automation within that domain. SD-WAN is a great example. If you deploy an SD-WAN solution, it’s always going to come with a controller. That controller is always going to come from that particular SD-WAN vendor, and it’s going to give you a subset of automation, task automation typically within that particular domain. You’re also, as you start to build this library of automations and scripts, you’re going to need some way to execute them. So you might be looking at something like Rundeck or Ansible Tower or the Ansible Automation Controller now.

Rich Martin • 32:52

So you see this more sophisticated set of tools also start developing as more and more automation becomes part of what you’re doing on a day-to-day basis and a focus for that team. The use cases, honestly, they probably start off pretty simple with read-only stuff. How can I correlate data from different switches to troubleshoot a problem so that I don’t have to spend much time? It’s more of a read-only thing. That’s usually where it gets started until you feel an amount of comfort with the tooling and the systems that you have. And then eventually it progresses to, okay, let’s start to really tackle some of this backlog or tackle some of the CLI toil. And so they start to look at things like, you know,

Rich Martin • 33:36

port and VLAN changes that need to be done all the time. It could be also along those lines with security, firewall updates and rule updates, things like that. Then the one that always pops up, it’s continually a problem is software or firmware upgrades on networking devices. That’s a big one because there’s always new firmware coming out, software coming out for your different routers and switches with features or security updates, and there just seems to be never enough time to get it done and get it done successfully. Those typically tend to come really at top of mind for your first use cases. Then you’ll start to develop more and more libraries around that in different domains as well. And then as you shift more towards the next stage of process orchestration, you can see even more maturity in the tool sets, right?

Rich Martin • 34:28

So now maybe you’re more mature on the Python and your Ansible usage. You’ve got more experience and expertise and confidence in those tool, those toolings, but you’re also now leveraging as part of this process orchestration, integration into more specialized systems. So you might have DDI systems for DHCP, DNS and IPAM. So now you can access those programmatically in your automations and orchestrations, as well as integrating with your ITSM system like ServiceNow, JIRA for updating and documenting tickets and closing them out. You’re also now integrating with, you know, monitoring and telemetry systems. So you’re gonna see those. This is a great example of something that sometimes gets overlooked with manual process in the heat of the moment of getting things done, allowing the network operations team, the ability, you know, communicating with them that I’m about to make a change on a device which may cause some sort of alert or alarm to go off in the monitoring system.

Rich Martin • 35:31

So please take that out of service for the next 30 minutes or whatever the maintenance window is. Automating that. along with making sure you’re taking a look at your telemetry systems as part of the automation. That might be part of a pre-check or a post-check in your orchestration. And then ultimately, team communication is big, especially as network teams get bigger and bigger and bigger and as they are always interrelated, accessing some sort of network web service or database is always gonna have multiple network domains involved. So if you’re doing a change on one part of the network, it’s going to have an effect on possibly access from another part of the network. And so being able to automate

Rich Martin • 36:21

and communicate together as a team as part of that. So you’ll see a very sophisticated method of team communication, whether it’s Slack or Teams with channels set up and then being able to orchestrate and involve your orchestrations with those as well just to give everybody a heads up and oversight in what’s going on. And then your use case examples will obviously grow as well as the view of what you can do in automation broadens. So it’s gonna be more of an end-to-end process that includes what happens when we open the ticket all the way to updating and closing the ticket. That always includes a set of really robust pre-check and post-checks to make sure that when we make a network change, the network state is in the right place for us to make those change. And then after we make those changes, let’s ensure what we intended is working as well as making sure we didn’t impact anything else. and then those changes are going to affect multiple network domains.

Rich Martin • 37:18

Being able to orchestrate changes in those different network domains along with all of the other systems that are part of the whole process. Then ultimately, you could land on self-service networking, where you’re going to integrate with the entire suite of DevOps tools and platforms and teams who are trying to create self-service mechanisms and catalogs so that they can offer these automations in a way that bolsters efficiency for the organization. Use cases here are ITSM service catalogs. ServiceNow is a great example. ServiceNow has really taken a huge foothold in IT organizations as the center of the IT galaxy. We’re seeing more and more of our customers and prospects talking about the need to deliver self-service catalogs for network infrastructure and resources inside of ServiceNow, but there are a lot of other platforms to do the same. Then figuring out a way to offer network as a service and integrate with DevOps pipelines in a way that works for their platform.

Rich Martin • 38:27

That could be using API calls that are attached to your automations and your orchestration processes so that they can be called from within those platforms and pipelines.

Morgan Stern • 38:40

For folks that want to understand how you can use the maturity model to evolve, we’re going to talk about it again from two perspectives. For leaders, as I’ve said, critical thing is to make sure that you sit down and say, what does the business need from me or how can I impact the business most effectively? Is it for me to be able to eliminate excess cycles and idle time in the process? Is it about being able to process more transactions, like more actions per day? The critical thing is to say for the business, how can I best support them? Then what are the ways that I’m going to measure my ability to support the business? It may be that you’re looking at cycle time and you could say, I need to be able to accelerate this program.

Morgan Stern • 39:32

To be able to accelerate this program, we’ve got to deploy 10,000 units of work. My ability to do that is only gated by my ability to automate it, which means manually I would be looking at six-month program. If I do it automated, I can do it in four weeks, for example. It may be around energy and productivity. That may be the metric that you’re using. In some cases, folks that we’ve worked with have looked at their cost to perform a particular operation. By applying the right level of orchestration to it, they could significantly reduce their calculated cost per action.

Morgan Stern • 40:10

That was the thing that they focused on. But the critical thing is, as we talked about, what are the benefits associated with each phase? Remember, for task automation, it’s really about improving engineer productivity. Around process orchestration, it’s really about impacting the outcome. Those are the things that you want to focus on to say, hey, if my requirements are outcome-based, then I really need to focus on ways that I can accelerate our journey towards process orchestration. Once you start to think about it in those terms, you can start to quantify the benefits to the business, which then help you to justify the cost. There will be some organizations where the costs are going to outweigh the benefits, but you need to be thinking in terms of what’s the window.

Morgan Stern • 40:57

Am I looking at it from a six-month standpoint? Am I looking at it from a two-year standpoint? That window of planning will have a pretty significant impact on that cost value calculation. So think in terms of that as one of the dimensions in evaluating how do I get from, let’s say, phase two to phase four? What’s the window I need to get there in? What’s the benefit I’m going to deliver to the business? And then measure it that way.

Morgan Stern • 41:25

Thank you. Rich, can you talk about the practitioner ways to use the maturity model?

Rich Martin • 41:29

Yeah, absolutely. Thanks, Morgan. And I think that it’s important for the practitioner because a lot of times we are kind of in our own silos with so much to do day to day that we miss the big picture. And I think the maturity model can help them to evolve by helping them to understand the big picture. A lot of times, one of the insights is that we’ve seen is that, you know, and we’re gonna share is that this is so organic in a lot of organizations and big organizations too, where a practitioner is reaching out to find the tools to fix, you know, to automate some problem they or their colleagues have. And then it just kind of blows up and blossoms from that in a way that they didn’t ever expect it, right? Because the network, you know, the network team is showing off some automations and somebody says, hey, give me a copy of that automation.

Rich Martin • 42:22

I wanna do that. Now it’s kind of out of control. And, you know, once it maybe, once it gets to the leadership, maybe it kind of grows even more organically. And so understanding the big picture help can help align on those tools, the resources, the people, the time and the skill sets and the roles that are going to be necessary. So you can actually have an opportunity to sit down and have a conversation with your team and your colleagues to say, okay, wait a minute, let’s take a look at this model. We’re here, we’re doing task automation for this team, but if we need to expand it here and share those, what are the things that we need to do as far as tools that can help us get us there?

Rich Martin • 43:08

How long is that going to take? One of the things that we found is that a lot of times, network practitioners, even with the best intentions on sharing their automations with their team, overlook a lot of skills and resources that they need. Like I need a new server, I need to make sure it’s secured. I need to learn all of these new tools and install them and manage them and administrate them. I need logging and auditing. And so this helps them instead of, trying to approach this in an organic way, like I said earlier, kind of like, whacking through the weeds, trying to figure out where you’re headed, this gives you the big picture and a roadmap to go forward.

Rich Martin • 43:45

And on top of that, one of the things, if you’re going kind of the organic route, you don’t really think about the best practices for each phase and what comes along with it. And I think for me, looking at the maturity model from a practitioner’s perspective, not only are understanding the tools and the resources and the people and the skills that we’re going to need to be successful in our maturity model and our strategy for moving forward, it’s being able to have a discussion with my leadership, taking a look at this map and then mapping a route through it and having those kind of frank conversations on the front end versus more uncomfortable conversations on the back end. Because like I said, with best intentions, I think we can do this without really knowing what’s ahead of you and being able to avoid a lot of potential traps and pitfalls. And I think that for the practitioner’s perspective is really a big, a big plus for the maturity model to being able to have these discussions and shining a light on what’s ahead of them.

Morgan Stern • 44:50

Okay. Well, this is going to conclude our first session around the network automation maturity model. But as Rich said, this is one of a series. We encourage you and invite you to participate in the upcoming sessions, where we focus on those transitional phases of saying, how do I evolve from limited automation to task automation? That’ll be in October 18th. On November 8th, we’ll talk about evolving from task automation to process automation. And then in December 6th, we’ll wrap it up by talking about the evolution from process orchestration to self-service networking. So for me, I want to say thank you for attending the session.

Morgan Stern • 45:29

If you have questions, you can ask them in the chat, we’ll answer them there. I will hand things over to Rich for the wrap-up.

Rich Martin • 45:35

Thank you, Morgan. It has been a pleasure so far. I look forward to the rest of the series with you and with our audience. Once again, thank you very much. If you need more information, please go to itential.com or you can contact us here with this information. And you can also sign up for a workshop where you can go through at your own pace and speed to get more acquainted with our platform and how we can help you on your automation journey. Once again, thank you very much and goodbye.