Speaker 1 00:00:01 Join us as we gather around the hedge, where we dig into technology, business, and culture with the finest minds in computer networking. Speaker 2 00:00:20 Hello? Tom, back with you. Did you fill your water bottle back up? Did you? Speaker 3 00:00:25 Nope. Nope, I did not. I still have, I only have like 10 or 12 ounces, so Speaker 2 00:00:29 That's only enough for 10 minutes. You're gonna have to take a break, , come back to us. I know how that works. And today we are joined by Terry Slattery and his massive number of books in the background, although he claims to have thrown a lot of books away. I don't know about that. Terry, if I believe you, , um, Speaker 4 00:00:52 The ones over there are whittled down from what it used to be. . Speaker 2 00:00:58 Terry, where are you? You're outside DC someplace, right? Still? Speaker 4 00:01:01 Yes, Annapolis, Maryland. Speaker 2 00:01:03 Okay. Speaker 4 00:01:04 And, and it's a cool rainy day here today. Speaker 2 00:01:07 Oh, wow. There you go. And we're being joined by Scott Roben, Roben Robin. I don't know how to say Speaker 5 00:01:13 It. Robe on Rob, like putting a robe on. Speaker 2 00:01:16 Oh, see, I'm so terrible at that. That's okay. And Scott is someplace other than home on a Friday night, and I feel sorry for him. Speaker 5 00:01:25 Thank you. It'll be okay. I'm, I'm, uh, I'm getting dinner out of it, so can't be that bad. Speaker 2 00:01:31 Well, I don't know. It depends on where dinner is. . That's true. . Like if it's, if like it's in a Waffle house or a little pancake place that shares a parking lot with a bad hotel, you probably aren't getting any kind of good dinner out of it. just saying Speaker 5 00:01:48 That would be a change in plans. . So Speaker 2 00:01:54 I have determined that any restaurants that share parking lots with hotels or motels, the quality of the restaurant is directly dependent on the quality of the hotel. The two go in and in. If you wouldn't stay in the hotel, don't don't eat the restaurant. Just say in . Speaker 5 00:02:09 I think that's a good rule of thump. Yep. , Speaker 3 00:02:13 Russ's, Friday Road Warrior Wisdom. We should have a, we should have a recurring, uh, you know, recording on that road Speaker 2 00:02:18 Warrior. Yeah, we Speaker 5 00:02:19 Should. It's a segment. It's a new, a new segment for the hedge. That's right. Yeah. Speaker 2 00:02:23 . So we were talking about, uh, automation on the hedge a couple of episodes ago. Uh, maybe four or five now, depending on, uh, when this gets published versus when that gets published. And Scott, Speaker 4 00:02:36 Yeah, one number, 1 93 I think was the one that instigated to us. Speaker 2 00:02:41 , yes. And I think this is 2 0 6 or something. I don't know. Things go fast here at the hedge. Um, well, it's also the end of the year, so as always, Tom and I are trying to record through the end of January as quickly as we can so that we actually get a break during, in December. And it has never worked before, right Tom? It's never, Speaker 3 00:02:59 Yeah, it's never, never. But I think this year it's going to Speaker 2 00:03:03 I'm optimistic. You think so? I don't know. You're being optimistic, are you? Yeah. Okay. Well, okay, well, we'll see. And so Terry wanted to continue the conversation, which is good. It's cool actually. Um, we like continuing conversations. So Terry, I mean, I guess we start with the original conversation was around why doesn't, why hasn't automation taken off? What's going on? That automation hasn't taken off. So some of the things we covered about were things like the vendors aren't giving us a, a consistent model and other things like this. Um, so let's go down your reasons, Terry. 'cause these are interesting. Uh, Speaker 4 00:03:44 Well, I, I started off with a bunch of, of observations about the conversation that went on in that particular episode, and then I got to looking at it and I, I did a presentation enterprise connect this early this year, and I looked back at that presentation, refreshed my memory on it. And there are actually four higher level reasons other than the ones that were discussed in that particular podcast that make automation difficult. And I, I felt like it was important to, to surface those and make sure everyone is aware of what those, those high level basically just four things. What are those four things and how can you start to work around them? Speaker 2 00:04:27 I, I like the number four by the way. I, you know, I do my entire network model on the, on the rule of four. So I like, Speaker 4 00:04:34 I like it. Not seven. Huh? Speaker 2 00:04:36 Not seven. No, I'm not a seven, dude. I'm a four. Dude. Speaker 4 00:04:39 , Speaker 2 00:04:40 You'll have to go, you'll have to go read my articles over at packet pushers to understand that little joke. But , yeah, Speaker 3 00:04:45 Seven, seven is for dip. It's not for network models. . Speaker 4 00:04:48 Now it was interesting. I'm, I was sitting here and I'm, I'm taking a class on network automation programming, uh, network academies class, just for fun. Uh, I've officially retired, so, um, I'm taking this class for fun. And one of the suggestions was to use chat GBT for things. So while I was waiting for the, the, uh, zoom session to start here, I was like, ah, what are the top four reasons organizations have difficulty adopt? What, what are the top four reasons that organizations have and difficulty in adopting network automation? And so chat, GPT came back with a list that is pretty familiar, legacy infrastructure, skill gap, cultural resistance and complexity and security concerns. So I, I thought that was pretty good. My top one is culture change. Yeah. Because culture change is very, very hard. Speaker 2 00:05:50 People are much harder to work with te with te than technology. In fact, there used to be this cartoon that I had on my wall, and I don't know if I could still find it again, but it was someone talking to their supervisor and the, the supervisor said to them, their manager or boss, whatever, and said to them, you need to learn more soft skills. And they said, soft skills. I got into computers so I wouldn't have to deal with people. . And Speaker 5 00:06:11 There you go. . Speaker 2 00:06:13 That's kind the way I feel. People Speaker 4 00:06:17 And the supervisor had pointy hair, Speaker 2 00:06:19 . Yeah. Yep, Speaker 5 00:06:20 That's right. Dilbert. Dilbert in the corner. . Speaker 2 00:06:24 Yep. Speaker 4 00:06:25 Yep. Speaker 5 00:06:27 So, so culture change is hard. Yeah. Keep going. Speaker 4 00:06:31 Yeah. So there's that. And it's just a communication between people and making sure that they're all communicating and understand what the other party is saying. So that whole thing wrapped up together is, is my top one. It was number four. It was number three out of the chat GPT. But, and, and my book, it's number one, because unless you get everybody on board, um, as Scott McNeely said many, many years ago, all the wood behind one arrowhead, if, if people aren't pulling all in the same direction, it it's not effective. It's not an effective organization. Speaker 2 00:07:09 So would you say that from experience or is this something that you're observing, just like, you know, if this is a generic, I've seen this around, or like, is this like I've actually seen this in real life? Speaker 4 00:07:21 Um, a bit of both. Speaker 2 00:07:23 Okay. Interesting. Okay. Speaker 4 00:07:28 So I, I find that the culture changes often why automation projects fail. Um, I, I personally saw a case where we, we did a bunch of automation, but the organization culturally was, oh, we have to go so fast. We have to go so fast, we can't afford to take time out to do automation and automate stuff. And so they got one data center configured and they had three other data centers that needed to be configured. . Speaker 2 00:07:57 Yeah. So, Speaker 4 00:07:58 But they were going so fast, we have to go really fast. And they got one data center done. Right. But it was one of these high availability type systems, financial systems. And it is like, uh, guys, there's a big hole here in your infrastructure. . Speaker 2 00:08:13 I, Speaker 3 00:08:14 I agree that that culture change. Yeah. That's, that's definitely the bigger one. But I don't think, I don't quite agree that everyone has to be on board. If everyone has to be on board, nothing, no initiative ever will ever succeed at all. But two people do have to be on board and some, not all, some of the individual contributors have to be on board. Speaker 4 00:08:31 Right, exactly. Enough Speaker 5 00:08:32 Of the right people. Yep. And, and you touch on this later, I don't wanna steal your thunder, but, you know, lack of commitment from the top and leadership, not just from the top, but from within multiple layers. I think that ties into this, and I think you called that out too, but your emphasis on the tyranny of the urgent in your data center example. What else are there things about network engineering culture that's, that are particular here? Yeah. Um, and I would say, you know, the pride of being ACLI jockey is, is one hallmark of the culture that we're talking about that, uh, is a factor here. I don't wanna make it sound like, you know, disproportionately the cause, but I'm interested to hear what else the rest of you think too about network engineering culture. Speaker 2 00:09:25 Yeah, I, I do think it's the pri I think it is partially the pride of being ACLI jockey. I passed that certification where I had to type into the things really, really fast. And I don't really denigrate that certification because, or whatever it is, because that's what I'm known for, is being able to get up at two o'clock in the morning and solve the problem on the CLI in five minutes or less. And I think that's, that's a definite thing that happens. Speaker 3 00:09:50 That's definitely a, a hero culture. Like one, one individual kind of saving the day and you can't build, you can't build correct automation, uh, on one person. You have to, people have to play nice with each other to build, to build real Correct. Automation hero cultural is is antithetical to automation, I think. Yeah. Speaker 4 00:10:09 Yeah. And you get the, you, you get the CLI jockey that says, I can fix this in five minutes with the CLI and it'll take me an hour if I use the automation system because I have to go check out the code, look at it, make the change, check it back in, go through, uh, a simulation and testing, oh, why do I need all this stuff? Because I'm making this simple change. Speaker 2 00:10:32 Yeah. Yeah. Speaker 4 00:10:34 And that, and that change, by the way here, another example from the past that change is I'm gonna glue two, um, MPLS domains together. Um, turns out that they were both originating default route and so part of the network became disconnected from the internet. . Speaker 2 00:10:52 Yeah. Oops. Speaker 2 00:10:54 . Yes. I think another problem of it is, is fear though too. Fear. Not just fear of losing your job, of, of working your way out of a job, which I know people have, but also fear that you're gonna lose control. Like there's, there's a level of control when you're ACLI jockey. When you're just in there messing around with the CLI, you do things, the thing happens. You can look at the output and say, that thing happened. Like, I kind of know like what happened there. When I go to automation, it's not so simple. I kind of lose, I'm like one step away from the control point any longer. And I think there's a, there's a massive amount of fear around that too. But I don't know, Terry, Scott, any of y'all seen that? Well, I, Speaker 5 00:11:38 That's a, that's a definite factor. And I think the rapid rise in the last year of Chad, GPT and AI tools is pouring some kerosene on that fire, rightly or wrongly. Um, that's another, it's a new unknown and it raises our, it raises the concern of many that here's another thing that could disrupt, disrupt this job, disrupt my career. So that plays in here too. I'm not willing to put a percentage against it, but it's a, it's a log on the fire. Speaker 2 00:12:14 Absolutely. Yeah. I, I mean I, I can see it, right? I, I don't, I've not, I don't think I've experienced it in the real world, but I can see people having that perspective or that set of problems. Um, I think Speaker 5 00:12:28 It fuels, it fuels passive aggression. I think it, what it really does is, and it, uh, increases, um, the weight of feet di uh, exponentially for foot dragging. Um, you know, that's why we probably don't hear about it. Talked about front and center very much. Speaker 2 00:12:46 Yeah, that's interesting. I'm thinking, I'm building labs right now, and I don't automate my labs because it's just easier just to throw 'em together. I'm only dealing with four or five routers, like, who really cares? Right. And I, it's the immediate feedback, right? I put something in, I test it, I don't have to work with anything else. And then I imagine that if I put this into production, what I'm working on right now, eventually, which it probably will eventually go into production someday, but it's, I'm not gonna be the person doing it. I'm not writing the automation that if you were the person writing the automation, there's a big, big, big thing saying inside of you, it's already working in the lab. Why should I go back and build automation to build what I've already built in the lab, troubleshoot it all, do all of that work when it's running, right? I think there's, I think there's something in that space as well. Um, that may be a culture change issue. Speaker 5 00:13:47 I'll throw, I'll throw one other item out on this one. Um, and, and be a little, uh, self-deprecating. Another thing that we tend to do is dive straight into the details, which I took us on, on this point. And Terry started this conversation out with, Hey, I've got four high level things that I think are, are the real reasons. So I'm, I'm willing to hand the, uh, the talking stick back to Terry for the high level items. Speaker 2 00:14:14 ? Well, no, I mean, no, but we have, we're only at 14 minutes. You're okay, . Okay. Speaker 5 00:14:20 All right. I'm not just trying to manage time, but it was an opportunity to show we love bits and bytes, right? And we, we love, most of us love seven layers. Russ, I know you like four, but, Speaker 2 00:14:32 Uh, that's too bad. That's too bad. Speaker 5 00:14:35 . People don't need these stupid protocols. Anyway, , Speaker 2 00:14:39 Uh, I, mine comes out to six anyway, so it's okay. Yeah. It's just six pairs. So, you know, so the next one you have in your area was about adopting a network automation architecture. And I think that's interesting. 'cause that goes back to what Scott was just saying about we love bits and bytes and we don't do as well with architectural level thinking. Speaker 4 00:15:01 Yeah. But if you don't have an architecture, you don't know what the plan is. You don't know when you've finished. If there's no goal, your goal is ill-defined, how do you know when you're finished? So having an architecture allows you to look at it and go, okay, so do we have all the elements here that are necessary for a good network automation architecture? Um, it's, it's pretty obvious that we need a single source of truth, but what other functions do we need? Speaker 3 00:15:32 I think it's kind of funny that single source of truth is like this huge talking point. Everyone wants to talk about it, but there's all the other things that, you know, how are, what's the southbound interface? What's, nobody's talking about that. Like what, what's this, what's that? Like all these other elements of the architecture, I find it entertaining that, um, you know, as soon as someone talks about network automation, it's like single source of truth. And it's like, no, there's , there's so much more to it. Speaker 4 00:15:54 Exactly. And, uh, I took a look around, um, because we have architectures for a whole bunch of other things. And, uh, it turns out that network to code has a pretty interesting blog that, that has an example of a network automation architecture is the first one I'd seen. Um, I wouldn't be surprised at finding that there are others out there as well. It'd be interesting to, to put together a collection of, okay, here's, here's network to code's architecture, here's somebody else's architecture. Um, how are they different? What are the strengths and weaknesses of each? That kind of analysis would be kind of interesting. I think Speaker 2 00:16:29 I've seen them inside companies. Rarely ever have I seen a network architecture, a network automation architecture outside the four walls of a company, right? They seem to always be within a company and they almost are never, always followed. And I often think that, like Tom said, single source of truth. Like honestly, to me, single source of truth is not like the end all be all of network of network automation. I think we really, we, we really overemphasize it. And I always say the single source of truth is the network. I don't know, maybe that's wrong, but like, what is the network actually doing right now? That may not be what I intend, but that's what the truth is. And so that Speaker 5 00:17:15 You have a big distributed database of self-documenting the self-documenting network behavior, right? Yeah. It's all the collection of all the configs that are deployed and in service right now. Yep. Yeah. Speaker 2 00:17:27 And so I, Speaker 5 00:17:27 I, uh, so yeah, go ahead, Tom. No, Speaker 3 00:17:30 Go ahead. No, Scott. No, Scott, you're good. Speaker 5 00:17:32 So, so Terry, this is a really interesting point in terms of, you know, it, it kind of makes a lot of sense that a company that exists to del de deliver professional services, you know, design and build networks for hire would publish an architecture like this. And doesn't that kind of harmonize with your comment, Russ, that I, you said comp, you've seen them within companies, I assume you mean network equipment vendors? Speaker 2 00:18:00 No, no, not, no. Even inside, like when I worked for LinkedIn, we, we had an architecture for a network automation. Sure. Not that it was necessarily followed in all cases. I work at Akamai, we have an architecture for network auto. Well, we have more than one, shall I say ? Sure, Speaker 5 00:18:16 Yeah. Fair, fair enough. So not just vendors hiding their secret sauce, so to speak. Yeah. But, uh, in, in all the conversations that I've had preparing for the network automation Forum event in, uh, in Denver in November, this, this class of, of company, all these pro services companies are really important. Third leg of the stool, right? Of course, you have the solution providers, like the network equipment vendors, like the automation platform providers. That's, that's one leg. Another leg of course is the customers, you know, everyone trying to, to do this in their networks. And then the, the pro services companies, you know, like network to code, like others, I won't name names 'cause I don't wanna sound gratuitous, but a lot of 'em have come and stepped up and even sponsored the conference. Um, they're a really, really important part of, of this ecosystem, and I think are the key to driving, uh, or a important key to driving network automation. Speaker 3 00:19:18 Uh, I, I was also gonna say, I think that talking about architecture is important because it'll, it, it's what allows you to be independent of, uh, networking vendors, uh, in terms of tooling. Because if you're not, if you don't have an architecture, if you don't know a higher planning to structure the application that is network automation, uh, then you don't know what to do. A vendor will come and say, here's the tool, and you'll say, here's the tool. Another vendor will come and say, here's the tool. And you'll just always be talking about tools, and you'll never be talking about what, you know, the architecture, the thing you're trying to, the actual business, uh, value that you're trying to build. Speaker 5 00:19:53 I really like, I like this in the context of, begin with, the end in mind, right? Terry, you, you said it a differently. Yep. Um, if I don't have an architecture, if I don't know what all the logical components are that I need to assemble, how do I know when I'm done? So, Speaker 4 00:20:08 And how do you know what the next critical piece is in the, in the path? It's like, okay, so I'm at a certain point and, and the, um, maturity model, what's the next element out of the architecture I should go build? There are some things that better preclude others Speaker 2 00:20:28 and I, I, I wonder sometimes that not building architectures is not, is is also a cultural issue. Again, we like to Speaker 4 00:20:37 Well, yeah, that's why I had culture as number one . Yeah. Because, Speaker 2 00:20:40 Because we don't, we don't like to abstract things. We don't like abstractions. We like details. And architectures are by their very nature abstract. And we wander around going, well, what's the point of that? Like, it's just, you're talking about whatever, whatever, who cares? We're not, you know, we don't think in terms of like, the larger picture and making it all fit a lot of times because we're just not comfortable with the abstraction levels. So, Speaker 5 00:21:06 You know, along along those lines, um, I wonder, you know, there's a lot of us who came into the field, um, before there was a lot of structure and discipline around building networks , and I don't wanna, uh, make comments about anyone's level of experience in years here. Oh, thanks. Not. I'll let each of you, each of you. Well, look, I, I came into this in the early nineties and I was a kid in a candy shop. This was awesome. And playing with routers and hubs and then switches and just figuring it out as you go there. Fun puzzle. There was so much of that. Yeah. It was, it was a, a game that started to pay really well . Um, and certain people on this call took, took pity and had mercy on, on others and hired them, um, to teach others how to do this. Um, for which I'll always be grateful, Terry. But, uh, you know, I think many of us learn this in a really unstructured environment, and that feeds right into the architecture. You know, that's a class I skipped in college. Um, let me just assign IP addresses and get this link up. There's, there's, there's a lot of it that's ingrained I think, that may not be, um, explicitly understood by a lot of us. Speaker 2 00:22:32 Yeah. There's a actually a rabbit trail here that I don't want to go down, but I just wanna say it. 'cause at some point we might want to do this and talk about this, is that it makes me wonder that we've talked about in the past, Tom and I have, and, and other folks that the people who seem to succeed and be really good at network engineering come out of customer support, electronics, things like that. Maybe that's because those people developed the internal architectural bearings and the idea of big picture stuff and the discipline around putting, uh, putting structure around networking. Because one thing about networking is, there was a, a time when I was working with a big customer and we said, they said, we want your top six escalation engineers or whatever it was to come in, I think it was four, and design a new network for us. And a friend of mine said, yeah, you'll have one person riding and four people racing, because there's a million different ways of doing everything. And unless you have the structure and the architecture, the structure of something like an architecture in your head, you're not going to succeed because there's a million different ways of doing everything. Speaker 4 00:23:41 Well, that's where I go back to the architecture side. Um, it, it's no different than determining a network architecture for your physical infrastructure. Yeah. And, and these days, virtual infra infrastructure, the cloud, how does the cloud integrate with what you have physically? Because yeah, a lot of stuff's virtual, but somewhere there has to be real hardware running this stuff. That's right. Uh, so forwarding play, there is an arch. So, so there is an architecture that you've created for how your network is designed. Why don't we apply those same principles in determining architecture for network automation and apply that to the network. Speaker 3 00:24:22 I think one of the interesting things that's happened, because designing networks is different than troubleshooting and, and deploying them. Like, they're just, they're almost entirely different skill sets in my opinion. And, uh, probably the same. Well, definitely is the same in software architecture. And so I think one of the problems that we have come into as a lot of us became very enthusiastic because we saw the promise and the possibilities of automation. Um, but it's, it's a di that being enthusiastic about it is not the same thing as having the right mindset and knowing how to, how to think in abstractions and things like that. And, you know, all the enthusiasm doesn't actually confer the skill. Um, I I, and, and it's not to say that we can't obtain it, but we have to go beyond figuring out how to do things faster and with a better playbook and with a better, uh, you know, a better template. Speaker 3 00:25:09 We have to think at the level that you're talking about, Terry, and, and we have to pull, we have to tear ourselves away from the templates and the Python scripts for a minute to, to say, how does this integrate with a business? And I think that's, I think that's where the whole industry is right now. I think some people are starting to see that we need to start thinking that way. Um, and so I, I think it'll get better, but I think our roots of kind of get it done, make it happen, I agree with everything we've been been saying so far. Yeah. Speaker 4 00:25:35 You need to step back and take a look at, at network and network automation as a system. Speaker 5 00:25:42 Yeah. The, uh, the automation, architecture is the, is the Mylar overlay on the physical architecture. You know, if I were to go way, way back before, uh, before we had layers in, uh, in CAD programs, so yeah. And, and Tom, that was an incredibly kind way to say what you said, , um, all the enthusiasm does not necessarily confer the skills. I think I, I I got that mostly right. , so, Speaker 2 00:26:09 Yeah. Yeah. So in architecture, Terry, you talk about a five phase model and automation maturity. Talk to us a little bit about, see, you have five phases. I don't know what to do with this. I mean, there's five, there's seven, there's four, there's six. Like, what are we doing here? Speaker 5 00:26:28 Keep it, keeping it prime, you know, five Speaker 4 00:26:31 Is prime. There are different models with, with different number of 'em, but the, the end goal is you can determine where your organization fits in the maturity models. And it, it's all driven by things we've done in the past, you know, software methodologies, uh, development models. And th this sort of modeling has been applied to a variety of aspects of software development, networking and stuff like that. We need to apply the same thing to network automation. Are you doing no auto, are you, are you doing manual automation at this point? You're just starting out, you're thinking about it. You, you're learning about single source of truth and, and determining, well, what would that be? Like, what, what tools do I need to make that happen? Well, you're not thinking at that point about the end goal, the end goal down the road. The number five thing might be totally autonomous operation, where an automated system is able to de discern a network failure and take appropriate action to work around that failure or identify what it's down due to that failure so that humans could then come in and, and take action. So you're not gonna make that jump from, we're just thinking about it and it's all manual to fully autonomous operation in one fell swoop. You're gonna take steps along the way. What are those steps? Speaker 3 00:28:03 So can you tell us, can you just tell us real quick, Terry, in your mo in your thinking the rep model you're referencing, what are the steps? Speaker 4 00:28:09 Well, Joel King put it together and I actually don't have it in front of me right now. . Speaker 3 00:28:14 Oh, sorry. Let Speaker 4 00:28:16 Me, let me get back to you on Got one. Speaker 5 00:28:18 I'm, you, you talk and I'll pull up the slides. Jerry, I'll, I'll Speaker 4 00:28:21 Find it yourself. . Thank you. . Speaker 3 00:28:25 I think it would be really interesting to hear the concrete, but yeah, yeah, Speaker 4 00:28:27 Yeah. So it's, it's the manual thing and then, uh, the next phase is you're doing islands of automation. So you're automating sp specific little tasks that you have. Uh, so one of the tasks that, that I was associated with at, at net Craftsman, one of the gentlemen that was working on this put together a set of scripts that went out and verified an installation at a branch, uh, an organization's branch. And they had hundreds of these branches and it allowed the engineers to better do this installation and validate that the installation was done correctly and was operating correctly. But that was not plugged into a, a higher level architecture. Um, that, that was the extent of it was just checking these branches and it was not code that you could actually reuse elsewhere within the organization for checking other stuff. You couldn't check data center stuff with it, it was specific to the branch. Speaker 4 00:29:29 Well, what you want to do is you wanna move up the, my, the maturity model to the point that you're going, oh, this model for these branches is not a whole lot different than the model for this part of my data center. A pod or a, a set of racks, a a row of, of racks, that sort of stuff. Why don't I make one set of architecture here that can be applied to both and abstract out the things that are different between one versus the other. So as you work through the maturity model, you start to identify these patterns and begin applying them. Does that make sense? Speaker 2 00:30:10 If, if you find the patterns Yes. Speaker 4 00:30:13 Yes. You do have to have the patterns. Yeah. Do you find the slide yet, Scott? Speaker 5 00:30:18 Yep. Yep. You're, you're two for two with, uh, phase one, phase two here. Speaker 4 00:30:23 So why don't you read off the rest of them? Speaker 5 00:30:26 So from, from isolated automation, we move into automation frameworks, right? And Joel sites, the, you know, source code management with peer review of processes and having a, a source of truth. He doesn't say single source of truth, but I think that's implied Speaker 4 00:30:45 And I think that's probably one of the biggest hurdles because that's where severe culture change begins to set in. Speaker 5 00:30:56 Sure. Then from that, yeah, go ahead. Speaker 3 00:31:01 I was just gonna say the, the severe culture change with the source of truth. I agree. I, I feel like I have spent in a couple of different organizations now months getting people to agree on where to put the data, uh, and then like, like unreasonable amounts of time trying to say, just put it in the same place, . Once you do, there's a lot of power and flexibility it gives you. But yeah, I, that's, that, that jives with my experience. Speaker 4 00:31:25 And so what I took out of Scott's description, there was also source code control, having the, the source of truth under code control and this whole check-in checkout process. It was like, why do I need to do that? I can just make this change in five minutes. Speaker 2 00:31:44 And that's discipline. That's largely discipline, again, around Speaker 4 00:31:47 One and that, and that goes back to the culture. Yeah, Speaker 2 00:31:50 That goes back to culture. Yeah. So there's another one after that, right Scott? 'cause we should have five. Speaker 5 00:31:56 Yeah. So we're only on step three. Step four is end-to-end automation, where you have stealth service portal where I assume requesting services, um, and CICD processes. Speaker 2 00:32:10 Okay. Speaker 4 00:32:11 Right. So, so that's where we wanna stand up a new server or a, a new application and it requires this set of servers and they need to communicate with each other and they use these particular ports for their communication. And they're located in this part of the network, the whole end-to-end automation of putting all that together so that it just works. Speaker 5 00:32:39 And then finally, the, uh, the be all and end all would be the autonomous operations space, uh, where the description is processes extend across multiple technology domains. So this is not just network automation, this is coordination and orchestration of requests for services that would organize and, uh, and instantiate services on the network with compute attached to storage, provisioning the right apps in the right places, or, or maybe the best places given, you know, application characteristics and so forth. Speaker 0 00:33:21 Exactly. Speaker 2 00:33:22 Thanks everyone for listening to this episode of The Hedge. Join us next week as we continue this fascinating conversation on automation with Terry Slager.