 We have a double act from Microsoft, which is great to see. It's a joint presentation by Ryan Schmierer, who's the business architect for corporate IT at Microsoft, and Kathleen Wilson, architect at Microsoft for the data center and cloud services. In Ryan's case, he focuses on the processes methods, information and technology that form the connective tissue of Microsoft's enterprise scale internal IT operations. Over 20 years of experience in the IT industry, 13 years as a business and enterprise architect. Kathleen has spent over 21 years working in IT operations and consulting. Her current focus is on developing solutions for management and the adoption of private hybrid and public clouds, as well as DevOps. Kathleen's also the worldwide modern service management community lead at Microsoft, managing a community of over a thousand members, ensuring the service management is aligned to cloud DevOps, IoT, big data and enterprise mobility. In this session, they are going to look at the transformation taking place in the IT industry and how this is impacting both the business models of organizations and in particular, their IT functions. So please give our friends from Microsoft a warm welcome. Please come up. We're handheld today. We're handheld today. We're going to sing a little karaoke afterwards, too. Great. Thank you. The world has changed. Of the Fortune 500 that existed in 1955, 89% of them don't exist anymore. Jack Welsh said it well, in that if the rate of change inside your organization isn't keeping pace with the rate of change going on in your environment, well, the writing is on the wall. The world is now a network, a network of devices, a network of people, a network of organizations, and a network of ideas. The network is constantly changing, constantly reinventing itself in new and unanticipated ways. With that change, customers aren't just consuming your products and services anymore. They are now your brand ambassadors. Every experience they have, good or bad, is shared in real time with the entire network of their peers and people they don't even know who are listening. Information that was once locked within your IT systems, within the minds of experts, is now being made available and aggregated for decision making in more dynamic, real time ways that really change the way we think about the enterprise, the way we think about the world and the network. Security isn't just a concern for technologists anymore. It's now a concern for the entire enterprise. A security breach or event is now a boardroom consideration. As the shift occurs, entire industries will reinvent themselves. Organizations will rethink the business that they're in, how they conduct that business. This change starts with people, with individuals, with every one within your organization. At Microsoft, it's our mission to empower every individual and organization on this planet to achieve more towards their potential. I'm very proud to be a part of this organization, and part of that enables me to be here at the open group and speak with all of you and participate as we drive standards in this space. As was mentioned, my name is Ryan Schmier. My role within Microsoft is the business architect for corporate IT. We do a little IT at Microsoft, just a little. We'll get into that in a little bit. Before we talk about how we handle internal IT and some of the changes that have taken place within our corporate IT organization, I'd first like to introduce my colleague Kathleen Wilson, who is one of our key architects working with customers day in and day out in the area of cloud services, data center, and the consumption around those. She's also, as was mentioned before, the leader of our worldwide modern service management community, a group of thought leaders within Microsoft and folks who are involved across the company, helping to take some of the things that we talk about here within the open group and in other forms and drive those into our internal culture and DNA. So Kathleen? Can we just trade the clicker? Hi, yes, I'm Kathleen Wilson. I'm an architect, so my job day-to-day is to incorporate service management principles into cloud and DevOps. So that's my job. I work for some really, really smart people that connect customers up to the cloud, but I deal with the people and the process aspect of it. Right, Arrow? It is. So I'm going to share a little bit today about what I learned with my friends in Office 365. Everybody familiar with Office 365? Okay. So initially, Office 365 was the office product group, right, as we all know and love it. So we took the office product group and then we started developing something called software as a service. So I'm going to talk about the story about how we shifted from being a product group to becoming a cloud service provider and our lessons learned. So I'm probably going to say some things that will upset and infuriate some people. I welcome the challenge. I will be around all day today so you can challenge me. But there's three laws of the service provider, right? And all along, IT has been asked by the business to become a service provider. We know that hardware will fail. Humans will make mistakes and software has bugs. But how you deal with them is significant, right? Because it will differentiate you either as an IT organization or a service provider how you deal with these things. Because these things will happen. With Microsoft, as I said, I'm the worldwide community lead for the modern service management. It used to be called the ITSM community. I'm sure all of you are familiar with the MOF, Microsoft Operations Framework, right? That was our model for it. Well, when I joined my team, I had to promise them that I would never put a MOF slide in any one of my offerings. Because everybody was done with the ITSM conversation. Our ITSM story did not stick to our software products or services. And that was my job with the worldwide community lead to change that conversation from traditional IT service management. And this was what came out three years ago that I started this. And then it was part of my job, right? How do I incorporate IT service management into Microsoft Azure and Office 365? One of the things that was frustrating is that we always focus in the cloud world, the service desk plays a less significant role in the cloud. Because people, when you go to cloud services, you expect to go to a portal, you expect to consume things. Our customers or our consumers of IT right now are much more mature. Think of the Genius Bar at Apple, right? You go to the Genius Bar and they go and help you. They're not necessarily fixing your problem, but they're leading you through a service request process of how to make your experience better. Things like change management. In the past, change management was slow, controlled. At Microsoft, we had four different environments. We had like dev tests, staging, and then a prod environment. And we focused on failure monitoring, right? We just focused on things that failed. We didn't focus on service capabilities. We had a lot of IT escalations. We had customers who bet, you know, the whole deployment of their office stack on Microsoft. And, you know, we had things where they were escalating within their organization, and they were trying to get a hold of our product group who was responsible for delivering that service. We were failing miserably at that. We focused on SLAs and OLA's way too much, right? We're constantly focusing on SLAs and OLA's, but not really thinking, you know what, we should be delighting our customers. The people who consume our services really don't care. Well, you know what, the SLA states this, right? We have to stop that conversation. And then focusing on those operational best practices. Four years ago, we were working on offerings like, what do you do daily, weekly, monthly with Office 365? We spent so much time on that, then focusing on how we were going to delight our customers with our service. So what did that look like when we transformed it into what we call modern service management? Well, again, we look at online initiated support. For those of you who use Office 365, you can't call the Microsoft service desk and get help, right? What we try to do is push as much in FAQs and self-help articles out on the internet so you can consume them. We're constantly deploying at Microsoft in Office 365, more so now than we were four years ago. So we actually had to figure out how we were going to deploy it. So we actually have deployment rings. So we have VIP swap rings. And then we have small deployment rings where we, as we deploy daily, you know, we deploy to a ring, check for a pulse. Nobody's dying. We deploy to the next ring. And then we focus more on service capability monitoring. And something that you would, as an Office 365 user, you don't care that a server is down in our data center. You care whether or not you can send or receive email. You're able to open up a Word document. You share a point. So we had to change the way we monitor to monitor for service capability as opposed to component failures. We had to work on how we dealt with our customers, right? Because now our customers are brokering services for us to support for them. So we actually had to work on that triaging major incidents or any instance of what kind that we could actually get our services group who support our customers to work better with the customers IT organizations. And we realized that financial penalties will not make us a whole business, right? And focusing on the customers and delighting them. We had a couple of false starts at Office 365 and, you know, people weren't consuming it. Now it's just one of our biggest growing areas of our services business, right? Because we focused on what customers want versus how we were deploying it in our data centers. Then we look at also two instead of focusing on those operational debt best practices. Yeah, we write them down and then we automate them, right? We have to automate things. And I always liken it to is like, and it's probably not a really good analogy, but if I could give a task to my 13 year old daughter and she could do it and I wouldn't be concerned, I should have a runbook or an automation script for that, right? Because if it's risky, but she's better in IT than me, like she actually blows me away. So that's probably not a good analogy. But if I could give it to my mother, my mother's 75. If I could give my mother a task written down step by step, why didn't I create a runbook for that? And then we focus on DevOps. And again, DevOps, again, is not a framework. It's a culture. It's about being agile. It's about focusing on customer delight. So I feel that the clouds are driving our DevOps cadence. So how many people here are familiar with the Phoenix project have read that book? It's a very good book. I got mine personally signed by, I'm a big Gene Kim fan. But one of the things that we're looking at is like, and I'm sorry, I didn't get the number here for Office 365, but these are what companies are doing right now. So Amazon is actually deploying 23,000 changes a day, right? You know, look at Twitter, they're doing three a week. We look at Facebook, they do one per day, right? And their lead time is in hours. Reliability is very, very high. But then we go back and look at the traditional enterprises that are trying to be agile and adopt that. They're doing something once every nine months, right? And we change the way we deployed software at Microsoft. How many of you here are familiar with service packs? Right? You know, we have these things called update rollups and technical previews now. So we're actually shipping new features and bug fixes every four, six weeks at Microsoft to help and delight our customers. So they're not waiting six to eight months for a service pack to go out there as we're trying to do things smaller. But understanding to be able to have this type of velocity is you actually have to foster a cultural trust. And you do have to remove some of those barriers on change release management, right? So you have to trust, developers have to trust each other and operations has to love developers. One of the things too, I found when I was working with a lot of organizations when they were adopting Microsoft Azure as a cloud service, I think our IT pros are really confused out there. They actually need to slap across the side of the head. IT organizations do these developers or sort of these infrastructure people think the business is actually using the infrastructure. They were confused on who their customer was all along. So we have infrastructure folks that think that the business is actually consuming infrastructure and they're not. Infrastructure people have to realize that application developers are their customers, not the business that sells. And that they have to work and deliver infrastructure so developers can develop applications and services that the business consumes to do their business. So I think that relationship was all skewed. So what does this look like in an organization? Well, I think we have to lead with the people. So if you look at traditional two car companies, we have Ford and we have Tesla. Tesla, new and modern, they were able to be that startup automotive industry because they were able to start everything automated, right? Everything was machined. But then you look at organizations, right? And this is where we're trying to build these frameworks and standards to drag the Ford Motor Company into the world of modern, right? But you can bring in a robot to paint a car. You can bring in automation and all this stuff. But the challenge is people will not accept it because you're impacting their jobs, right? As soon as you put in that robot in to paint a car, somebody's out of a job, right? So I think you need to not necessarily focus on the processes, but you need to focus on the people first and the processes will naturally fall out. And then if you look at Tesla again, everything's fully automated. They do have multiple product lines of cars right now, but it was a challenge for organizations like Ford, like the IT organizations we are today, is actually how do we make them more modern? That was good. There we go. So I liken it to this type of quote. In traditional IT, they build their own airplanes, right? They maintain their own airplanes and they fly their own airplanes. But then we ask traditional IT to use cloud services and it's likening to you now have an airplane full of pilots, right? And the pilots are very frustrated because they can't get in the cockpit and they can't control everything. You know, we leave them, okay, you got to sit back, use the online entertainment system, have a drink, have something to eat, have a plane, but you can still deliver value to the business, right? So and again, for those pilots being, excuse me, being a cloud service provider to a bunch of pilots is also very daunting, right? So as I said, as Microsoft, we, when we're delivering cloud services like Azure to our customers is very challenging as well because we have a bunch of pilots out there. These people know as much as we do. So this is kind of the analogy. If you think about it, we're flying around a plane full of pilots. So in Office 365, when we started looking at, and these were kind of the key takeaways and there's an e-book from the developer division there, a bit about DevOps and how we actually, you know, transition from being very slow and lethargic to being more agile and adopting DevOps in Office 365. We believe now that every call to support is a bug. Whether or not it's, you know, but what we used to call operator error, right, operator error, it's still a bug, right? It wasn't intuitive. We didn't do enough training and people didn't understand. Anything we do manually in Office 365 is also considered a bug, right? We actually have to find a way that we can automate that. Our application engineering team actually owns the storage design and networking design instead of traditionally having our folks in, because we host Office 365 in Azure. Hopefully everybody knows that in the room. So they're responsible for designing the cloud architecture for the storage in Azure and how they're going to use it. All our applications and services, we need to understand the upstream and downstream effect. So one of the things we do in consulting services, we actually have consultants that go out and help customers to do service views or service maps. Anybody familiar with those, like the visualization of services and really look at risk from that point, right? We've made some acquisitions too recently, which we'll have some products that will do that automatically. We're talking at dinner about that. Monitoring is actually owned by engineering, not by the infrastructure folks, right? And again, I spent probably seven years at Microsoft working with the operations management and that and trying to explain to you is like, the mom operations manager guy is an expert on how to monitor, but the application developers are the experts on what to monitor, right? So again, you don't release any new features without monitoring as part of the code base. So when we ship these packs and stuff out to Office 365, we've already done the telemetry and instrumentation for monitoring. Major incidents are, we try to view them in a positive light as an opportunity to learn. Understanding that change is reality, that we don't have to control everything, that we embrace change as long as it's, you know, we're notified and we actually know how to do with that. Back in the day is like, when we're doing smaller changes, we're only doing like small little burns, but back in the day when we're doing big releases, it was more like a big smoking crater when it failed, right? So now it's like you can actually look at, hey, I'm only have a small bushfire here. It's not too bad. Am I going to roll back or am I going to roll forward? Am I going to let the burn and, you know, continue with the burn and then develop another patch or update or release and put it on top of that in a roll forward situation? Things about monitoring. So these are some of the core things that we learned with, you know, doing things at a cloud scale is that if you don't know how the services impact it, you can't delight your customers. And monitoring is how we do business. It's not an after fact. It's how we do business. And by only looking at failure mode, like component failure mode, you're not going to delight your customers. As I said, I liken it to also for when we try to explain it to customers, it's like we're familiar with ATMs, right? Customers don't care if the ATM is on or off, right? You need to monitor, can people do a balance update? Can people actually extract cash? Can they deposit a check? Those are the types of things when you change your thought about looking at service capability monitoring versus component monitoring. And then people recognizing patterns at the service desk is not the best way of doing things in a modern world. I'm thinking about machine learning and automating problem management in the future. I'm hopefully in six to nine months going to build an offering around that. That's my dream. I keep pushing the product group to make that capability, but you think about it. I've now collected all my monitoring logs. I'm storing them in the cloud. I'm going to use Azure machine learning to actually identify problems and possibly in the future tell me what I'm going to have a failure. That's cool. That's modern service management. It doesn't exist now, but I'm going to make it happen, hopefully. I'm going to use some of the stuff that Ryan gives me and I'm going to do it. Major incidents, failures will happen. Again, as you said, as a service provider, how you respond is critical. You need to have triggers for major incidents, and we were talking at breakfast this morning a little bit about that. It's like I'd like to see when you have that big smoking crater that it's automated. You ought to know you have a major incident versus waiting for 100 calls to come in and think, oh my God, something's wrong. We did have some failures in the early days of Office 365 and Azure, and we actually had to go back to the drawing board and rethink how we were doing monitoring. Because you start rolling out to all your deployment rings, and then you start seeing failures. It's like, how do you roll back or roll forward? Look at data that you mine from the major instance review process as a goal mine of how you can actually improve, and everybody should improve a major incident process. We found out that was the biggest challenge with customers were using Office 365 is that when things broke, if their major instance management process wasn't really good and they didn't know who to contact at Microsoft, the customer satisfaction, because we shipped out a survey to them, it went down. So we spent a lot of time with our technical account managers at Microsoft to tell if at the service desk, if it's broken, this is who you contact at Microsoft. Change and release. Again, when you're in a rapid modern world and you're deploying 23,000 changes per day, you need to maintain some risk and security, but you need to think about how you're going to deploy out. It's more of a wave as opposed to a big bang approach when you're releasing changes. Tooling, again, all workloads should consume one platform and communication should be outbound, right? So the idea is that how are you going to monitor everything and manage it on your bus? And how are you going to communicate these incidents, alerts outward bound to the service desk or the product group who actually manages the service? We have zero standing access in our Office 365 and Azure data centers. So we have to actually have everything automated and deployment so people can't physically walk into data centers. And the way to think about it now is that in the past we used to follow scripts as humans to do tasks. With automation now humans are the backstop to that automation. So if automation fails, that's when we pull in humans to fix it. Think about patch deployment. We automatically deploy patches and then we use humans to backstop if there's an error. How many people here are using Windows 10? Yeah, I am. You're using some other version of Windows 10.2. Yeah, we don't even call it dog food. I don't even know what you're using. I looked at his desktop and I was like, oh, he's got a newer version of me. But the idea is that when we were initially doing that we were constantly getting things pushed down to us, right? And things would fail. Again, if you were on a very important project at Microsoft they have a website at MSIT where you can remove yourself from the push deployment. But we're much better now. We're much better now. It was ugly about six months ago. It was pretty scary. Major service reviews. Now that you're not managing your exchange and office infrastructure, maybe you should have people do like monthly service reviews on the services that they provide. So thinking about that, we talk about it a lot in our frameworks about we're going to do a service review but nobody actually really does it. So think about in those discussion focusing on metrics that are always red, not green. Stop showing on your scorecards to your management green metrics because it's like boring. It's always green. Obviously you haven't set the bar to some reasonable level. But if it's always green, why report on it? You should be focusing on things red and changing red to green. Another thing working with customers that drives me until it's like we come out with all these action items but nobody takes them. There's no end date for it, right? So the idea with a monthly service review is you draw and doing it monthly, there's not that many actions that should carry over more than one month. And if your service is important, you should have a major service review. So I'm just going to be wrapping up this section and then Ryan's going to actually integrate the IT for IT story. Understanding that IT is more of a commodity versus being so special like this group is so special, you're so special. The idea is that we really worked on moving to standards. So a lot of customers when we did private cloud deployments and like only have three sizes of VM compute, small, medium and large. It's very easy to automate and do the script deployment from portal on that. And if something falls out of small, medium, large, then you can change it and say okay, that's a one oven, you can do it. But if you go to anybody for infrastructure or developer, they're going to throw as many cores at it and they're going to throw so much RAM at it, they'll just take it. It's like they hoard. And we started finding out like customers when we started moving them to Azure too is that they would pick up that virtual machine and now they're paying for it at a bill rate in Azure. And they're still at 3% utilization. So Ruthless standardization leads to better opportunities for automation. So you need to be ruthless. Look at constantly trying to iterate and improve focus on how your customers are consuming your product and drive that consumption. And there's no such thing as an end state. These reference architectures are to help you on the journey. It's not a destination. The final thing is like treat your infrastructure like cattle, stop treating them like pets. So that's the way you have to think about it. But we had a big challenge in MSIT about that. People want to hug their server. I don't want to let it go, I love it. I'm going to call it George. But the idea is it's just a server. Put it in a data center. So if I can sum it all up in two points is that IT today needs to think about becoming a manager and a broker and an integrator of services, not necessarily knowing that they're going to be able to control everything and be okay with it. You know what I mean is you can't control everything. And IT needs to focus more on delivering business value and not the technology to do to actually deliver that business value. That conversation is old and kind of understand what business is your customer. And this is where the software as the service providers are actually going to gain a lot of momentum over the next five years. And my quote is that cloud is going to make the traditional role of the IT pro obsolete in five years. In five years time now, those people who rack servers and watch the blinking lights will be out of the job. But if they don't learn to manage higher up the stack and deliver better value, well, as I said, it happened at MS IT. We're moving what 93% of our compute will go into Microsoft Azure. We just said that 7% will remain on premise and that's just for competitive advantage. And Ryan can probably tell you what's going to stay on premise, but 93% of our cloud of our compute right now will be in Microsoft Azure as we migrate it over. So thank you. I'll pass it over to you, Ryan. Thanks, Kathleen. Well, you promised that you might shake some people up here saying that within five years most of the traditional IT pros will be obsolete. Well, that's one way to do it. Let's talk about that a little bit more. For years, we've been talking about technology trends and what's coming, the promise of cloud, what that's going to mean. The productivity promise of social, social media, social networking. Big data, analytics, the things that we're going to be able to do someday, the impact of mobile and location aware devices and the threats from a security perspective that that brings. Those trends are no longer of the future, they're of today. We talk about the millennials, folks that don't have as much gray hair as I'm starting to get and some of the folks in this room. The latest stats I read showed that the millennial generation will make up over 50% of the worldwide workforce by the year 2020. Now that may be off by a couple of years, but that's not very far away. That's four years from now. As we think about the impact of this generation, it's not about assimilating them into the ways that we do things today. Getting them on board with the way we do IT. They're wired to think differently. They're not constrained by the way things have always been done. We cannot underestimate the disruption and opportunity that the workforce of the future will bring to our industry. Now you wouldn't bring an architect up here if you didn't expect some sort of a picture or a drawing. But let me kind of paint the picture, draw the sketch about the next few years. Let's draw this a few years into the future. What is our environment going to look like in about five years? Focus on the left-hand side of the slide. This is what we're looking at. Your infrastructure is most likely going to be run by cloud service providers. Your networks are going to be operated by your cable company, your cell phone company, the telecoms. Business users are going to go out to third-party SaaS providers to get the features and capabilities they need to support their job tests. If we're not running the infrastructure, if we're not operating the network, if we're not developing the line of business applications, what is the role of corporate IT in the future? Are we destined to be irrelevant? I don't know about you, but I don't really like that idea. If we don't want to be there, where do we want to be? What is the role that we would like the IT function to play in the future? The role of a business enabler, really understanding the value that technology brings to the enterprise, being that broker of services, most of which are bought or licensed or subscribed to from third parties, a few of which are still built in-house, the steward of enterprise data. Remember, IT stands for information and technology. For too long, we've been focused on the technology side of it. As we move forward, the information part of IT is going to become more and more critical to the core value proposition that we bring to the enterprise. And then providing that assurance of security and resiliency that the organizations depend on to keep the lights on and stay out of the headline news. But if we're going to get there, it's not going to happen just by showing up every day. We have to change. We have to rethink the skills of our workforce, the culture of our organizations, how we reward success, what we value, how we interact with each other. The methods we use to get work done day to day and the systems we use to manage that. We can get there. It's going to require some change. Over the next few slides, I'm going to talk about some of the journey that Microsoft IT has been on over the last couple of years as we've started down this path. We've learned some things, as Kathleen shared. We learned some things the hard way that we recommend you never do. So what is the role of Microsoft IT? Microsoft IT is rooted in the concept that you have one foot firmly planted in the presence and one foot stepping towards the future. Creating the environment of the future, yet delivering on the necessities of today. Within Microsoft, we're slightly different than some of your organizations because we're an IT company. We play a dual role. We play the traditional role of powering the enterprise transformation, providing the capabilities to support the enterprise. But we're also structured to model the IT organization of any large Fortune 500 company. We're modeled to be the first and best customer of Microsoft's products. What does that mean? It means we go through the hard times trying out new ideas, new products, new ways of deploying things. To identify what needs to change, what needs to be fixed to make it right so that we can enable your experience to be better. Sometimes that's tough, sometimes it's a lot of fun. But in that role as first and best customer, we also have an obligation to work with those product teams to help them understand what capabilities all of you are going to need over the next few years so we can help get you there. I always love these slides when Mary Jarrett from Shell shared theirs last year, or three months ago, seems like forever ago. I always like looking at the scale of different organizations. Microsoft IT, we support 110,000 employees plus a whole lot more vendors, contractors, etc. Over 880 physical locations around the globe. Over 2,000 managed line of business apps. Over a million devices that are connected to our corporate network and that number is growing exponentially every year. Some things break. Kathleen talked about that. Software has bugs. People make mistakes. Machines break. Over 1.2 million help desk tickets every year to help enable individuals within the company to continue to be productive. The slide got cut off a little bit in terms of the key stats in terms of the cloud. Kathleen mentioned our goal is to get to about 93% cloud adoption for our line of business apps. We're only about a third of the way there. We're not there yet either. We're learning things. Some of these are really difficult. But we're helping to figure out what those difficulties are so when you encounter that in your organizations hopefully we can help. Office 365, Skype for Business. Can't see it in there but Skype for Business. Over 130 million instant messages over our Skype for Business service internally every month. Over 270,000 SharePoint sites. Content managed in the cloud. Most IT organizations are of this scale or something similar. As we look at the transformation the next few slides are going to look like this. I'm going to step through some of the details. I mentioned in the drawing slide that there are some things that needed to change in order to help us get to where we want to be. First thing that needs to change is how we define success. In the past traditionally we've looked at things like availability. Is the service available? Are the lights blinking? Did we deliver that IT project on time? In the IT organization of the future it doesn't matter whether the component is available. It matters whether the person who needs to use the system or use the service can get their job done. It's not about the project or the platform we delivered but about the business outcome that we enabled as a result of that delivery. And it's not about the quantity of data we're managing but how we're using that to drive impact within the organization. Talk about the people. This is where most of my passion lies. The heart of any organization is the people that come together to work together to get the job done. If you look at some of the traditional skills around data center management, solution management, building line of business applications, testing things. Those roles are waning in terms of the impact and necessity. They're being replaced with new skills. Here's where we talk about the retooling of the workforce. Giving them a new skill set to match the IT needs of the future around bringing your own device. Constantly new devices coming onto the network. How do we manage those? It's not about building applications but becoming process engineers. Working with business functions to help them understand what their technology options are and how they can use their information for driving decision making. It's not just about analyzing the data and looking and totaling up columns. It's about looking at all the different types of information that we have available and figuring out how to aggregate it in the most meaningful way for driving decision making. It's not just about the skill set though. It's about the mindset as well. In the past we've talked about IT metrics. Is this up? Is this down? Is this scorecard metric green? IT is a support function within most enterprises. What really matters is how you're impacting the business functions that are the core of what your enterprise is there for. IT has been very risk averse in the past. You've got to manage change. We can't allow that to happen. We've been the security guard standing at the door saying you can't bring that in here. Instead we need to embrace change. Experiment, fail quickly, learn from it, move on. Moving from a fixed mindset you must do it this way to a learning mindset that says we've done it this way in the past but is there a better way to do it? Then there's a whole not invented here problem. For most organizations IT is not a strategic differentiator to their business success. There are a lot of things that we do that we need to drive efficiencies and make it as simple as possible. And we need to look around at our peers in the industry and see what we can learn from them. Just because something wasn't invented within your organization doesn't mean that someone else doesn't understand what your challenges are. We need to look outside in for innovation, figure out how to bring that into an organization in a controlled way that doesn't expose us to too much risk. We've made a lot of changes over the last couple of years in terms of how we do our work, our methods, our ways of working. The most important one is the shift from waterfall methods to agile methods in terms of delivery. Kathleen talked a little bit about legacy waterfall IT projects. If something goes wrong you end up with this big smoking crater that you have to deal with. In an agile world you have the ability to not queue up that risk but distribute it out over time and manage it as it happens and mitigate the impact. You also have the ability to adapt more quickly to changes in the environment and in requirements. And in the networked world that we now live in, adapting to the environment is critical. In the area of help desk, as was mentioned before, in the traditional IT service management the help desk is the core of the support function. Everything comes through the help desk. You talk to a person, that person will help you. As we move to a world where there are more and more third party components in your infrastructure, and the things that you develop are used by people that you may not even know outside of your organization, you need to look at unifying that support model. It's not a single centralized help desk. It's a unified support model that crosses both your supplier and your customer ecosystem. Oh yeah, and the systems. We like talking about those. In the past, every job role has had their own systems to support getting the job done. Architects, we've got our systems. We love them. The planners have their systems. The engineers and testers have their own systems. The folks doing support and operations management have their own systems and ways of working. As we move forward, it's no longer about that functionally siloed set of capabilities, but it's about evolving into an integrated IT management system for running the entire IT value chain. I promise I bring IT for IT back in here. Now we're getting to that part. As we describe this integrated IT management system, the marks of success here are the consistent end-to-end user experience. As job roles simplify, as we take on DevOps, the same person is going to be performing many of these roles. Having that consistent experience will make people more effective and efficient in their jobs. Integrated operational data to drive decision-making. It's all about making the value stream more efficient and enabling us to make better decisions out of the data that gets created. And then the seamless integration with third parties, both your suppliers and your customers. So we've been at this for a couple of years going through this transformation. We've learned a few things. The first thing we learned is the change starts with people, and when you're talking people, it's hard. It's the most difficult part of what we're doing. The expectation of how IT operates has shifted. The functional capabilities in silos really do need to be integrated into end-to-end experiences and processes. Just like we're doing for our business, we need to do it for ourselves. The whole concept of ERP for IT that Charlie and others have been talking about for a number of years now. The time is ready now for it. The evolution to services, becoming a service broker. Don't put lipstick on the pig. This isn't about changing the column heading in your application portfolio and renaming them as services. They really are different. We can talk a little bit more this afternoon about what that's all about. As we embrace more third-party components in our ecosystem, the experiences that are created get more fragmented. When we had one team developing a set of systems, we could apply things like design and user interface standards. What happens when the system from supplier X has this concept of user roles and supplier Y has a different concept? Suddenly you have this fragmentation in the user experience. Assurance of things like security, resiliency and performance get more difficult. Then when we think about things like architecture standards, it's not about being rigid. They're taking on a new meaning about how architecture needs to become an enabler of the changes that need to take place within the organization. Then as we think about big data, we need to remember it's an IT scenario too. Within all of our operational processes, we create a wealth of information about how not only the IT organization is running, but how the business itself is operating. We need to learn to harness this information, aggregate it and mine it for decision-making purposes to drive those higher-level insights that can generate value for the organization. As we look ahead, the IT for IT standard, a lot of amazing work that's happened from the folks in this room and those who couldn't be here today, we haven't figured everything out yet. As we fix things, as we make some things better, some things are going to break. As we embrace more third-party components, as service providers become more specialized, particularly in the application and SaaS space, as organizations and every organization becomes a software company as we see the digitization of business take place, we're finding new problems. We talked about the fragmentation of user experiences and how do we scale those? How do we coordinate amongst our supplier network? I mentioned the importance of data. At the point that you're not managing the physical infrastructure and you're leveraging third-party software components, information and data becomes the core strategic asset of your enterprise. We need to learn what it means to own this, what it means to integrate it across systems, and some of the portability concerns as we look at moving that with us as our IT ecosystems evolve over time. We find it more and more difficult to track consumption of services and rationalize what that value is that IT is providing. This is going to be a key concern over the next few years. How do we answer the ROI question? As companies are rewiring to support the digitization of business, we need to address the aspect of fluidity. It's about a constantly changing ecosystem, a constantly changing environment. It's not so much a physical structure as it is an organic structure. The connective tissue which exists within your enterprise today, right now as I stand up here, will have changed by the time we walk out of this room and have lunch a little bit later. We need to be okay with that. We'll call out to Charlie and some of the work that he's doing and some of his innovative work. He and I talked about this in Edinburgh a little bit. The key point here is that IT for IT is not a one size fits all solution. It's a framework. It's a tool to help us understand what the capabilities are. How we instantiate those capabilities within our organization is also driven by the scale of our organization. If you're talking about one guy sitting at his computer, a whiteboard and a stack of sticky notes is probably all you need in terms of management system. As you bring a team of folks together, you start dealing with coordination, keeping track of who's doing what. As you have teams of teams, you start to see specialization and process and handing things back and forth. So you start getting up to enterprise scale. You start dealing with things like portfolio management and prioritization, life cycle management and a lot more in depth capabilities needed to manage the scale and complexity. So what does IT for IT bring to this conversation? There's four things in this list. Two of them, the first two, are the key differentiators that make this standard different than a number of shall be unnamed frameworks that have come in the past. First one is the service backbone. The little purple dots that everybody tends to overlook when they read the reference architecture is one of the most powerful things that's been created here. You're talking about the connective tissue that allows you to track the evolution of a service from its conception as a need for the organization through its creation, its release and availability, how it's being consumed and then the feedback that we learn as it's being operated. This service backbone is what is going to allow us to decouple the decision making and support functions from the value stream activities themselves and allow us to optimize the activities taking place within the organization and still be able to drive the decision making that we need in order to drive the insights. The second area is the request to fulfill value stream. We talk about the shift from being a design bill shop to being a broker of services. This is where brokerage takes place. It's all about what are we offering up as available? Who's using the services we're creating? What value is being created out of it and how much is it costing us to generate that value? As an integration standard, we talked about all the systems and capabilities that exist within your organization. This is a standard that can help you bring all those together. You may or may not ever get to that single IT management system, but you can get a lot closer. The standard can also help you as you're working with your customer and supplier ecosystem to help broker that conversation. We need to drive that coordination when it comes to deploying changes, driving feedback and problem management, resolving incidents and outages when they occur. But the last one is perhaps the most important. This isn't just a standard. It's not a book. IT for IT is a form of thought leaders that exist here within the open group to help us address some of the problems that we haven't even identified yet. A form that we can bring those questions and get people who are passionate about this space together to help solve them together. Kathleen talked about Ford versus Tesla. Most of our organizations have a legacy. We weren't created yesterday. We don't have the benefits of being a startup and starting from a blank page. Where do we start that transition and managing the legacy of our IT organization? The first place is to start with the people. This is going to be the long bar in your activity. It's going to be the most difficult developing the skill sets and mindsets within your workforce that will get you to where you need to be in the future. The second one is actually pretty easy. It's something you can do today. Take that IT for IT reference architecture, the one I was showing on the slide with the functional component model. Grab one of the printed copies and take it back to your hotel room or take it back to your desk in your organizations. Take a look at the systems that you have in place today. Where do you have redundancy? Where do you have gaps? Where do you have fragmentation? Where are you missing the capabilities that you're going to need to manage your organization in the future? You don't need help to do this. You all are experts in your organizations. You can do this analysis very quickly on your own. Most of the systems we're talking about here have an expected life cycle of anywhere from five to seven years on average. Your engineering systems, your service management systems, which means you don't have to change everything today. There will be an opportunity coming up within the next few years to leverage the natural refresh cycles of the technology itself and that opportunity to drive change. You're going to be replacing that system anyway, either doing a major upgrade or replacing it with something else. Think about what you want that next evolution to be. And focus on simplification. You may not get down to one system and you may not want to. But the fewer pieces you have in the puzzle, the easier it's going to be to get the value realization of what it is we're talking about here. And last off, turns out transparency is a good thing. Kitchens operate more effectively when the customers can see what's going on and how the inputs are transformed into the finished product. The world we're in has changed. Have you? Thank you.