Network Automation Maturity: Evolving from Task Automation to Process Orchestration

Rich Martin • 00:02

Hello, everybody. Thank you for joining us on this webinar, where we will be continuing our Network Automation Maturity Series. Today, we’re talking about how to evolve from task automation to process orchestration. My name is Rich Martin, Director of Technical Marketing at Attention. And my role here is to help facilitate the practitioner’s point of view when it comes to exploring how we go from one stage to the next. And as always, I am joined by my friend and my colleague, Morgan Stern. Morgan, why don’t you introduce yourself and take us away?

Morgan Stern • 00:35

Sure, Rich. Yeah, my name is Morgan Stern. I’m the VP of Automation Strategy at Itential. And my role in this session will be to talk a little bit about the considerations and factors that are relevant for the leadership. So managers, directors, VPs, and those kinds of folks. So just to set everybody context for what we’re going to talk about today, this is part three of a four-part series where we’ve been talking about the network automation maturity model. Previously, we’ve talked about the transition from limited to no automation to task automation. In this session, we’re going to focus on what we see as being a really critical phase transition in the industry today, which is really about how the folks who have gotten good success out of doing task automation. Can move to the next level and can impact to the business even further by taking those tasks and Stitching them together and providing process orchestration So if you remember the one of the primary benefits of task automation is around improving the efficiency of individual activities When you make the shift to the process orchestration, you not only get all of those benefits, but then you also start to see Significant acceleration of the end-to-end process which means you get things done faster Not only the individual tasks, but the entire business process which can be faster time to revenue, faster time for fault resolution, faster time to project completion.

Morgan Stern • 02:14

All of those kinds of things become possible when you start to focus around process orchestration. And again, we see this as a point that many of the folks out there in the audience and in the larger community, this is a point that’s relevant for a lot of folks. In our last session, we’ll talk about the transition from process to self-service networking. But for now, let’s go ahead and just get started. So Rich, can you refresh everybody’s memory on the common characteristics of task automation?

Rich Martin • 02:42

Yeah, absolutely. So when we’re talking about task automation, really what we’re focused on, especially from the practitioner’s point of view, is one of those routine repetitive tasks that typically I’m doing day-to-day, week-to-week. Maybe there’s a significant backlog that’s attached to them. If I don’t get to these, then they continue to grow and grow. Those are some of the typical things that we start to automate under task automation. We’re reaching for the tools that are available out there to us, usually open source tools like Python or Ansible are usually the tools of choice for these. You’ll also see commonly in task and teams that are in task automation is they manually trigger or run their automations.

Rich Martin • 03:28

So this also could mean execution environments that are individual between different members of the team who are curating their own automations, building their own automations. And typically work is managed via tickets, ServiceNow, Jira, or some other ticketing systems, emails, things like that, that are really how we manage the day-to-day work and document and update. Along that, you also see a lot of common tools in task automation. I’ve mentioned Ansible and Python, as well as some of the libraries around that. You’ll start to see a lot of vendor solutions still, so vendor-provided solutions, especially those around things like SD-WAN, which tend to have controllers that are vendor-specific for the solution. You might start to also look at some execution environments to help manage some of the script growth that you’re using when you’re in task automation. Like I said, your use cases are going to be a lot of the repetitive things that get done that don’t require a lot of brain work, but quite honestly, network practitioners are really good at doing them because they do them all the time.

Rich Martin • 04:39

In fact, if it’s something I can do in my sleep, it probably needs to be automated, and that’s where task automation is really where you get started, so things like port, VLAN, interface, configuration changes that may occur quite a bit, and then software upgrades of all the different kind of devices in your network. So as teams kind of grow in their task automation stage, they can be really complacent and think this is really where life is good. But I think it’s important for practitioners and teams to kind of try to figure out whether it’s time to evolve. And there’s some really good indicators that tend to pop up if you’re paying attention that can help you understand, yeah, maybe it’s time to move from task automation or maybe we’re outgrowing task automation or maybe we’re not getting as much out of task automation as we should be. And so these are some indicators that we found that come up quite a bit as we’re working with prospects and customers. I mentioned this a little bit earlier, as your library of tasks, kind of your automations grow to automate these tasks, you’re spending a lot more time managing these scripts than executing them. What do we mean by that?

Rich Martin • 05:50

Um… Where you know, am I making sure everybody’s got the right script because everybody’s downloading the script and I find the one writing these Scripts, I got to make sure everybody’s is is is using the right one. So I’m am I flagging them down? Am I sending them emails? Wouldn’t it be great if I had a single place to manage these from or to put them from if I’m creating those things On the fly then I’m spending a lot of time managing securing them Making sure like who’s running them those kind of things Trying to solve those kind of problems now that I want not only myself to run these scripts my team to run these scripts to increase participation Despite the fact that the scripts are helping me reduce the amount of time that it takes to make changes on the network for these particular tasks, I’m still seeing a certain amount of backlog that’s still growing and preventing me from doing other things. So this seems strange, but what we found is that as you start to become more efficient by using automation, you start to, you know, for a number of reasons, you’ll start to see more of your customers, whether they’re internal or external, start to utilize those resources because, you know, that spigot is running faster, so now I can get it faster. And so you might start to see an increased backlog. And not only that, as the growth of the business naturally continues, you’re going to see more and more backlog. And so now you’re seeing, well, my tasks, the efficiency of these task automations, I need to get more out of my automations. And how do I start to do that? So if you see a growing backlog, that might be a good indicator. Another one we see is that perhaps you don’t feel comfortable sharing your script for someone so someone else can run it.

Rich Martin • 07:33

And this is kind of a hidden one, right? Because what that really indicates is that you’re not going to be able to increase participation of who can use these scripts because you have some issues with sharing your scripts. So some of these is I’m afraid of human error getting involved. You know, there’s a lot, if you’re manually running your scripts and you’re gathering data and copying and pasting, there’s all kinds of opportunity for human error. And while I may be really good at feeding my scripts, I’m not so sure somebody else is, or maybe I trust one or two people on the team. But in reality, if we really want to extend and expand the efficiency of automation, it needs to be usable by more than just myself. And so I need to start building solutions to allow myself to maybe enhance and validate inputs into scripts so that other people can run it that maybe aren’t as technical as I am with how these scripts run or how they work under the hood.

Rich Martin • 08:34

That might be an indicator for you to start looking at how to solve these problems so that you can progress forward. Another one is, as you start looking at these task automations and building structure around them, you start to see that there are other processes that need to be automated, and some of them can’t be represented very well in a script. Maybe it’s because the tools that we’re using don’t allow for processes to be expressed in an easy way. Maybe it doesn’t have some of the ways we need to integrate with these processes or these systems, which brings us to this last piece here, is maybe the tooling that we’re currently using doesn’t integrate with any of these systems, or at least doesn’t integrate easily, or maybe requires some maybe more unnatural ways to do integrations, like get another tool, stitch them together with more scripts, and those things, and then that starts to look like a lot more work to manage all of these scripts. If I got to write more scripts to integrate all of our stuff, then I’m going to spend even more time managing these scripts, and this is something we need to start looking at more as a way to evolve from where we’re at to where we’re going, because we’re hitting some limitations here. So those are things that as a practitioner, especially to take a look at, but there are also some things that may be tethering you to this particular stage. So really around task automation, some things to look at that might be keeping you here as well.

Rich Martin • 10:03

One of the top things is as we start looking to expand from task automation, which is looking at these very specific processes, maybe in a single network domain, as we even expand within the networking domain, as a practitioner, if I’m a data center practitioner, I can say, well, it would be great if these automations now could extend into a Cloud environment and maybe start doing some automation with the Cloud team. But hey, that requires some additional stakeholders on the Cloud team to want to work with us on this. I’m not so sure I can bridge that gap. So that could keep me here just within maybe my own particular network domain. But Morgan, do you have any other thoughts? Is this a bigger problem than that?

Morgan Stern • 10:46

It is. It is. And I think one of the challenges that folks encounter that they don’t necessarily anticipate is the fact that as you’re expanding the scope of what you’re trying to do, that means more people need to be involved. That also means people need to trust one another like and trust the tools so that what they typically had been responsible for as a team or as an individual, if that’s going to be now an automated task, that means this could run whenever and they may not be there to see that or to be involved. So that’s a, that is a shift that requires pretty careful kind of management and testing and working to get buy-in because that level of trust typically will exist within a team. But when you start to jump to other teams who are involved in the process, they may be new to that. It’s really something to pay attention to.

Rich Martin • 11:40

Fantastic. What about this next one? Teams are unsure how to adopt. Now, I can tell you from a network practitioner’s perspective, as we start going beyond the networking domain and start to look at automating processes, we’re certainly going to be unsure of a lot of those things. What are some ways or some thoughts that we’ve had and worked with the customers with about how to tackle this one?

Morgan Stern • 12:06

A lot of the teams that we work with are typically looking down at the network and are very comfortable with, I’m going to use a tool that’s going to talk to this device, it’s going to make this change or talk to this API. That is a realm that folks are really comfortable with. Where it gets more complicated is when it starts to either look towards, well, how does the work come in and those are ticketing systems or what are the other systems that are part of the process maybe it’s an inventory system or some other component. I think part of it really becomes then an education process to say, okay, historically, I used to get my work this way. We’re going to move to doing this through an automation. Now I need to work with maybe some of the IT folks I haven’t normally worked with to be able to just understand, what can they provide to me and what do they need from me to be able to automate this?

Rich Martin • 13:03

Yeah, that’s a good one. I think that actually touches back into my leadership’s ability to help bridge between these different stakeholders so that we can start to work together and understand how to interoperate our automations together. Now, this third one is a big one, the single source of truth misconception. From a network practitioner’s perspective as an engineer, this makes sense to me on paper. Before we can start to do any real automation, we need to have some system or database that reflects all of the devices in the network, their configurations, what they’re connected to, down to every CLI command that’s necessary. Then we can start doing some real automation. What is our experience with this one?

Morgan Stern • 13:53

Well, I will say this, you know, a lot of my professional experience has been working in the service provider communication space. If anybody was going to be able to solve that problem of a single source of truth, they would have solved it. And that has been an elusive challenge for as long as the business has been in existence. Right. So, so what does that mean? What that means is they have come up with methods to work around that, that, that, you know, chasing a single source of truth, except in a very small, very static environment is a difficult thing. But there are certainly opportunities to say that in any environment, there are certain pieces that are authoritative for some set of information.

Morgan Stern • 14:37

And being able to navigate in that kind of an environment is becomes really critical to say, particularly when you move into cloud and when you move into things like some of the SD-WAN spaces where controllers are managing a lot of the pieces. that let them be authoritative for what they’re doing, and just make sure that however you’re approaching this process orchestration has the ability to factor that in.

Rich Martin • 15:01

Yeah, and I think that’s critical too, is from the enterprise space as well with all the different and various network systems and solutions out there including Cloud being a crucial part of the networking environment as well. That becomes relevant even for the enterprise. I think one of the hidden costs here is that the longer you go down this path of trying to create this single source of truth, the more you delay your execution of any automation. I think we’ve seen customers having on this path, maybe not fully down this path and realize, this is going to take us a lot longer than necessary, and we really need to start automating things now. What can we do today? Absolutely, yeah. The next one, and I think I hit upon this a little bit, is task automation tools that we’ve already invested in, really we’re starting to see where their limitations are, where they can’t support process orchestration.

Rich Martin • 15:59

That could be around how they integrate with our ecosystem of devices and systems that we need to now call in our automations in order to do things like data gathering, opening tickets, things like that. Any thoughts around this one?

Morgan Stern • 16:18

Well, for me, it’s always been a matter of figuring out what tools are going to be the right fit for purpose, and that anybody who’s developed on anything knows, you can solve a problem with just about any tool, right? That isn’t the point. The point isn’t, could I write a giant Python script that would manage the whole process? It’s really, is that the most efficient way to do it, and what kind of technical debt are you creating, and what kind of complexity are you creating? And so really kind of looking at that and saying, there are a lot of things that are super effective at making scripts to do quick jobs, and that’s what they’re optimized for. Whereas there are other things that are oriented around process orchestration, and so you really want to gravitate towards those as you’re moving up this level of maturity.

Rich Martin • 17:05

Yeah, that’s a great point. I think understanding when your tools hit those limitations, and maybe when it’s time to now, because of the need to move towards this next stage of automation, looking at making a real assessment on the tools, and then having the coverage from your leadership, you know, as a practitioner and say, hey, we can only go so far with this, we really need to invest in something. And I think also, that leads to this next point, you actually see a need to integrate with your ecosystem in a programmable way in order to accomplish orchestration.

Morgan Stern • 17:38

Right. So, so, you know, the way that this manifests in most cases, is that there may be parts of a process that are not addressed through a programmable way, right? There may be data sources that are either don’t have an API, or just have no way of interacting with them, right. And so that means for that part of the process, you’ve got to figure out some kind of workaround. Now, some folks use like, like, RPA tools to do screen scraping or whatever. But it does become a challenge, right? It certainly can be a gating factor. And I know that in the environments that we’ve worked, we have seen a lot of creative workarounds. Because in most cases, there’s just no easy tool to be able to do that for some data sources.

Rich Martin • 18:28

So what you’re saying is, I, it might be time to give up our spreadsheet.

Morgan Stern • 18:33

Absolutely.

Rich Martin • 18:36

All right. Well, well, now that we’ve spoken about that, let’s talk about how to evolve into this next stage of automation and orchestration. So why don’t you take us, take us ahead, Morgan. Sure, sure.

Morgan Stern • 18:50

Within the process orchestration world, the things that are really in common, regardless of what tools or platforms you’re using, is most of the time people will stitch things together with some form of workflow. Could be like a graphical workflow tool, could be almost like a script oriented workflow. But it’s really about recognizing that I need a way to capture, and reflect, and execute all of those steps in the process, and have some mechanism to kind of connect them so that information that gets manipulated or collected during one stage is available to the next stage, right? So you could think of, if each stage is a task, the process needs to have some way of persisting the task through the right, or persisting the tasks through the right set of order of operations, as well as carrying relevant information so that later activities can benefit from the things that happen. Most of the folks who are doing process orchestration will leverage tools and platforms that will simplify integration with their ITSM systems or any of the other northbound systems. So whether it’s ticketing things, whether it’s order entry kinds of things, there’s some way that the work needs to get initiated, and typically it will be some kind of an order or some kind of a request that that system is responsible for capturing and processing, and then it’ll assign it to the process orchestrator to execute on it. Also, the platform will integrate with the east-west systems, meaning sources of information or sources of where I’m going to store things. Could be things like inventory or topology systems, could be network monitoring systems, service assurance tools, things like that.

Morgan Stern • 20:43

Those become participants in managing the overall network. The more that I can connect to them electronically means I don’t need to manually set things up in those systems, I can just leverage the capability of the orchestration platform to be able to manage that information. Another thing about the common characteristics of an orchestration system is the same way that they can integrate with those east-west systems, they can take existing automation assets and they can incorporate those into a larger orchestration. I know we’ve done other webinars on how to integrate scripts into orchestrations, so we don’t need to go into too much detail, but the idea here is if a script is the right tool for capturing a task, why not continue to use that script, but within the context of a larger process orchestration, that you can use the orchestrator to really do the feeding of the script, to say, do this, do it at this point in time to these systems, and that way you’re eliminating a lot of that busy work that would be associated with feeding the script. Also, these tools may integrate with other like DevOps CICD tools, so that folks can use the process orchestration for those contexts in which it makes sense when you’re integrating with a larger like overall DevOps process. For example, you may have an application pipeline that deploys new versions of the application, and part of that pipeline may need to make some changes to a firewall to allow the right ports, and so you can integrate those two systems so that you can use the process orchestrator to manage some of those config management processes that aren’t well reflected in a traditional pipeline. A lot of different tools and use cases for thinking about process orchestration.

Morgan Stern • 22:42

We mentioned like some of the mature Python and Ansible, we’re also talk about the kind of monitoring and telemetry tools that get integrated along with the team communication pieces. I think one of the underlying components of this is like the primary tool would be that platform that stitches all those pieces together. For use cases, we see process orchestration as making a huge impact in areas around like eliminating idle time from end to end processes. And Rich will talk through one of those examples in a few minutes. Where we started to see very early on where process orchestration made a huge impact was just eliminating all the busy work associated with prechecks and postchecks, where we were seeing literally hours of maintenance windows being spent, generating outputs, reviewing the outputs, making sure that the system looked okay to make the change. And then after the change, reviewing the same outputs to make sure everything was okay. Well, there’s no need to spend hours doing that when you can spend seconds, the orchestra can do that in seconds.

Morgan Stern • 23:47

So we started seeing significant impact in terms of the process execution once folks incorporated that in. Now, those pre-checks and post-checks in the middle might be that same script they were using before. But by limiting that time means that the engineer becomes more efficient and the activities get done way, way faster. So, in terms of the opportunities, as I just was saying, for leadership, it really gives you an opportunity to reduce the execution time of any process. So not only are you doing some of these activities electronically versus manually, but because you can stitch them together in one overall process orchestration, you take out all of the idle time where it might normally be sitting in somebody’s queue to do the work. That notion of sitting in queue goes away. So the process will run as fast as it can run based on the ability that it has to connect to systems, to connect to sources of information, and to connect from there.

Morgan Stern • 24:49

So we see really dramatic, dramatic increases in efficiency in terms of the time for the process to execute. Some of our marketing would talk about days to minutes. I’ve seen processes go from three months to like an hour by stitching the process together with orchestration. You also see a pretty significant impact in improvements in accuracy because you’re taking out all of those steps that normally would have somebody manually entering data or manually reviewing data. So you see immediately better quality. You see lower activation errors. You see better end user satisfaction.

Morgan Stern • 25:28

You see less rework that needs to happen. You don’t have to back out as many things. So you see pretty significant benefits across the board by having that improvement in accuracy. And then you also see significant improvements in scale. So if you don’t need to do prechecks and postchecks for an hour and a half for every task that you’re doing, suddenly you can get a whole lot more of those done in the same amount of time, which means the system can run as fast as it needs to run, and you can start to process a whole lot more activities. Rich, do you want to talk about the benefits for practitioners? Absolutely.

Rich Martin • 26:03

I’m itching to. So number one, let’s talk about being more efficient. Network engineers, the way our engineering lines work, we want to see more performance and more efficiency. So start thinking in terms of how much more efficient you can now become individually and as an organization, as a team, when you start to expand your automation from task to now more of that process. So like Morgan just said, some of the big initial wins for network practitioners is being able to start building in pre-checks, post-checks, data gathering, ticket management. Those things right there make that process much more efficient and make your team much more efficient and you much more efficient. You want to have more trust and reliance on your system.

Rich Martin • 26:54

You don’t want to really spend that much time doing these very lengthy pre-check, post-check. you know, type processes, any kind of manual oversight, especially if it’s repetitive. It’s like when it’s repetitive, not only do we, you know, we recognize we can get really good at it. So that means it’s really good to be able to automate. Like it’s very simple because now we can kind of put that methodology down on paper as a network engineer. And so when we do those things, now we can start building automations that have our processes, our pre-checks, our post-checks, the things we would expect when we would look at them and stare and compare can now be, you know, operationalized into the automation so that when we run these things, they run and we have more trust and reliance on this versus if somebody else wrote it, right? So that’s why I love helping network engineers build these automations and expand them just because it’s their work and they recognize it and they understand it.

Rich Martin • 27:58

And now they are more free to run these automations, have confidence in them and then give them oversight so that they can look at any of those that have maybe some sort of fallout condition. That’s where I’m focusing on, not on every single CLI command, every single output, comparing it to everything that I have locked away in my brain or written down on a piece of paper or a document to compare it to. And this is very freeing and this is amazing. There’s an amazing amount of like, wow, this is awesome, you know, to being able to do this that I want network engineers to experience. Again, this doing more with less frees you up to do the fun things. And one of the things, you know, fun things can be relative. I think from a network engineering perspective,

Rich Martin • 28:40

fun things are seeing the network run, run well, and not get calls at two or three in the morning, you know, so that you can fix something that you could have preemptively fixed because we never got around to doing that years ago. And so if I have free time to fix all the things that need to be fixed in the network, not getting called at two in the morning is a lot of fun for a network engineer. But also being able to optimize the network, being able to make sure that we’re proactively managing the network and a lot of that just has to do with time. Being able to have more time in the day to do these things is a lot more freeing. It makes the network so much better. And so I think this is an easy opportunity for network engineers to understand. And maybe one that they don’t see necessarily is career opportunities.

Rich Martin • 29:30

We’ve seen in the networking world all kinds of tools that have come into existence and now, and maybe we looked at them and saw them as, well, I don’t know if I can use that. And then as we started implementing them in our work, we were like, now we can’t live without them. There’s all kinds of tools like that. We need these tools. Automation is a really big tool that’s not going anywhere. And so there are real career opportunities for folks who really want to invest into the network automation tooling, the process orchestration tooling, and the ability to speak to your peers and colleagues in different groups and different departments. And becoming a net DevOps leader, network automation subject matter expert.

Rich Martin • 30:14

And so I think there’s a lot of paths for network engineers to go. And, again, this is going to be critical in the future. These tools and this tooling and this process is not going anywhere. It’s going to be a standard. And so getting in front of that and saying, hey, this is something I really enjoy and I like doing, and bridging the gap between your network team and being their advocate with all of the other technology domains that your automations and your orchestrations need to work with, that’s a pivotal role for a networking person.

Morgan Stern • 30:44

Thank you, Rich. Let’s talk about what people need to do to make this evolution jump. Sure. For leaders, it’s really about working across teams, right? So it’s how do I build buy-in? I need to work with my group, I need to work with my peers, I need to work with my internal customers, I need to work with my internal suppliers to make sure that folks are bought in. And I think that it is a combination of a technical and cultural thing.

Morgan Stern • 31:15

To say that while, while it may be easy to describe technically what needs to happen, getting folks to be comfortable with moving towards this kind of orchestration, sometimes takes a little bit more nuance and finesse to work it. And so there’s a number of different things you can do to start small and build from there. But it really is about making sure that everybody understands the benefits and the risks of doing this, but also the fact that this is not unproven ground there are many organizations that have benefited from this. And there are many folks that can talk about the lessons that they’ve learned to make this happen. So I think that the situation is, is certainly in the in the community is certainly far enough along that people understand really how to do this and mitigate those risks and maximize the benefits. I think the other thing that you need to do is really focus on coming up with like a goal-driven strategy Those goals can be expressed in pretty quantifiable ways to say in terms of amount of work number of processes but more importantly like particularly when you’re dealing with customers being able to Accelerate things such that you can deliver way faster than the current SLA is always a great way to to obtain buy-in because that’s really what folks want and so so Focusing on the goals and the outcomes becomes that motivator to get people bought in I think another thing you need to do is make sure that you’re looking at the tools and platforms the right way and making sure that for whatever the Activity set is at hand and whatever the processes are at hand that you’re picking a tool That’s going to be optimized to be able to solve that And then that final part around implementing best practices You know, we we’ve been in this Automation and orchestration space for quite some time now and it’s been really interesting to watch how folks have learned and to watch how best practices have evolved over time and emerged and There’s clearly I think a growing Set of best practices that people can that people can benefit from so being able to Incorporate those into your strategy now that they exist is is a very helpful thing How about for practitioners, Rich, what do they need to do to evolve?

Rich Martin • 33:46

Well, I think first and foremost, when we talk about moving into more of a process orchestration, we’re inevitably going to have to learn some new skills. Amongst those is learning the concept and the realities of how APIs work and how they work in the specific set of ecosystem tools and solutions and platforms that you have that will necessarily need to be automated and orchestrated along with those great task-based automations that you’ve built. What is your ticketing system? I don’t have to tell network engineers to spend time in the ticketing system. They say spend plenty of time in the ticketing system, but spend time in the ticketing system understanding the flow and how it’s going to work. so that you can now, just the same way you’ve implemented a network process of pre-check and post-check, like you naturally understand the step-by-step of doing a pre-check and post-check. I do this, I execute this command, I look for this output, I compare it to this.

Rich Martin • 34:47

Once you’ve automated that, start taking that mental way of thinking and now start applying it to how you would automate the steps in your ticketing system, because that’s your next step that you need to evolve. I need to open a ticket, then I need to fill out these fields, then I need to maybe update some work notes with some data from over here. Those are the steps that will need to be automated in order to accomplish this orchestration that we’re talking about. So thinking about those new skills, taking it a step at a time, and really coordinating and sharing with your peers these new things that you’ve learned. Because again, participation across the team is going to be critical as well and how they understand this tooling and these automations work. So that’s one thing. Getting alignment with your team, other teams that you’ll be working with, and most importantly, your leadership.

Rich Martin • 35:40

making sure that you are in alignment with your, the business initiatives. Cause a lot of times from a network perspective, we can be a little self-centered about our world and we want to see these things automated and those are good things. And in time, you know, we will, we will get there but sometimes you need to help to focus your automation and orchestration efforts with what’s, what’s going on with the business and leadership. And there could be some, some, you know, some strategic things that need to be done first. And when you prove yourself, not only are you generating more, a greater skillset for yourself, but you’re also showing your ability to work as a team. And remember when we go to orchestration across these different systems, teamwork is, is, is an incredibly important things. These are the other stakeholders we need to tie off with and work with.

Rich Martin • 36:28

And obviously if you’re in this situation, advocate for your team, be the spokesperson for your team and be willing to work with, with your leadership and your, these other teams that you need to automate with. And then expand your use cases. Again, if you’re paying attention to the indicators that we pointed out earlier, you’re going to see where maybe the existing tooling you’re using in your task automation stage isn’t quite up to par to being able to do this automation with all these different systems. And this now really talking about process orchestration. But this also involves looking at the process and starting to think in terms of how do I now automate these things? And this is how you expand your use cases. So maybe as a network practitioner, I automate in my domain, and it’s very easy to think about, well, when this ticket comes in, this also means we need to automate in this domain so I can go over to my peer on the networking team that’s working in that domain, and we can work together, and that’s pretty straightforward.

Rich Martin • 37:29

But what about… What about the other systems, your ITSM, your databases, your notification systems, your, you know, those kinds of things, telemetry systems. Who are those people that you’re going to interact with there? You need to think about expanding your use cases beyond to encompass all of that. And now you’re starting to think in terms of process orchestration, going from task automation to process orchestration and involving these systems and necessarily these teams as well. So let’s leave you with a real life example. We’re going to build upon what we did last week.

Rich Martin • 38:06

So last week we talked about how we had a customer that was able to start to use task automation to help with their data center port turn up requests that cause significant backlog. So that’s where they started without, with very little automation, they were able to implement some task automation. This allowed them to leverage Python scripts to do some data center port turn ups. So it’s not just a single command, it’s a single command, it’s multiple commands on multiple devices in the data center. So you have your leap and spine devices and then you might have some other devices as well that need to be updated to give access. And so getting these scripts around, making those actual changes. gave them the ability to be more efficient during their maintenance windows when they were doing these.

Rich Martin • 38:54

However, when they started, they were still doing manual processes for all of the other things that bookend these changes. So some pre-check and post-check, some ticket management, notifying their teams, data gathering, script, and then of course, taking all of this information and feeding scripts and feeding tickets. When you start moving from there, that’s where you start. Yes, we can get our network changes to five minutes, but now we’re starting to think in terms of what does this end-to-end process actually look like? Now we’re saying, wow, we spent a lot of time on this particular process, doing all these manual changes, even though we’re automating the CLI, the manual pieces that bookend all of this, 35 plus minutes. Now that team is starting to think in terms of process orchestration.

Rich Martin • 39:43

What do we need to do in addition to all of the network stuff that what do we need to automate now? Now I think in terms of external systems. In this case, it was, wow, we’re spending a lot of time in service now. Not only are tickets being generated, but then sometimes we need to create new tickets. There’s always a process of documentation. I have to do things like during this process, I have to do things like, run a CLI command, show the output before I make a change, put it in the ticket so it’s documented.

Rich Martin • 40:15

Then I have to show the proposed changes that I’m going to make. Then after I make the changes, I may actually have to show the state of certain route tables or connections or things like that in the ticket. I need to make that as part of the process that I’m manually doing. This is before I even running the task automation itself that makes the changes. Then I can feed the task automation with the data I’ve gathered from Infoblox. Now I’m feeding the data, now I have to do another set of commands to update the ticket. Then if there’s an incident, something doesn’t work right, then I have to open up an incident request ticket.

Rich Martin • 40:53

This is where you get to really start to see the process unfold into a very long process that is more than just the task. But the good news is with the investment in tools, with the help from leadership, stakeholders, being able to now automate these pieces and parts. Like Morgan said earlier, you can think of these as one task at a time. One task at a time might be, let’s focus on now doing the service now piece of this orchestration because that’s probably where a lot of networking teams are spending a significant amount of time. I’ve heard it more than once and I’m pretty sure you have as well, Morgan. Service now is my second home, or we spend more time in service now than we do in our networking tools sometimes. That’s usually the easiest go-to.

Rich Martin • 41:40

They started with, how do we start to manage these service now tickets? If we can automate pulling data from a network device, can we now take that data, turn it into something that’s usable in an API call into service now so that that ticket gets automated with the right information immediately before the change, during the change, and even after the change? The answer when they accomplish that is yes, you can do that. This is why the knowledge of APIs, this is why the knowledge of having a broader view of what automation can look like when you look at orchestration. getting the right tools so that you can integrate all of these different systems. They were to start with ServiceNow, doing ticket management, big win there. Data gathering from Infoblox.

Rich Martin • 42:26

I don’t have to spend time as a network engineer going to Infoblox, doing queries from a dashboard, taking that in, doing some manipulation in a template or in a Word document or a text document. Being able to now have the automation handle the calls into Infoblox, pull that data, manipulate that and transform that data so it can be used both in a ServiceNow ticket and into a set of CLI commands that I pass to my task automation Python script that they had written earlier. That’s what they were able to do. And then even go beyond that to maybe even some slightly smaller gains, but still nonetheless very important gains because things like notifications to our teams. So how many teams should be, or I would say ought to be notified when you make a change? Well, you’ve got, they looked at and they said, well, who’s currently working on staff, especially if this is like in a 3 a.m. maintenance window? Well, there’s a Slack channel for the networking team.

Rich Martin • 43:28

Generally, there’s a Slack channel for the network ops teams. They need to be aware of what devices are under maintenance if they’re being taken down on the network. Of course, that’s on the ticket, but wouldn’t it be great if we could notify them in their Slack channel with the subset of data and maybe links into those systems so that they can be aware of what might be impacted? That’s exactly what they were able to do. Take something simple like notifications in Slack. Now I can say, I can take this orchestration, extract data from all the different sources that we need, info blocks, tickets, things like that, manipulate it in such a way so that I can update all the systems that need to be updated. And I can also now take that data and make people aware on my team of what’s going on with the information that’s relevant to them.

Rich Martin • 44:14

So they don’t have to go hunting and packing through a lot of data that is really not relevant to them or not necessary for them to know. So the network ops teams can get an update as that automation is running, that is specific to them and the data and the tooling and the system hyperlinked in Slack so that they can click on it and know what’s going on. The network engineering team can also be aware of what’s going on in greater detail so that they can not only just be aware, but if there’s some fallout condition, somebody can jump in and help. And this dramatically can help the team just by the communication, but also in trouble resolution if anything does happen on the network. And so because of being able to now take that full end-to-end process and automate that over time, going from 35 plus minutes to now six minutes, that includes the task-based automations that they were using from their Python script, augmented now with the orchestration with all of these systems and the data manipulation that was required, being able to take that, trigger the automation and just let it run. And of course, the results are pretty clear, however, you want to, you know, measure efficiency and productivity. Clearly it went up.

Rich Martin • 45:29

This always has an impact on end users, and I think network engineers need to take a step back and recognize that, and maybe leadership can help them see this, because sometimes it’s hard to see the forest from the trees when you’re deep in the middle of network land. But productivity going up is a big deal, but the impact on the end user, whether that’s internal and external, and it could be both, right? If the ticket’s coming in from an IT, you know, applications team, in my mind as a network practitioner, wow, this is another set of, you know, systems that they’re spinning up. If I can accomplish setting up the network piece of that infrastructure as quickly as everything else, that makes it so much easier and faster and less stress for them. So that’s one side of the customer equation. But then there’s maybe ultimately the end customer that’s also being supported by the use of these resources. So network teams think in terms of that, like now you’re starting to think in terms of we’re part of this bigger infrastructure team that’s supporting this entire business.

Rich Martin • 46:32

So productivity is obviously going to go up, and that’s a good thing. Delivering more consistent services, services consistently with less human error. This is a big thing too. Imagine how much data juggling we’re doing manually. Even with task automation, if I have to go to Infoblox and pull something from there, I have to input something first, then I have to extract data from that, then I have to turn it into something that may be a CLI command or a set of configurations that I need to post in the documentation, work notes for a trouble ticket, or I’m sending over to the network engineering or network operations Slack channels. Any typos or misconfigurations can have a tremendous impact. Being able to build these automations myself or with my team using our best practices and our processes we know work, now I don’t have to be involved in making those copy and paste changes, bless human error.

Rich Martin • 47:30

This is a beautiful thing. Network engineers, again, we talked about this. Now you can start to shift. I want network engineers to understand how amazing it is, to look at a maintenance window and not scratch your head and go, I hope I can get all this done in this maintenance window, but to actually sit down and go with these automations, I absolutely know we can get all this done. Now you start to shift your focus. from executing every single CLI command and overseeing every single output to now executing automations, being able to see the summary of everything that’s going on and knowing because we built these automations according to our specifications, knowing these things are working and then allowing that process to show you that it’s working, right? Because you built the process in the post-check that shows all the connections are up or we’re seeing data flow from point A to point B so that we know this works.

Rich Martin • 48:25

But now you can actually focus on anything that may go. corner case because maybe there was an error in something on the network. That’s where you start to focus. This is such a wonderful thing for network engineers that quite honestly, they probably rarely experience, is being able to go into maintenance window and say, I know we can get all this done, and now I get to focus on if there’s anything that’s out of the ordinary, that’s where I get to focus on. This is cool because this also means that all those skills that you have of knowing how to troubleshoot networks, knowing how to quickly go in and fix things, you’re still using those skills. You just don’t have to use them every single day in such a tedious way because you’ve built your automations with all of this expertise built in. This, I think, is a really, really great way for network engineers to start to see what they can get out of personally, and for the team, and for the business, out of going from task automation into this new world of process orchestration.

Morgan Stern • 49:27

So having seen on now multiple occasions, the sort of light bulb go on when people realize like, oh wow, okay, so for the 99% of things that are fine, I really don’t have to trouble myself with those. I really just focus on the fallout and I can fix these things and I can dedicate the right energy to that. And that doesn’t become an obstacle to the rest of the work continuing to happen, right? The old way of working was, hey, if I hit a problem, I stop. And since I was doing everything serially, that meant everything that was gonna happen afterwards, even if it was all smooth, might get pushed to the next maintenance window.

Rich Martin • 50:06

Yeah.

Morgan Stern • 50:07

Now all the ones that are gonna go, go, right?

Rich Martin • 50:09

And that’s a huge, huge shift. It is, tremendously.

Morgan Stern • 50:14

All right, well, so as we’re kind of winding down on this, just to kind of set the stage and talk about where we’re at, right, today we’ve really focused on this task automation to process automation. This is part of the larger maturity model where we’re working inevitably towards sort of the self-service networking, which for a lot of folks is on the horizon, but is still a really desired outcome. So, this has been part three of the network automation maturity model session. And December 6th will be on the final session where we do talk about that self-service networking. I wanted to thank you and also thank you, Rich, for being a good partner on this. Absolutely. Thank you.

Morgan Stern • 51:00

I really enjoyed this. So thanks, everybody, and we look forward to seeing you on the first session.