Network Automation Maturity: Evolving from Process Orchestration to Self-Serve Networking

Rich Martin • 00:00

Hello, everyone. Welcome to another Itential webinar. Thanks for joining us on this last session for Network Automation Maturity where we’ve been discussing the maturity journey and we get to finally evolving from process orchestration to self-serve networking. My name is Rich Martin, Director of Technical Marketing at Itential where based off of my experience as a network practitioner, I’m going to help show the point of view from a network practitioner’s perspective as we go through this journey. And as always, I am joined by my esteemed colleague and friend Morgan Stern. Why don’t you introduce yourself, Morgan, and take it away.

Morgan Stern • 00:35

Thank you, Rich. Yeah, this is Morgan Stern, VP for Automation Strategy for Itential. And I will be focused a little bit more on perspective and insights for the IT and network leaders. So to kick things off, as Rich mentioned, where this is kind of the last in a long series where we’ve been reviewing the different components of what we’ve developed for a network automation maturity model. Early on, starting around no automation, moving through task automation, ultimately then to process orchestration, which then evolves towards self-service networking, which I think when we’ve worked with folks, as they have undertaken the journey, a lot of times the self-service piece is desired, but it seems a long way out. And what we’ve been able to do is kind of identify some of the opportunities, some of the challenges, and also some of the ways that we can help to facilitate people to get from where they are today to where they ultimately wanna be. Rich, as we’re talking through this, can you refresh everybody on things that are consistent around process orchestration?

Rich Martin • 01:47

Yeah, absolutely. Thanks, Morgan. Yeah. When we talk about process orchestration, we’re really now talking about incorporating business processes along with the network change tasks that were built in the automation task stage. Really, this is about thinking beyond just the network changes that we need to make as part of an automation, but what are the processes that bookend it? Understanding those processes and then orchestrating a workflow that can leverage all of those things together. By doing that, we’re really looking at building more efficiency in the automation and orchestration process. Typically, you’re going to leverage other platforms within this. Think in terms of your ITS systems or other northbound systems.

Rich Martin • 02:36

So ServiceNow, ticketing systems, CMDBs, as well as east-west systems. It could be things, especially from a network perspective, it could be things like your DDI, your sources of truth for IP address management, inventory systems, network telemetry, observation and monitoring systems. All of these things play a crucial part in the process. Some of them are related specifically to networking, but some of these systems are not. They’re just part of the process, like we need to open a ticket, we need to update the ticket with documentation. We need to notify other teams of what’s going on when we make a network change that’s relevant to maybe something, an application or a service that rides on top of the network infrastructure. So these are the things that we think about as common characteristics as process orchestration.

Rich Martin • 03:25

You can also exist, and the key part of this is that you’re reusing all of the automation assets that you’ve built that are specific to networking and stitching them together as a greater, you know, there’s a greater whole that needs to be automated in your network automations that you’ve built prior to the orchestration stage are critical components of that. And you may start to integrate some DevOps and CICD principles into the way you think about how we can execute automations across different processes. So with that, you’re also going to see a common set of tools and use cases. You’re definitely going to have a more mature utilization and knowledge of these network automation tools like Python and Ansible. Like I said, you’re going to have systems that are specific to those common sources of truth for networking, so DDI systems, things like that, as well as a way of identifying through ticketing and things like that, change requests and your ITSM systems are going to be there. Monitoring telemetry, always a big part of it. And then again, team communication, being able to now notify other teams, even within or outside of the networking organization, about the things that are happening in regards to these orchestrated processes that are now being automated. Your use cases are now going to look more like end-to-end processes, things like what needs to happen, what do we need to automate inside and outside of networking when we open a particular ticket for a change request or an incident, all the way to a close. And then your set of pre-checks and post-checks will probably grow and become very much more robust because now you might be looking at other systems to help you identify that services are up or other services haven’t been impacted by changes.

Rich Martin • 05:11

And the understanding that your use cases are going to be across multiple networking domains, that could include cloud, data center, SD-WAN, or any number of these things, security, or all types of network services. So, Morgan, talk to us about the demand for self-service exposure.

Morgan Stern • 05:31

Sure. There are a lot of factors that have been driving demand for folks to evolve towards self-service. I think that what happens pretty organically in an organization is as teams get more and more proficient at developing process orchestrations, that visibility then starts to permeate the rest of the organization. Folks start to recognize, hey, there are some very valuable assets here that are going to help me do my job faster, or they’re going to help us get things done much quicker at less expense. So we start to see that this functionality starts to then be really highly desirable outside the organization. And so that starts to manifest in different ways. In some cases, it’s around how can we expose this to our business partners so that we can cut out some of the time associated with the interactions that we need to do.

Morgan Stern • 06:31

So for example, the segment that I focus a lot of my energy on is around the communication service provider space. And when you look at the way that that business is organized, you’ve got some providers that are purely wireline and may specialize in doing fiber. There are others that are doing wireless. And in some cases, they are business partners of one another using components and functionality from each other’s networks. And so self-service, one of the ways that it’s manifesting is they’re exposing APIs to one another so that they can streamline the process for acquiring and managing capacity from one another. Another example of demand growing for self-service exposure is on the application side of things, where folks who are in the development organization want to bypass the old model of sending an email or creating a ticket, and really just want to be able to request the functionality that they need to be able to do their job. And we see this extending even to the internal end-user community, for example, one area that…

Morgan Stern • 07:40

We saw some tremendous benefits was when the team took the work that they had been doing to automate some of their security rules around creating access lists and creating firewall rules, and they exposed that as a self-service function. That any end-user that needed some new kinds of access or to change the permissions on the security perimeter, could make that request through an API or through a portal, and that would get expedited through the process. Now, of course, there had to be a sufficient amount of intelligence built into that orchestration flow so that it could do things like deny things that are the always deny kinds of rules and permit things that are there always permit. But what it did do was streamline the work effort such that it was really management by exception. What they were able to do there was turn what had been a two-week process into a real-time process. I also see a lot more demand just across the board around transitioning from like a people-centric process just to an API-centric process. So that regardless of whether it’s an end user, an application, a partner, an outside customer, right?

Morgan Stern • 08:55

That it becomes available to them. And one of the areas where we’re seeing a whole lot of momentum that’s been building is around starting to expose capabilities in a network as a service or as a service kind of model. So when you think in terms of self-service and exposure, there are aspects of it where it’s purely internal. You may be working with internal stakeholders or customers. There may be situations where you’re working with business partners, or there may be situations where you’re working with external customers. And in all cases, that is really kind of the, they’re all under the umbrella of self-service exposure. Now, obviously there may be some different nuances with respect to how do you charge for that service?

Morgan Stern • 09:39

How do you manage that service? What kinds of wrappers you need to put? But ultimately the mechanisms are very similar at the core of it. Okay, so let’s kind of transition, and Rich, do you want to talk about what are some of the factors that are keeping people kind of stuck in the process orchestration, but prohibiting them from really making the jump all the way to self-service?

Rich Martin • 10:04

Certainly, and I think that really ties into what you’ve talked about in the last slide. I think it’s interesting because it’s going to require, maybe one of the first things to think about is requiring, especially from a networking practitioner’s perspective, how we start to offer these things as services from a user perspective. So that’s one of the first things, because I think we’re all really used to being able to see this self-service consumption model outside of maybe our work life, right? Everything is kind of on demand and that’s really the preferred way to do it. So I think one of the first things that I would think about is networking teams really thinking through that and like changing the way that they think about how network has been traditionally sliced up and used and understood internally and being able to offer it up in the same way that we would consume other services. So I think that’s really beneficial. But from a practical perspective, some of the things that may be tethering you into the process orchestration side of this journey is the realization that you might not have all the right tools to take your automation and turn them into self-service.

Rich Martin • 11:12

And one of the things that I think is interesting is throughout every one of these steps of the journey, there’s kind of the need to look at the tooling to get us to the next piece of this, instead of just jumping in, being able to look at this now with a little more guidance and say, okay, what are the tools we need to offer and what are we using today? And what’s that gap? So that might be something to consider because self-service is exposing these things to a different type of end user, right? Maybe one that’s much less technical or has no technical background in the networking domain. Another thing is you haven’t built an easy-to-use or easy-to-access self-service catalog. So perhaps you have the tools, but maybe the process of finding it and using it is so complicated that people are like, I’d rather not do it this way. I’d rather do it another way that’s simpler. So making an assessment on, hey, if we’ve already gone down this journey a bit and it’s not working out, is it because the way we’re approaching this is still too complex for the user experience on the other side?

Rich Martin • 12:13

And again, changing the way we think, what may make sense, especially to an engineer, may not be comprehensible to this particular type of end user. One of the things that’s constantly, I think, a part of this, and we’ve talked about this going all the way back to the automation journey for the task-based automation stage is building confidence in our automation. So as networking practitioners, we are prone to being a bit cautious and careful when making network changes. So that’s why it’s so important for networking teams to be involved in this process. But now, as we’re exposing these automations to, like I said, an end-user group that may not have all the technical understanding of our domain, we’ve got to be able to have confidence that the inputs that they provide into these forums that maybe run these automations from a self-service perspective are going to be validated and ensure that that doesn’t cause any problems. So there might be a lack of confidence in your guardrail. So you want to make sure that those things, you have the ability to build those things in to test them and have that kind of great confidence in what’s going on.

Rich Martin • 13:26

I think that’s why it’s so important for the networking team to be a part of this, because they know, they have the experience, they have the knowledge, they have the understanding and the processes to build those guardrails in. It’s about the tooling and getting them involved into being able to do this so that they do have the confidence. Your current automations and services may be a bit too complex for consumption. This entails really taking a step back and looking at these automations, these services and these automations behind them and maybe simplifying them, maybe breaking them up and maybe kind of reformatting them so that they can be used in consumption. So that’s another piece that could be keeping you there. And again, this kind of ties back into confidence. If we’re going to expose this to this greater group, and ultimately the idea here is to drive up utilization when we expose this in self-service to more of the end user or business partners or other applications and platforms, we need to make sure we have very, very detailed logging and auditing and oversight into when these automations run and the output of these automations.

Rich Martin • 14:34

And not at just one layer, but at multiple layers, multiple teams that need to be involved in this. So your mechanism and your tooling has to support that as well. So that’s one of those things to think through.

Morgan Stern • 14:45

So, Rich, I was talking to a team earlier this week about this process, and one of the analogies that I used that I think made a lot of sense and kind of helped explain it was I was talking about almost like restaurant kinds of terms of saying, if you think about the process of a restaurant, they’ve got the ingredients, the chef puts the ingredients together, they list what’s available to be ordered on a menu, right? You get a check, the waiter is keeping track of what you’re using or what you’re consuming, and so at the end of the experience, you were able to discover what was available through the restaurant’s version of a catalog, which was the menu, right? The menu explained what you were going to get in sufficient detail so you could make a choice and hopefully end up getting what you wanted to get, right? They were delivered to you in a way that was easy to consume. You had a plate, you had a napkin, you had a fork and a spoon. You got a check that explained what you were paying for, right? And any one of those pieces, if it’s missing, really doesn’t translate to the restaurant experience, right?

Morgan Stern • 15:55

it translates to something but it certainly doesn’t translate to like what we’re talking about here in terms of self-service so I think when you’re thinking about that and saying okay well why do I need a catalog well the catalog is how people decide what they’re going to consume It sets an expectation for what they’re going to get. It tells them how much it’s going to cost. It provides the boundaries for what there is going to be. Just a helpful analogy there to talk about, for you to be able to graduate from being a very good process orchestrator to a provider of self-service, these are the things you need to think about. Let’s move on and talk about how do you evolve? Not what’s keeping you here, but how do you get there?

Morgan Stern • 16:40

To extend the metaphor, what are the characteristics of self-service networking? One thing that continues to be a recurring theme as we’re talking with teams and with leadership is they want to deliver a Cloud-like IT experience to their users. That there’s been a very clear expectation that’s been set by Google, by AWS, by the Azure teams around how easy it can be to consume Cloud services. That becomes the paradigm that people want to try to approximate or to equal to or to exceed. The things that are common is once I move into that service delivery mode, I’m going to have a set of capabilities, and a set of processes that I’m going to expose. Some may be complex, some may be very simple, and what you want to do, like any other good provider of capabilities is, you really want to try to meet what you think people are going to use. Now, what nice thing is, as soon as you start to expose the capability, you’ll get very clear feedback and very measurable feedback as to what are the high runner items versus what aren’t.

Morgan Stern • 17:57

But typically, what we tend to work with people around is, think what are the common chunk sizes, like bite-sized things that people are going to consume, and also recognize that it won’t always be a person or an individual that’s asking for these services. These may be services that could be triggered by a particular event condition in the network environment. They could be capabilities that are triggered by a pipeline. Using that example, the pipeline consumers may want to use a very specific function or they may want to provision a whole service. That will drive how you think about how you’re putting boundaries and how you’re dividing up the functionality into the microservices. Ultimately, what you really want to look to as your guiding principle is, how do you best support the business processes that are underpinning the activities that are driving your consumers? Clearly, it will be different if it’s an internal user versus a business partner versus a customer.

Morgan Stern • 19:03

But you really want to look and say, what’s the business process that’s ultimately driving this person to be requesting a service from me? Then what you want to do then is really wrap that around and say, how can I incorporate these activities so that I can increasingly drive value to my team and to my organization? One of the things that we’ve talked about in previous sessions was to say, once you start to automate tasks and then stitch those tasks into orchestrated processes, every time that executes, it’s adding value to the company. If you can make it easier for people to find and to request that service, you’re just adding incremental value with minimal to zero incremental cost. The more you automate something means you’ve effectively driven the execution cost down as far as you possibly can. In some cases, approximating zero. Obviously, there’s systems costs and things like that.

Morgan Stern • 20:05

But from a manual effort standpoint, you can target squeezing all the manual effort out of there, which means that you’re not constrained by people constraints, meaning availability, time, resources, scheduling, the business hours, any of those kinds of things. Suddenly, now, every time you run that process, more and more value gets generated because you’re driving execution of those other business processes without any additional cost or time. What we start also seeing as part of this, and this has picked up a lot of momentum in the past 18 months or so. Strategies like platform engineering have become more prevalent in the application development space. Folks are looking at working towards a platform engineering strategy for how they expose their network functionality. How do I create that menu? How do I make that menu easy to read and access?

Morgan Stern • 21:05

Then how do I make it so that I can incorporate that into all the other activities that the teams are doing? We see some really interesting projects that are focused around that. The tools and use cases that are typical around this, a lot of it is DevOps platforms, a lot of it is things like ITSM systems that are sitting north of the orchestration platform so that it becomes the point of entry and kind of the funnel of activities because in a lot of cases, those ITSM systems will be orchestrating a larger business process. Then ideally, they’re directing the things that are very technology-specific or network-centric down to the orchestration platform. The point of intersection, coming in as the API, but more importantly is making sure that the ITSM service catalog is consistent and up-to-date and synchronized with what you’re willing to offer. There’s a couple of different mechanisms you can use to do that. That, I think, is really the glue then that advertises the capabilities to the larger audience.

Morgan Stern • 22:21

Okay, so now that you understand the characteristics, let’s talk about what opportunities that’s this creating. One is tied in with what I was saying before, that this is really a way to maximize efficiency of how you perform the work, that when you orchestrate the process, you’re taking out a lot of the manual time. One of the pieces that folks don’t recognize until they’re kind of in the thick of it is, it’s not just about eliminating the time where people were doing stuff, but it’s also about eliminating the time where people weren’t doing stuff, meaning like any idle time, where if you send a ticket to a team and the ticket sits in the queue, all that time that ticket sits in the queue is really like zero value add. It’s just waiting to be worked. It slows you down. you’re kind of getting double whammy. Like you’ve got the cost to do the work, you’ve got the cost of waiting to get the work done.

Morgan Stern • 23:18

And what this will provide for a lot of leaders is not only have I squeezed all of the manual effort out, but I’ve also squeezed the idle timeout. Which means now you’ve got a much more predictable timeframe to be able to get what you need and to be able to support your end users. Which then we start to see a pretty rapid acceleration. Not just of the technical process, right? But also of the larger business process that is driving those folks to be asking for the service in the first place. Also see tremendous opportunity to improve customer satisfaction. That when folks know what they can request, they know how to request it, they have expectations on how long it’s gonna take to fulfill.

Morgan Stern • 24:01

Also because you’ve taken a lot of the manual effort out of this, you’ve eliminated a lot of these places where manual errors can creep into things. So people can get what they want when they want it, which is a huge boon to customer satisfaction. We had a team that we were working with a couple of years ago, where just by moving to this self-service model, they were able to significantly increase their ability to capture customers because all of their competitors were still doing it the old way. So the competitor would say, well, yeah, I can activate your service, it’s gonna take 45 days. Meanwhile, the team we’re working with said, now we can have you up and running tomorrow. That was huge impact on customer satisfaction, which ties to this next piece about saying, once I build this environment that I can offer self-service, I can start to do really interesting things that I could have never done before in terms of packaging those capabilities, whether it’s really granular things that I combine into a new service or I start to offer combined services. It gives teams who are advertising to outside customers, many new revenue opportunities, and we’re seeing this globally today, where folks are saying, I have assets that I own, I have business partners who have assets that they’re responsible for, but if I can preserve the billing relationship with the customer, and I can expose not only my capabilities, but my partner’s capabilities as an overall umbrella, I can do a lot of new things without incurring capital costs of spinning up new infrastructure.

Morgan Stern • 25:41

So, today, a lot of the things that are driving self-service in the service provider space, some combination of internal, some combination of external. In some cases, the external revenue generation capability becomes a thing that they can add into the business case, which could then defer the cost of everything, right? Covers all the pieces. Rich, can you talk about some of the opportunities that transitioning to self-serve presents for the practitioners?

Rich Martin • 26:09

Absolutely. Yeah, so for the practitioner, it may initially seem like what real benefit is there if I’ve already done network automation on the task layer, and then we’ve progressed to process orchestration, and now we’re moving towards self-service, but there really is a lot of advantage and opportunities for practitioners. For one, you’re gonna start to understand now that you’ve got this regimented and disciplined way of using automations to provide services on your network, and just the idea of changing the mental framework you’re working on and shifting to more of a self-service view of how we offer these things, network services, you’re gonna start to see that there’s gonna be a better understanding of your infrastructure and specifically how it’s being utilized and the resources that are available, or in some cases, not available. And here’s another dirty secret. Sometimes we don’t know because we don’t have this discipline and this framework and this process in place. So a lot of times we’re reactive to these things as a network practitioner. We see, uh-oh, we’re running out of this resource on this switch or this router, whether it’s memory, CPU, ports, physical ports, or whatever, we need something else and we need it quick.

Rich Martin • 27:26

So being able to now leverage these orchestration, these automations, and then ultimately self-serve and seeing this grow, seeing the resources available, it’s gonna give you a better view of the network and how it’s being utilized. And it’s actually gonna give you the time to do those things too. One of the complaints is, you know, from networking teams is, hey, we’re more than just pipes. Well, in the world that we live in today, that couldn’t be more true. We are more than just pipes, but in order for people to understand that we’re more than just pipes, we need to look at the value we bring to the larger business. And because we, when we’re at the table, when it comes to automating and going into the self, going towards self-service, you’re sitting at the table with all the other infrastructure teams. talking about how you can interact with one another and your piece of it has always been critical, but now you’re able to understand and have them, more importantly, have them, your IT leadership and your colleagues and other teams understand the value that network brings to the table and your ability to interoperate, interact with them so that we can all have this focus on self-service.

Rich Martin • 28:38

And ultimately, maybe for selfish reasons, when you elevate your value and people understand your value, this helps you to get the right tools, skills and budgets that you need so that you can continue to go in this direction. So this is a great thing. And so while we say, hey, we’re more than just pipes, we need to show that value and this is a great opportunity to do that. Even more selfishly, there’s a career growth path here. And we talked a little bit about that earlier, but now you can become like a Lego master in this sense. We’re building modular automations, we’re understanding processes. There’s a real skill in turning very complex processes and automations and orchestrations into simple and modular pieces so that they can be leveraged throughout the different processes, platforms and systems that we need to self-serve to, like Morgan was talking about a couple of slides ago.

Rich Martin • 29:33

There are CICD platforms, there are ServiceNow catalogs, there are APIs that we may expose to our partners and business partners or other organizations. All of this comes down to somebody on the networking team who can understand these processes, understand how to automate, understand the network engineering practice, and then build these things. So there’s a great growth in being kind of the network automation Lego master. And then ultimately, one of the things that we also need to understand is, as we as network practitioners engage in the ability to provide self-service to make life easier for our end users, right, and understanding that this is a mental framework we need to change, what does this need to look like for the end user I’m now providing this to? Remember, you’re also a consumer of somebody else’s self-service platforms and self-service menus, I want to say menus now because Morgan talked about the menus, but self-service catalogs. You can gain benefit from this because this is going to be an organizational change where all of your IT infrastructure colleagues are going to be pushing towards the same goal. And so this allows you to also become a consumer of their services as well.

Rich Martin • 31:01

So think in terms of like this is an entire organization where now I can request these things either from a self-service catalog or from an API to make our role in our jobs even easier as network practitioners. So, Morgan, why don’t you lead us into what to focus on for the for the success towards self-service.

Morgan Stern • 31:27

Yeah. Yeah. As I mentioned, we’ve worked with a bunch of teams on their self-service strategy, and I think we’ve seen some some pretty consistent things in terms of how they have prioritized the projects and what kinds of things that they have really looked at to be able to drive a successful outcome. I think the first one, and this goes for a lot of things, is really focus on the end user. That when we when we kind of talk about the catalog and the significance of that, I mean, the critical thing is making sure that you are framing your capabilities in a way that they’re going to want and understand. So if I’m going to a restaurant, French restaurant, and I don’t speak French, it makes it really hard for me to figure out what I want to get. Right.

Morgan Stern • 32:16

And so subsequently, you want to you want to not think in terms of what are the technical details around how I implemented this, but really, like, what do they get out of this and focus on that outcome as opposed to the mechanics of it. That’s your job is to worry about the mechanics. It’s really you want to hide that from the people just just to the extent that that they know what they need. The second thing you want to do is compare your service to the market. We worked with a team a couple of years back where they said, look, my internal end-users have choices. There’s nothing stopping them from going to Azure or going to AWS and requesting some of the same capabilities that I can provide to them. One of my design goals is to make my service

Morgan Stern • 33:06

not as good as but better experience than if they were starting to buy from the market. One of those advantages like so in terms of the consumption model, well, I’m going to present an API, I’m going to frame the service in ways that make sense, and I’m going to make it easier for them to get it from me than it would be for them to get it from a third party. Because they don’t have to give me a credit card in most cases. There may be some internal chargeback mechanisms, but you always want to make it easier for folks to use your product when they have a choice. I think the other thing to recognize is that you may see some outcomes that are a little bit different than what you would have expected. And that’s that point around recalibrating your expectations of supply and demand. In a normal world where you have physical tangible items and you have like pretty predictable supply, you kind of know what’s going to happen, right?

Morgan Stern • 34:04

When you increase supply to meet demand, you kind of hit homeostasis. If there’s any mismatch of any of those, that will change behaviors. what we have seen pretty consistently in this world is, don’t use today’s demand for your capabilities, become the baseline target that you’re designing for. What I’m saying by that is, if you get 50 requests for a firewall rule change a week, it will not be 50 once you provide self-service, it may go up dramatically. You say, well, wait a second, it’s the same customers, it’s the same business process, why would it go up? Well, what happens is, anytime people are requesting a service or a product or anything else, they’re expecting some kind of, they’re building in some kind of friction into that. I know if it takes two weeks for me to get a thing, then I’m gonna give it a fair amount of thought before I ask for it and make sure that I need it and make sure that I’m able to wait for it.

Morgan Stern • 35:08

But if I don’t have to wait two weeks, if I can get it instantaneously, there’s zero friction to do that. That means I will look for more opportunities to use that instantaneous service than I would normally. And so very consistently we see that folks, as soon as they start to become comfortable with doing the self-service consumption model, consumption goes up dramatically. And the nice thing is, as we’ve talked about, because you have taken out as much of the effort and all the other pieces, and you’ve turned this into an orchestrated process, that’s great. I mean, that means you’re delivering more value to the company at minimal incremental cost, and in some cases, no incremental cost. So it’s really fascinating to watch the demand curves shoot up, to watch as the satisfaction goes up, it drives it even more. But it’s really about saying, I need to expect that my usage will increase, but the good news is your costs don’t increase at anything even close to a linear rate.

Morgan Stern • 36:11

One of the other things that we have very consistently seen is that last point around service design. When I talk about service design, it’s really how do I frame the capabilities that I have such that it becomes another menu item on the as-a-service menu. This transition from process orchestration to self-service is about taking a set of activities that were very inwardly focused around how do I mechanize a process. That’s a very internally focused thing to say, I’m going to create a workflow, I’m going to create a script, I’m going to do this piece, I’m going to do that piece. But you’re really just thinking like how you’re going to deal with that particular problem. Now, I’ve gone from a very internally focused exercise to an externally focused exercise to say, it’s not just the workflow, it’s how do I package that workflow, how do I expose that workflow, not just so that humans can discover it, but also systems can discover it and consume it in an easy way. So you’re taking that set of activities from a very inward focus perspective now to a very outward focus perspective so that you can drive consumption.

Morgan Stern • 37:25

So, I think the key things that folks really need to focus on as they’re undertaking this evolution from process to self-service networking is to start to think about externally my stakeholders, whether it’s internal customers, external customers, business partners, what do they need to be able to get their job done? How do they think about what they’re asking for? Will give me lots of insights as to how do I want to advertise it in that catalog, in that menu. Another thing that becomes a critical decision is making sure that you’ve got a platform that’s going to be able to facilitate this evolution, right? Just as it’s a different set of tooling that you use for task automation, things like scripts, to moving towards orchestration, you need to make sure that the tooling that you’re selecting and the platforms and choices you’re making are going to give you a way to create that catalog, are going to give you a way to offer that level of exposure in whichever degrees of flexibility you need to do that. And if you do have requirements for making sure that you’re tracking usage and figuring out how I generate some chargebacks or bills for that, those are all capabilities that you’re going to need to have that you don’t necessarily think about in some of the prior steps. And then I think another critical thing for IT leaders is start to move.

Morgan Stern • 38:50

further along in the continuum around thinking about network infrastructure as code, that the same benefits that it brings when you’re moving through the other evolution phases will just only accelerate. Because moving towards that kind of a mindset really gives you the right components and the right pieces so that you can more easily snap them together. You can more easily leverage things that were already done. That adding new functionality really is just about managing code. It’s not about changing a manual process. It’s not about changing a lot of complex things. It’s really about working with tools that are gonna give you the velocity that you need.

Morgan Stern • 39:32

Rich, can you say a few words about what practitioners need to do to be able to evolve?

Rich Martin • 39:37

Yeah, absolutely. From the practitioner perspective, really continue your education in APIs and data formats. We hit upon this a little bit in the process orchestration stages, but now you really need to familiarize yourself with APIs and data formats like JSON, and not only how to utilize those APIs as they’re exposed from other platforms, but now keep in mind you’re exposing your automations, your orchestrations to other platforms. Having a super solid understanding of how APIs work, how JSON works as a way to provide data input or extract data from API calls and methods that are returned back to us, more important than ever. Also, continue to gain an understanding of a DevOps approach and the CICD strategies that their utilization. There’s a lot of value in not only understanding the approach, but like Morgan said, we’re starting to see more and more of these things and how you can fit your automations, again, publishing them as self-serve automations as part of the CICD pipeline that’s already being used. So, being able to sit at the table and expose your part of the IT infrastructure and being utilized within a CICD pipeline is critical.

Rich Martin • 41:03

And so, understanding that, if that’s a strategy that’s already going on in your organization, you need to take part of that. So, understanding that and then learning how you can integrate with that platform by exposing your automations out in a very self-serve way. and then expand your pipeline knowledge. Gain this understanding of pipelines, taking, you know, like I said, the skills that when you go into the self-service piece, there’s another skill that gets developed around understanding how to break up, you know, large modular or large complex processes into smaller bite-sized ones, perhaps, these microservices, and then understanding how they can be leveraged in other platforms. So perhaps we’re doing something in, you know, we’re providing self-service catalog for network infrastructure and service now, but if we develop the backend automation and orchestrations in such a way, we can start to leverage pieces and parts of those for CICD pipelines. And this is a skill that you can develop and evolve that is definitely gonna help you as you go down this self-service route. All right, so let’s now talk about a real life example around self-service network infrastructure.

Rich Martin • 42:24

So this particular customer started what we talk about stage three, process orchestration. So what does that mean? That means they had an automation that’s been integrated. And it’s a series really of network automations, task-based automations that have now been integrated with the other external systems like ServiceNow, the process of data gathering, which really means querying NetBox, and then being able to execute upon the network changes required in this particular automation around data center, provisioning data center network infrastructure, and then providing notifications to network teams, network operations teams, the engineering teams, and even the application teams to understand when the automation was executing as well as the different stages in between, and then ultimately the final status and then updating tickets and things like that as part of this orchestrated workflow. They were able to automate this full end-to-end process. So this is analyzing the whole process, starting with what are the network changes that need to be made on one device, on multiple devices, what are the pre-checks, post-checks. expanding that process out until they finally have the full automated end-to-end process.

Rich Martin • 43:39

And then reducing that end-to-end process down to six minutes with some manual execution. So this means somebody is going in and manually kicking off the execution, somebody is somebody on the networking team. So they have a knowledge of networking and some of the forms associated with this can ask some networking specific and networking technical questions or options, which a networking engineer would have understanding of. So, where they evolved to is now they want to take this process that they’ve created and now apply it to a self-service methodology where the end user is not a network technician, is not a network engineer, is really the end user. So, the first question is, well, who is the end user here? And in this case, this particular automation is around provisioning infrastructure for applications. So, what the question is, if our application team is the end user, how can we provide a self-service exposed automation in a ServiceNow catalog to allow them to request the underlying network pieces and parts in the data center that they would need, but they’re not technical to ask for the specific things, but how can we offer this in such a way that allows them to order these things and then we on the backend as the networking team can take that input from them, very minimal, but it’s input that they understand, and turn that into all of the data gathering and resources we need to provision all that infrastructure, so it could be VLANs, it could be VXLAN configuration, routing on multiple devices in a data center.

Rich Martin • 45:22

And so, this goes back to the menu analogy in the restaurant. instead of a menu that’s very, very technical that a network engineer can understand and fill out very quickly to run an automation, now we need to change our mindset and say, okay, this is an application owner. What are the things that they’re aware of that’s within their purview that we should ask them so that they can consume this quickly and easily? So things like, what is the application type? What is the location? Things like that, things that they would be aware of and understand as part of this ordering process, and then take those inputs and then build those into this process so that we can derive the technical pieces that would allow us to automate the provisioning of the service along with all of the other steps in the orchestration. So again, this is taking that next step and trying to understand it from a user’s perspective and the things that they’re acquainted with, speaking the language, in this case, if you don’t know French and you go to a French restaurant, makes it very hard to order, we want to speak the language of the end user here.

Rich Martin • 46:28

And so being able to frame that in a way that they can understand and consume very simply and easily. So once they were able to accomplish that, The light bulb goes off and says, you know what? Not only are we aware of, but our customers, our end users, are also aware of a slew of other network services that we would love to have access to on your menu. So now the menu grows. So they had the ability now to take the success that they had with infrastructure for application owners, provisioning basic infrastructure and say, okay, what other network services are out there that may be something that they require, or they request often that now we can do as a self-service, or maybe we have these automations and these orchestrations already ready to go. Now we can start taking the success that we had in one and reframing it in a way where we can expose that into the same self-service catalog and service now.

Rich Martin • 47:21

So things like DNS, load balancing, other network provisioning, or even security services start to become high on the list and very quickly something they can start to offer in those catalogs. While the end-to-end processes may not change because you’re still basically using the same back-end orchestration with some changes to understand the end-user’s perspective here, what you are seeing is an increased utilization because they’re able to access and order and consume these things in real time. So now you’re driving greater efficiency because there’s a greater, not just opportunity for other users, but they’re actually actively using these automations to request infrastructure. And because it’s real time, I think Morgan mentioned this earlier, the demand goes up quite a bit beyond what you have seen previously. So now you’re delivering more efficient service and, quite honestly, a more delighted customer because if I can get everything I need in minutes, that’s fantastic. And then being able, like I said, to take this experience and then build API exposure so that maybe we’re not, you know, that self-service catalogs and ServiceNow isn’t the end of it. There are other platforms and services and programs and teams that you may want to start to expose these automations to, these orchestrations to. And so being able to now provide that through an API for these other platforms is something that becomes easier and easier because the mindset is such that you’re thinking in terms of what does self-service mean, how do we offer it, both from a technical perspective, but how do we need to offer it from the end user perspective, which is the key change here.

Rich Martin • 49:18

And then the results, like I said, increased efficiency for network service delivery. And I would like to point out, that’s not in a silo. Increasing your ability to deliver these different network infrastructure services just doesn’t impact the team. That’s a great thing for the team to see the metrics, but leadership and the team should actively go out and try to understand how that also increases the productivity of IT delivery as a whole. Because network is one part of several different infrastructure groups that are required. And as they say, a chain is only as strong as its weakest link. If networking is its weakest link, only because they haven’t progressed in their ability to automate their infrastructure as quickly, then you have just, by getting to the self-service part, you have just increased the strength of that chain, so to speak, immensely.

Rich Martin • 50:16

And you should be able, as a networking team, you should be able to understand how valuable that is to the organization. And because of this, like I said earlier, as a network organization, things are going to change in your relationship with your management and your other IT colleagues insofar as they’re going to see you not as not just the plumbing anymore, but that is a critical piece of infrastructure that has all of the same capabilities for delivering quickly and efficiently as we do. And now it’s a question of, we don’t have to wait for the networking team. It’s how do we work with the networking team? And how does the networking team get to utilize the self-service assets that we publish to them? And so there’s this whole new world of working with one another, with your other IT teams and as part of the overall automation strategy that is really having an impact on the business. And then personally, for network engineers. being more productive personally. So having more time to be proactive with network optimization and being able to understand network utilization and resources so that we can be more proactive and go back and have the time to go back and optimize the network and fix all the things we wish we could have fixed.

Rich Martin • 51:37

That is a fun part of network engineering. And it’s a part that if we could do it proactively and not reactively, is not only gonna make us happier, but it’s gonna boost morale of the team and really have a significant impact on how the network as a whole works. So these are all great benefits that you can look forward to and that our customers have looked forward to as well. So take us through the final couple of slides here, Morgan, and let’s kind of recap where we’ve been in this series.

Morgan Stern • 52:11

Sure, sure. If you remember, I mean, we started way back in the first phase where folks had limited to zero automation and That has become a much smaller community than it used to be right, but a lot of folks have started the journey And have have really found themselves Getting some good benefit in the task automation space where they started to become comfortable with scripting But then realized hey I need to now start to tie these things together Maybe choose some different tools around doing end-to-end process and then ultimately to get to where we were today, which was talking about the the shift from process orchestration to self-service networking So given that as the backdrop We did want to take just a couple of minutes to kind of talk about what at Itential What we’re doing to help folks make that transition So rich do you want to talk about that that first transition jump from task automation to process on? orchestration and how I tential is helping its customers make that transition.

Rich Martin • 53:17

Certainly. This is really where the network practitioner begins the journey for them. It’s around understanding that we need to automate a lot of these network changes that are constant. Really, at this stage, it’s focused on how do we take this tremendous amount of CLI, this cookbook of CLI commands that we have to execute every single time one of these requests comes in, and how do we automate this? Then that’s what we call task automation. From Itential’s perspective, we want to meet teams exactly where they are by taking all of that work that they’ve done to automate these tasks and helping them to organize it, to share it, to search it, and to execute it along with wrapping it all up, and not only security encryption, but also to be able to audit who gets to run that and what happened when those automations run. With Itential, we use a part of our product set called Automation Gateway to help. teams that are down that route, leverage those automations in a unified way across their teams, because this is something they will have to solve for when you go from the single execution environment, like we’ve said before, to an execution environment that includes your team.

Rich Martin • 54:35

How do I share these automations? How do I secure them? How do I provide authorization, access control, and auditing? So that’s what Itential does with Automation Gateway, but then it can actually integrate and take you to the next step of process automation by taking all of those great automation scripts and playbooks and programs that you’ve created and allow you to stitch them together in the Itential Automation Platform, where you can now start to model the end-to-end process, and you can start with just the network changes, the pre-checks, the post-checks, and then add on the ServiceNow or whatever ticketing system you have. And you do this in a visual framework so that you leverage the existing work that you’ve done in task automation, and then you take advantage of the integration capabilities that we have in the platform with all of these IT systems, other networking systems, clouds, things like that, and then you can stitch together this process very quickly and continue down this automation journey. I’ll let you take us from that process automation step as well into the self-service, Morgan.

Morgan Stern • 55:45

Sure. Yeah. And so as we’ve been talking about this, the shift from process orchestration to self-service networking is really about framing things for the end users, making it easier for them to find and consume. And so with the Itential Platform, we’ve got a couple of different capabilities that kind of fall under how we do that northbound API exposure, right? We’ve got a very easy to consume API that can be wrapped around any number of orchestrations or use cases that you build through a component in the operations manager that’s focused around the catalog. And when you build a catalog item, you kind of link it to the automations and orchestrations that you created. You can define how you want to expose it, either for an event or be triggered by an API request or any way you want to expose that. But basically, the idea is to make it really easy to generate that catalog, to expose that catalog for people to be able to use. And what becomes really interesting is all of the pieces that Rich talked about, all of those components that you built before, now it’s really about taking all of those things and combining them in different ways so that it becomes easier and easier for folks to consume, all with that end goal of making it easier to find, easier to use, which drives up uptake, which drives up value, which drives up overall end-to-end success.

Morgan Stern • 57:17

With that said, we’re going to wrap things up. I hope it was pretty obvious. This is something that Rich and I really like talking about. It’s an exciting space. We’ve seen a lot of teams really embrace this evolution path and really do some very innovative things, and really radically shift how their organizations were perceived within the larger business, and became really an instrumental part of the business and mission critical efforts that were going on in their teams. So we’d like to thank you for those of you who stuck with us and listened to all these sessions. As always, we’re always happy to answer questions or have discussions with you, or we’d love to hear from you.

Morgan Stern • 58:02

give you some more examples and show you how we can we can work with you and how the Itential platform can help you in your Automation and orchestration goals. So rich. Thanks a lot. It was great to do the series with you and Hopefully next year we can we can bring some some other cool stuff to to their tour. Thank you