 It's a pleasure to be here and a great honor to be the closer after so many distinguished speakers. It's a high bar indeed. I'm going to stick close to my laptop here because this is a one-time custom presentation and I've got quite a few notes here. I don't want to miss any points. So let's start with where we've been and where we're going. The next three slides with apologies to Gene, our Phoenix project in a nutshell. What is a day in the life been? Waiting fires, waiting for go live, releases, approvals, provisioning, overload, far too much work and process. We're starting to see some light at the end of the tunnel thanks to Agile, Gene, Cloud is a big part of it, it's a new world and we're definitely not in Kansas anymore to riff a little bit on the digital transformation presentation from Forrester Excellent Work. I think this is what Dorothy would say, she would say, well, Auntie M and Uncle Henry certainly weren't growing digital wheat. Running around in the barnyard we now have the digital chicken with genomics and internet of things in the poultry barns, the bird is getting pretty smart. You've all heard of the connected car. We now have the connected cow with their own RFID tags and again the mature supply chain but in all seriousness, as we start to see these market facing digital applications of technology in terms of what the business actually needs, we can no longer have the classic nine month release cycles, the luxury of hiding out in the back office, nine month releases don't cut it and of course 10 deploys a day was only the start, now we're up to millions a year, big web properties releasing more or less continually with better uptime in years past. It goes to 11, who gets that, exactly. We've dialed up our processes to 11, didn't work, there are good reasons why it didn't work and a growing industry consensus that process is not a solution to everything, it's one of the bigger hammers we have and not everything is a nail. The iron triangle, cost, time, scope, pick any two, right? Not so much, not anymore, DevOps practitioners, researchers are finding that optimizing for speed in the right way as Gene also emphasized, benefits the other two, that lead time, to production from code commit, you can have your cake and eat it, yep, testing in production, chaos, monkeys, sounds crazy, actually makes perfect sense from a systems thinking systems theory point of view and the bigger the system is, the more likely they are to be doing these kinds of things nowadays, crazy? I'm just a con artist, right? Not really, I mean I was there, I finally got to go to the DevOps Enterprise Summit because it conflicted for two years with the fall open group meetings where I was working on IT for IT, very honored to be able to speak their last fall. DevOps has clearly crossed the chasm, you know these stories are real and they are making sense and the people who are executing and doing this are clearly inspired and excited and they just are bringing amazing results to the industry and absolutely it's in the biggest of the big. So what does it mean for IT for IT? I want to talk about three things, I want to talk about flow, I want to talk about efficiency that word efficiency and I want to talk about a body of knowledge. So let's talk about flow first and we can argue value streams, value networks, value ecosystems, you know there still is benefit to actually representing things in a sequential way, putting partial ordering on a complex domain is part of what architects do to solve problems. So IT for IT's value streams I really think they're very well done, they work, we break apart investment, we break apart development, provisioning and operations that gives us a great set of concepts that work even in the new world and they clearly remain relevant even with what we've heard today, even in the new digital world we're investing in ideas, we're developing them, we're provisioning them and we're operating and supporting them. These are fundamental concepts that do not change and in a world of continuous evolution it's nice when you can find something that's reasonably stable. So it's important that the concepts in the body of knowledge are not too fine grain I think that's been the failure of so much guidance, you get smart people in a room they get together they maybe overanalyze things a little bit, based on their experience we wind up with dozens of processes and operating models that just don't transfer very well and ultimately don't work as the overall answer to our problems. Love Bernard's presentation too, with permission I use this cycle here, cycles are another way of visualizing a problem and of course some ways we're seeing a lot more cycles and fewer linear representations but as we look at what Bernard proposed we compare it very readily to IT for IT, I think we're coming to an industry consensus here on what matters. So you invest based on business strategy, strategy to portfolio, we determine the system value proposition and intent and we iteratively meet that, that's required to deploy. We consume commodity services through requests to fulfill increasingly automated, increasingly API driven, taking provisioning latency out of the loop and that taking of infrastructure provisioning out of the loop is what has empowered agile development and fast feedback. I mean it's often struck me as odd that the people who invented computers, some of the smartest people to have walked the planet would have come up with something like waterfall, why was that? Were they just dumb when it came to process? No, the trouble was is that you were doing a lot of systems engineering back in the day, you had to know how much hardware you were going to go to the well for with the SVP signing that check. Now with Amazon it's very different and so absolutely you can iterate, you can solve problems in a much faster way because you've gotten the infrastructure engineering out of the picture. Absolutely and then finally from a dev ops point of view and dev includes dev as well as ops that then tracks over to requirement to deploy, detect to correct but detect to correct does need its own identity. It is a more predictable, somewhat process and it does have its own organizational identity in many organizations. They have not gone to completely cross functional product teams with operations engineers on the product as Gene also mentioned with companies like Google and so forth. But nevertheless tightly integrating them, not necessarily driving the org structure is what dev ops suggests. This is a little bit more technical work here. I bring in this diagram from my friend Murray Cantor who is lead quant at rational. Another aspect of the value streams is that they have different variability profiles. One of the biggest drivers of agile was the ongoing failed attempts to try to make software development in particular R2D more predictable. It never worked. But R2F and D2C in general are different. We can apply techniques like Lean Six Sigma to those value streams and key point from the get go and this is really the kind of nuance that speaks so highly of the work that people like Lars Rossen and the HP team did with Lars. Can you raise your hand here? This is really the IT for IT is so much Lars' brain child. I noticed that the actual provisioning and testing what Gene highlighted as the less variable part of the value stream, that is not in R2D so much as it is in R2F. It's kind of a nuance that you have to really focus on because R2E is the more variable stuff and R2F actually should be the more predictable stuff. And so R2F is how we get the stuff into production. Understanding these different classes of variabilities I think is one of the most important problems we have in building a new body of knowledge for the industry. IT for IT gives us some great and very functional tools for doing that. From a pragmatic point of view, those of you who are trainers, architects in the audience, those of you who are actually out working in the field with organizations, IT for IT is a great foundation for value stream mapping. It provides a logical overall structure, common definitions. We can use it as a tool for managing cues. Cues are a huge topic of discussion at Agilent Digital Management. They made an appearance in the Phoenix project. Of course, Don Reinertson has been a huge advocate of understanding cues and the problem of invisible work in progress, visualizing and making visible and elevating that work in progress so that it becomes something where you can pull an and on cord instead of just this massive invisible backlog. IT for IT gives you a basis for that discussion as well as seeing the blockages. Whoa, what did I just step on here? Once you've figured out the cues, where are they being blocked? What's preventing you from tightening your feedback loops? Because that is so much the agenda for modern product management. When you have too much work in process in the system, it slows down feedback. And then when you slow down feedback, you slow down product discovery. This is why this stuff all fits together and why it's so interdependent. We're moving away from a world of plan-build-run to one of investigate, invest, experiment, and elaborate. And the speed with which we can execute those experiments may well be our most critical success factor. So you put it all together. I've done this now in a couple places. You use IT for IT, drive the discussions. What are your major processes? This is an example of the work you can do as trainers and consultants and architects with your client teams. Where are the processes living on top and using IT for IT as a backbone? Where are your cues? How do your feedback loops actually work? Where are your hot spots? Where is the work being blocked? And if we had more time, then we could actually then drill down into some of the recommendations that are made at the functional component level. Like for example, IT for IT specifically recommends a feedback loop from problem management into defect management. So right there you start to break down some of the traditional silo boundaries between ops and dev. So I want to move on to the question of efficiency and this will touch on to some extent what Bernard was focusing on. So efficiency has been kind of a red flag word for me lately. It doesn't mean the same thing as effectiveness. I think you all know that. Sometimes the goal of efficiency is not our highest organizational value. It's still a thing now. So this is one of the slogans. Automate all the things. Well this is definitely, you know, when we're talking about automating all the things, we're not talking about R2D. You can't automate software development, the creative product discovery, but you can automate the actual testing and release of it and you need to per Fred Brooks and the other things we've learned about software. If you don't have automated testing in place, you will not scale. Absolutely correct. So we're building this automation. It's what we do in digital and IT for IT helps this answer this if I can use the word meta, a group of architects, right? I can say meta and not get things thrown at me. The DevOps is, to some extent, DevOps is answering this meta question of how do you automate the automation? What are the points where you can automate? This whole idea of if it hurts, I do it more. I do it more often. We stop the madness of the manual handcrafted once every nine months releases. We get to the point where as Mary and Tom Papendique would say, you can take one line of code, change one line of code, and move it all the way from development to production. But ultimately, if you're using a ticketing paradigm with a lot of human in the loop, you're not going to get there. So there's got to be this cultural change away from the ticketing systems. But that doesn't mean you get rid of a completely get rid of a process conception because the processes are simply becoming automated. That's what the APIs are replacing as the ticketing. In order to automate, we've got to know what we're automating. We've got to know the process. And then when you automate, people go find something else to do. So you wind up in the innovation cycle. This is not original. This is people like Simon Wardley have been using this idea for a long time. The idea is that you're always in this kind of a commoditization. Innovation, standardization, commoditization, lather, rinse, repeat. So S2P, strategy to portfolio, requirement to deploy, tend to live up here and innovate. R2F and D2C tend to live more at the bottom here. And we never get to done. And the fact is, is we've been through this cycle many times, and we can dig down through layers of evidence like archaeologists, which is where IT for IT also comes in and can be used in a practical sense. So I'm actually not sure that technology evaluation processes should completely be done away with, but certainly they need to justify their value a little better. The business value of a technology adoption process is more favorable vendor terms through economies of scale and better vendor leverage, reducing your IT staffing spend and increasing staff mobility because you have fewer technologies in the mix, actually reducing your development time, and this is a two-edged sword because obviously if developers need a new tool and they're waiting nine months to get it, that's not adding any value, but sometimes there's R&D that happens that doesn't necessarily need to happen. It's called resume padding. And then finally, you've got higher support and better security for a smaller number of products to reduce security perimeter. So Gene, those are the business arguments for why you manage the technology portfolio. Too many vendors in the mix, it's a known business problem. We're not ever going to get away from this, but it's got to be handled in a very sophisticated and nuanced way. Certainly from an IT for IT perspective, you can also use it as a basis for your system's inventory because the thing is, sure, yeah, Amazon code pipeline, but we still have our home-built DevOps pipeline, and oh yeah, we're still using Endeavor and the related build tools on the mainframe. And oh yeah, you know, we acquired a company that's using Azure, and now we've got both Amazon and Azure in the house, and we can't necessarily replatform it, so we've got to have cross-platform, cross-architecture, cross-operating model, integrated releases because we are trying to get some synergies. You know, at scale, you wind up with the whole mess. You wind up with Lean Kit, and Rec Pro, and Atlassian, and Jira, and you have to constantly drive this conversation to drive down the technical debt of, do we really need that anymore? How do you actually get rid of the tools? Well, it starts with understanding where do they live and what are they doing? And so here you've got a useful reference taxonomy for reasoning about that and thinking about it. Finally, I'm going to talk a little bit about IT for IT as the basis of a body of knowledge. Now, it itself is not a complete body of knowledge. It is systems and data primarily along with a very useful value stream architecture. I think we have huge challenges opportunities here in the industry. The major flow, sorry, the major how-to guidance at the management level I think is a bit past its sell-by date. I'm not going to name the names either. We need something a little more integrated, and as I mentioned earlier, we also need something that doesn't assume that processes are the fundamental building blocks of the operating model. So I'll tell a little bit of a story. Target management is all but done away with its project management office, and this is widely known, and they've said this at any of a number of public events. I'm not disclosing anything. Some of those laid-off project managers showed up in a mini MBA class I was teaching at the University of St. Thomas, and basically said to me, Charlie, what just happened to us? And at the same time, my dean said, Charlie, I just talked to four CIOs who are thinking about doing away with their PMOs in the Minneapolis area. So this becomes now a question for workforce. It's not just a question for, you know, this fringy stuff happening in Agile. We've got a major university system with 400,000 students a year, and some of those campuses are requiring project management. What do we do about the mid-career professional who's sitting there just been blindsided by a lay-off? I mean, the thing is, is for better or for worse, there's a press release on the record. Target said they did this as part of their transition to an Agile operating model, and I can provide you with the link to that press release if you want it. So at this point, this stuff, you know, as I said, the gene, it's the old story of the dog in the car, the dog, you know, the Agile and DevOps movements have been chasing after the car. They seem to have caught the car. So now what? What do you want to ask the dog? What's the dog going to do? Well, we're going to need new bodies of knowledge, because that's part of what we do. I mean, we've got to train the next generation, right? But I think we need to train them and look at it in terms of the fact that guidance itself is a complex system. So I'll introduce you to this quote from John Gall. I call it Gall's law. I don't know of any counter examples. He stated it pretty bluntly that a complex system is always something derived from a simple system. I don't know what his evidence for it was, but it's a widely cited quote, and I can't think of any counter examples. And I think we need a way of structuring, communicating guidance that follows that same approach. This is a diagram that Henrik Neiberg put together, used by permission, that I think illustrates this well. You know, if you are thinking in terms of planning and building and running and you're always thinking at the enterprise level, it's essentially kind of like waterfall. You walk people through the IT for IT value streams or an ITOL, it's strategy, design, transition, operate. I mean, we see these life cycle sequences everywhere, and at a certain point it just becomes this big blue wall. You know, what do you do with this? And how do you communicate it? And what do you do when you're trying to talk to somebody who really is not ready or interested in talking about things like policy management? Well, my inspiration recently, my inspiration for how I teach my class and I've been writing my recent textbook, is that it's got to be a more iterative approach. It should be more like what they call a minimum viable product or a walking skeleton. You need to figure out what the minimum viable DevOps or Agile or development or product platform is on day one. You know, day one in the garage, do you need formal project management? Do you need project process management? Probably not. And so I've been inspired by facts like Dunbar's number about how human organizations cluster. Armies have shown this over and over again. Soldier squad, platoon, battalion. There are fundamental structures that actually arise from our biology and our psychology in terms of how human beings can communicate. I think we can use this way to sustain a new body of knowledge. I'm going to have to move a little more quickly here. So as a founder, you've got a very simple operating model. You've got some sense of digital value, what you're going to offer, what your reason for being is. But once you have that, your concerns become very practical. Infrastructure and an application pipeline. And here's what it looks like in terms of IT for IT. You need source, build. You need source, build, package, config, maybe some monitoring we could argue about the specifics. In terms of IT for IT, this is really the core delivery backbone. I would, and I tell my students, don't get started in the garage. Don't go think you're going to do this later. You do this now. You don't write the first line of code until you got these things in place and they're free. You know, just stand them up. That's what I teach them how to do. Hey, at the team level, the team level is the critical level that we have to keep in mind much in a much better way in terms of our overall communication of bodies of knowledge. The team level has not been well treated. That's how I interpret the rise of agile is kind of the reassertion of the fact that the team is very possibly the highest value unit in the modern economy. In fact, it may have been the high, the, the high performance, highly collaborative team, maybe the highest value structure the human race has ever come up with. That's maybe a bold statement, but you know, I'll go with it for now. And a lot of this has been what agile's been emphasizing as we've got to get away from processes that destroy team cohesion. From an IT for IT perspective, well, product management becomes critical. You have to have a shared mental model of the product and that's some of the new things coming in here at the top, like defect and test and requirement. You start to need rudimentary workflow and rudimentary operations, but you still just have one product and you still don't have a coordination problem to solve. I was actually really interested to hear Gene talking about some of the coordination problems that arise arose at Etsy in terms of, you know, the idea that, you know, that this product would have worked great if they could have solved the coordination problem. Well, that is exactly the problem when you scale to the team of team's level. Very hard problem and you need to approach it extraordinarily cautiously. The challenge here is protecting team level delivery when you're dealing with multiple teams that may have some form of dependencies. There's ways we can minimize dependencies like versioned APIs. But ultimately, you do wind up with a coordination and dependency problem. It is an objective fact and it's a wicked problem. You need to be very wary. I'm very wary of anybody selling magic beans that solves the, you know, the team of teams problem, whether it's scrum-a-scrum, scaled agile framework. You know, it's the best you're going to get is you've got a variety of tools and practices that depending on your situation might help you. But ultimately, coordination communication, signaling, marshaling, minimize it and then also recognize when you can't minimize it and then that's what you have to solve for and that's what we need to solve for in the body of knowledge. From a systems and IT for IT point of view, you start to see the investment structures come in with things like portfolio and project management. You see increased operational capabilities where you actually can then marshal across partnering teams so that they can solve their dependencies so on and so forth. And then finally, hey, you made it to the enterprise level. I'm going to reiterate, you know, the discussion of the operating models is based on what you formalize and so people have to get some raised eyebrows that I waited until enterprise to get to security. Now, of course, you were thinking about security from day one, but now you've got a VP CSO and formalize risk and controls management. You didn't have that as a startup. Really you didn't. So the question is, is when do you formalize these things? Which I think is the essential question is we develop guidance along this new narrative structure. And you're very conscious at the enterprise level, what defines it for me is that it's the external forces that really start to define you. Your external adversaries, your external competitors, hackers, regulators, you can't rely on tactical firefighting responses and timeframes get longer. You get technology product life cycles that last decades. How do you solve for that? How do you manage it? So I think there's some very promising approaches for solving this. I'll give a huge shout out to the work Gene did with Jim DeLuccia on the DevOps Audit Defense Toolkit. Remarkable piece of work by a very credible auditor. And you can start to see how you solve for some of these enterprise scale problems within the context of these new delivery approaches. They are not just for unicorns or team-level problems. And then finally at the IT for IT level we fill in the rest of the pictures with things like the stuff we need for SIAM and multiple sourcing and service brokering and all of those kinds of complex operations that really do legitimately emerge at the enterprise scale. And I certainly would never lead with teaching people about this when I'm trying to introduce them to what a digital pipeline is. This is important stuff but it's not day one stuff. And so this is kind of the ultimately how we can communicate this in a different way. But ultimately it's a different conversation. You see what I did? We presented IT for IT itself in an iterative and incremental way rather than just this big blue wall of static blocks. So hopefully if we do that people will be less likely to dismiss it as irrelevant to their worlds and see the real value in this kind of guidance especially as we go through generational transitions here. So in conclusion it's a world of digital transformation. Cloud, DevOps. What have IT for IT? I think it's an excellent tool for promoting flow, fast feedback in the modern digital organization. Ensuring the digital pipeline remains efficient. Ultimately I hope it's the basis for a new body of knowledge for the digital management professional. So thanks again for your time. It's been a real honor and I don't know if we have time for questions or if I'm in between them and lunch.