 Good morning. Okay, y'all got to do better than that. If I have to be up here on stage, y'all have to be awake and alive. I know that there was a lot of nightlife going on down the street away from the train station last night because I walked by and it was really seemed like fun environment. We'll try it one more time. Good morning. Much better, much better. It's great to be here with so many friends and colleagues from around the globe. This morning I'm going to continue some of the conversation that Arpit started yesterday about, you know, what's next? What do we do next? How do we move forward? And I'm going to start by talking a little bit about AT&T's network transformation and where we are on that journey, where we are on our maturity curve. You know, it all started about almost five years ago now. It seems like forever ago, but then five years seems very short time when you talk about the major shifts and transformations we've done as an industry. And for us, we started with virtualization. John Donovan challenged us to virtualizing control 75% of our target network by 2020. And I'm happy to say we are on track to do that. Along the way, you know, software control is the next step of that. You virtualize it and then you software control those virtual functions. A colleague of mine, Mike Paradise, wrote in a blog a couple of weeks ago and compared the virtualization of our network to building highways. And when you build highways, then you open them up and you put traffic on those highways. And that's what we're doing today in our software defined networking. We're putting traffic on our network. And we have currently about 75% of the traffic that goes across our MPLS tunnels, the data traffic moving across those MPLS tunnels, about 75% of that is software controlled. And we use software to do things like automatic rerouting, carrying for outages, carrying for events such as hurricanes, which we've experienced recently over in the United States. And those are things that we're extremely proud of, but we didn't stop there. White boxes was the next step on the journey. And we have white boxes deployed in our network in production in many places, one of which is our network cloud. We connect the servers to each other through white boxes. And that network cloud is where our 5G packet core rides. It's in production, live carrying traffic today. We also have white boxes at our cell sites, serving as a SIAD type of function. We also have white boxes at our customer prems connecting to our business networks. The next logical journey or step along that journey was DevOps. And we're about a year into that cultural transformation. And I say cultural transformation for a reason. And I'll talk a little bit more about that a little bit later. There at the top of the chart, you see some question marks. What does the future hold? What's next? Before I get there, I want to talk about that cultural transformation that we're undergoing within DevOps. As I said, about a year ago, July of 2018, we intentionally did an organizational change. We took our architecture, our development, our engineering, and our operations, and we moved it together into the same team. Now, just moving people to the same team isn't going to make everything work perfectly and make, all of a sudden, you have a utopia DevOps world. You have to change how you do the work. And that's what we've been doing. We've been changing how we do the work. We have developers sitting down together with operations people working on and teaching how you do software. And the operations people are teaching the developers what happens when your software doesn't work. We're partnering together like we've never done before. The key there is we have a single organizational accountability. Now, what that means is my boss and all my peers, we all share the same goals. Now, in the purest sense of the world, word, that's not DevOps. In the purest sense of the word, DevOps is a small team where you've got everybody on the same team and they go accomplish a task. And that may work in a small startup world. But in the world that's at the scale of the network that we support, that wasn't going to work for us. And so this is our hybrid approach and how we're approaching our cultural transformation, changing how we work, changing the types of things we do. Part of the reason we're changing that is because we're driving towards an outcome. We're driving towards an outcome that is declarative predictability. That's hard to say. It's even harder to do. And declarative predictability to me is a world where automation thrives and execution is as predictable as the sun rising in the east every morning. For us, our first example of where we have used this declarative type of platform is Airship. Airship is an open source project in the OpenStack Foundation that is a declarative lifecycle management and software tool. Platform, actually. It's not a tool, it's platform. You submit YAML documents to it. They're executed. The artifacts are stored. And then if you need to change them or make a change, you edit them and then you repeat the process. You have a single source of truth in that artifact that's stored in a repository. That's a key for being able to maintain automation and maintain the ability to have predictable outcomes. Predictable outcomes are generated by automation. I believe that in the world we live in today, and I have many debates with my operations peers, most of us, when we say automation today, what we're really talking about is mechanization. We're talking about mechanization that is a tool that takes a single task and it automates that task, and then you can run that task over and over again. But true automation is where you take the outcome of that automated task and you drive the next automated task. You trigger that next task and you do that across the whole system. And when you're doing that across the whole system, then you get end-to-end automation. In the telecom world, there's a saying, thinking back into the physical world of telecom, that hands in the plant generate failures. The more hands you have in the plant, the more apt you are to have failures. I would say in a software world that we live in today, that same saying could be translated to hands on the keyboard generate failures. And what I mean by that is today in the world we are living in today, we still operate our networks the same way we've operated them, the same way we've configured them, the same way we typically manage them through that CLI interface. Our operations teams want to have control and have the ability to go in and make changes and to fine-tune the networks. My challenge to us is I don't think that works in our new world. In our new world, we aren't able to live with hundreds of thousands of changes that are configuration changes driven by us driving our cloud, driving out to the edge, the 5G is going to require so many more instances, we have to get to a point of true automation because mechanization is is repeatable, but it's not scalable. One of the reasons and one of the ways we accomplish this with airship and how we went about using airship to power our network cloud is that we stepped back and we simplified. We simplified how we established what was going to be our network cloud. We eliminated way too many flavors. We had a lot of flavors of different types of applications for our internal cloud and so we took that and we consolidated it down to one. There's an effort going on right now that ARPIT talked about called CNTT. This is a similar effort where we as service providers around the globe have banded together working with our vendor partners, working with the open source and the standards community to simplify how we are defining our infrastructure, how we are creating a common network function virtualization infrastructure and it's important to be able to do that and to create a finite number of infrastructures so that as we look to scale and we look to creating a healthy ecosystem we have the ability to control what we need to do and the ability to automate it and to move forward and automate it faster. For us what we've done with DevOps has allowed us to really create savings within our organization and we've only been at it about a year. One of the big areas where we've been able to generate savings is in shifting our testing left. We've shifted our testing so that the testing that our ops teams used to do at the end of the process now is shifted left and being executed automatically through our development pipeline so that when we get to the end of the process of deploying our sites and deploying our software it's a golden run of a test set of test cases and it checks things off as opposed to finding a lot of defects and that's important for us it's important for the speed it's important to be able to reduce the cost of testing and it's important that we get these reference architectures and implementations defined by CNTT and put out there into OVP and tested and have a place where people can go test against that infrastructure early and often. Another thing that we did internally to AT&T that was part of this cultural change part of this transformation we're going through is that we started thinking about things and especially automation by design in the past there was always a time to market push and challenge I mean how many of you have ever had a senior level person or a marketing person say just just get it done for time to market we got to get this product out we'll come back and automate it well we all know that cost us more money and takes us more time and so we've made a commitment in the past year to go for that automation first to design it in by design and to start with the end in mind of automation that's allowed us to really focus and we've really come together as a team as as our pit said I've been around telecom for a long time I've never worked with a group of people together like we're doing now where we actually stopped and said we're going to shift this date out because we need to get this automation right now because it will save us in the end and everybody up the chain all across my peers and then up the chain agreed with us said it was the right decision and we actually shifted a launch date out because we wanted to do it right the first time those are the types of things that we have to think about as we're designing the infrastructures let's go back to the future I was talking about the automation talking about what the future looks like there's a movie that really has nothing to do with technology but there's a quote in it that I like and it says it's Tom Hanks in the face of a guy and he says you can't handle the truth well we need a single source of truth we need that declarative predictability but guess what we aren't ready for that we're not ready for that yet we're not ready for a world where you've got GitOps at scale but that's got to be our north star it's got to be where we're going we've got to put that out there as here's the goal we want to get to and then as we're working together across the community we've got to work together to that end and so my challenge to you today is let's drive for simplification especially in our infrastructure layer because let's face it we don't want to compete at an infrastructure layer that's not where service providers compete we should be working together to solve common problems that's what open source is all about so drive simplification collaborate on that infrastructure and automate the life cycle management so that we can get to that north star that declarative predictability thank you