Yeah, thank you, Matteo and Alicja, for the invitation. This has been a very interesting and educational meeting for me. So I want to talk about a story mostly of experimental evolution. This is a collaboration with the lab of Ariane de Fisser. And it came out in Nature, Ecology, and Evolution just a couple of weeks ago. And this work has been spearheaded by two former postdocs in Ariane's lab, Martin Schenk and Mark Swart. And Mark Swart actually already appeared in the talk of Sarah Duxbury earlier this afternoon. So the general context that we're interested in are factors determining parallel evolution, in particular, of course, evolution of antibiotic resistance. And so very broadly, there are these various aspects that are important. There is, on the one hand, there is selection as typified here by selection coefficient. So the strength of mutational effects, the distribution of mutational effects, and possibly their interactions. Then, of course, there are the rates at which these mutations appear. So there's the mutation rates. But another important factor that I want to emphasize here in this talk is the size of the population. And of course, all these factors sort of interact with each other. So the competition between mutations that are selected or that are prominent because of high selection effects versus mutations that occur at high rate. This is sort of the theme of the effects of mutation bias. Of course, the mutation rate and the population size together determine the supply of mutations. And there is, in addition, this important effect of clonal interference, which sort of filters out mutations of particularly strong effect in large populations. So all these factors you'll see are sort of interacting in this story that I want to tell you. And the plasmid also appears in the story. So otherwise, I wouldn't be here. But you'll see that the plasmid is maybe not the most important thing. So the model system that we have been working on for a number of years is a well-known antibiotic resistance enzyme Tem1-B-dilectomase, which originally arose as a resistance enzyme against ampicillin. And what our studies and many other studies are looking at are how this enzyme can adapt to novel antibiotics, in particular, how it can raise its low activity against C4-texam by mutations. And we have spent a lot of time on sort of characterizing these mutations, determining their properties and their interactions and so on. But so the experiment that I want to describe was there the scope was a bit broader. So the question here was, how do populations evolve resistance against C4-texam in a sort of more open-ended way? So these experiments looked at the adaptation of E. coli to increasing levels of C4-texam in standard serial transfer experiments over 500 generations. These bacteria had the Tem1 gene on a multi-copied but non-conjugative plasmid. So they did have the Tem1. But as I said, this is a very bad Tem1, which doesn't do much against C4-texam. In order to maintain the plasmid, there was also tetracycline resistance gene on the plasmid and there was tetracycline in the medium. And so in this experiment, resistance against C4-texam could evolve through mutations that could occur either on the plasmid or on the chromosome corresponding to different kinds of resistance mechanisms. And this was what we were interested in, and particularly since we're interested in the effect of population size, these experiments were carried out at two different population sizes. So two times 10 to the sex and two times 10 to the eight. And altogether, there were about 100 parallel lines that were studied. Just a word on the experimental protocol. So I said the C4-texam concentration is increasing. And the way this was increased was to simply increase the concentration bias by a fixed factor whenever the OD reached 75% of the ancestral value. So in this way, we sort of tried to keep these populations more or less at a constant selective pressure. And what you can see in this spot, so here you see sort of the concentration trajectories of the small populations in red and the large populations in blue. And you see that the blue populations are essentially already sort of evolving at the maximal rate, whereas in the small populations, there is more variability. And of course, the small populations reach lower resistance levels than the large ones simply because they have access to less mutations. So this experiment was carried out for 500 generations and then we looked at what had come out. So we were interested in looking at the mutations that were present at the endpoint. And so the sequencing revealed about 1200 mutations. And what was particularly interesting here is that there's sort of mutation of different classes. So there are SNPs, there are different kinds of structural variants. And we decided to sort of distinguish here between small-scale insertions and deletions, so less than one kilo base pair and large-scale variants, which are larger than one kilo base. Among these structural variants, a particularly prominent one, which was actually unexpected was a deletion of the 10-1. So a lot of these populations actually got rid of the 10-1 because it didn't do them any good. And this is sort of a separate story that I will come back to at the end. On average, there were about 10 mutations per line and this number was essentially the same in the large and the small populations. And that already tells you that clonal interference played an important role. So the bigger mutations supply in the large populations didn't mean that they ended up having more mutations, but they just ended up having different mutations. So this is a picture of the panel of mutations that we found. This is of course not easy to read, certainly not in this kind of format, but just to sort of explain a little bit. So here is the chromosome, here is the plasmid. These are the small populations in red and the large populations in blue. And the one thing that I want you to notice here are these red bars on the right-hand side which correspond to the deletion of the 10-1 gene. So a lot of, in particular, the small populations often deleted the 10-1 gene. In some cases, since this is a plasmid that is present in multiple copies, in some cases some of the copies had it and others not, but this was a very prominent event and I'll get back to it at the end of the talk. Okay, so now you can, and so as I said, the thing that we want to focus on now are these different mutation classes. And so this is to begin with a histogram of the number of mutations per line in these different classes, SNPs, small-scale indels, large-scale structural variants. And you see that there are some differences. Most importantly, in the small populations you have less SNPs and you have many more structural variants which is sort of hinting at the main storyline that I want to get to. But since we were interested in parallel evolution, we wanted particularly to look at the similarity of these endpoint clones. So we introduced a repeatability index. So the difficulty here is, of course, that you're sort of comparing apples and oranges. You have SNPs and you have these large-scale structural variants and they sort of occur at the same time. So how can you define similarity on that basis? So what we did was basically to define a kind of normalized similarity based on the overlap of these mutational events. So for a pair of genotypes with M versus N mutations, you look at the overlap between all the events, their sizes, you normalize this by the size of either one or the other. So this index is not symmetric under A and B. So in order to symmetrize it, you just take the average of H, A, B and H, V, A. So this is just a convenient way of being able to determine similarity between mutational events of very different scales. Now, if you do that, then you can sort of quantify the repeatability.  So that gives you a kind of overall repeatability, pairwise similarity between the endpoints. And you can do that on the nucleotide level or you can do that on the gene levels. On the gene level, you just ask whether a particular gene is affected or not. One very conspicuous pattern here that you see is that there's more repeatability on the gene versus nucleotide level. This is of course expected because it's sort of coarse-grained scale. You also see that repeatability is stronger in large than in small populations. This was also expected because you have more clonal interference or things become more deterministic and you expect to have more repeatability. The really striking and unexpected finding, however, is this picture, which now compares the similarity for different mutation classes. And here I just show the snips and the structural variants. And so here you see that repeatability in the large populations is driven by the snips. So you have a couple of snips that are common and that occur over and over again. But in the small populations, it's much more strongly driven by the structural variants. So this means that different classes of mutations are important for the adaptation in small versus large populations. So where does this come from? So our hypothesis was that the population size mediates a transition from structural variants to snips. And this happens because the structural variants tend to have higher rates and smaller effects in the snips. So this was sort of the hypothesis. And why would that lead to this pattern? Well, this is due to clonal interference. So this is sort of schematically shown here. So if you compare a small population and a large population in the molar class like this and you have two types of mutations, high-rate, small-effect mutations and low-rate, large-effect mutations, then in the small population, the first type of mutation that appears is likely to be a high-rate, small-effect mutation and that will then fix. Now, in the large population, not too soon, no, not too much later, a low-rate, large-effect mutation can appear and this can then displace, sort of out-compete the high-rate, small-effect mutation and so the blue mutation fixes instead. So this is essentially a kind of competition between mutation bias and clonal interference. So you have mutations that are favored because of high-rate and you have mutations that are favored because of a large effect and the balance between these two is shaped by population size. Now, this is a kind of theoretical problem that has been discussed in the literature quite a bit, in particular, a sort of minimal model of this was introduced by Jan Polsky and Stolzfuus. So the minimal version is the following. Suppose you just have some wild type, the genotype and then you have sort of two alternative mutations with rates mu A and mu B and selection coefficients S, A and S, B and let's assume that the A mutation has higher rate but lower effect. So then you can ask what is the probability that A fixes first, okay? This was studied numerically by Jan Polsky and Stolzfuus. Now, it turns out that you can sort of develop a rather complete analytic treatment of this problem based on earlier work that we did with Kavita Jane and I don't want to go into that here. This is work in progress with Switzerland Park and this picture is just supposed to show you that we understand this problem. So this is a comparison between simulations and analytic formula and you should just see that this sort of matches. So what you see here is always that the probability for the high rate mutation to fix goes to zero as a population size increases. And so these are sort of different pairings of selection coefficients and these are different ratios of mutation rates. So here the mutation rates are the same. So in the small population, the neutral limit, the ratio is just one half. Here the ratio between the mutation rates is 100. So you start essentially only seeing the high rate mutations but at population sizes of 10 to the six, you only see the high effect mutation. So this is how population size sort of drives you from mutation dominated to selection dominated behavior. So this is sort of the hypothesis. Now, is this actually true? So how can you sort of check that? Of course, it's not easy for these thousands of mutations to determine their rates and their effect sizes. So we have sort of two kinds of evidence for this. One is that we can look at time resolve data. So we didn't do that for all the 100 lines but for five small and five large populations, we sequence the populations at multiple time points and try to sort of reconstruct model plots of these mutational events. Of course, the information that we have is only at these time points. So these plots that Mark Swarth created should be taken with a grain of salt but this is roughly what we think is happening. And if you do that, then you see that in fact in the small populations, the large scale duplications and deletions which are red and green here tend to appear first whereas the snips which are blue tend to appear later and in the large populations, the order tends to be the other way around. So the snips appear earlier and tend to dominate the evolution. So this is statistically significant. You can see that you can show that the order of events is different in large and small populations. The other piece of evidence and this is work was worked by my postdoc, Sangmin Wang who is now in Paris, was a kind of simulation approach. So what Sangmin did was to simulate use standard right-fisher simulations with three classes of mutations with which all of them had exponentially distributed fitness effects but with different rates and different means strength. And so in principle, this means that you have like the six parameters and there is in principle a kind of map that takes these parameters to the mean and standard deviation of the number of mutations in the respective classes at the endpoint. So Sangmin used the neural network to sort of learn this relation and this then allowed us to estimate the selection coefficients and the mutation rates from the endpoint data and this confirmed the hypothesis in the sense that the SNPs turned out to have the largest selection coefficient, the structural variance is smallest one and the rates also were ordered in the opposite direction and with a very significant difference in the rates between the SNPs and the structural variance. And in fact, these selection coefficients at least in relative terms, I think the absolute values shouldn't be taken too seriously because there are lots of things about this model that are not realistic but the ratios are consistent with an analysis based only on the mic values using a generalized linear model. Okay, so this is basically why we think that this hypothesis is confirmed. So let me finally say a little bit about the 10-1 deletion. So what we observed here is that 10-1 is often deleted from the plasmid unless it is rescued by a point rotation. And so basically you have this costly and useless 10-1 and you either have to get rid of it or you have to mutate it to make it work. And this is one of the large populations where this is happening. So after a hundred generations to a large extent, the 10-1 has been deleted but then there is a kind of rescue mutation that is called G238S. So this is one of the most powerful activating mutations which sort of saves the day and then the plasmid is or the 10-1 is maintained. So why does this deletion occur? So this is apparently somehow related to the construction of the plasmid which has these repeated regions which tend to promote this kind of deletion. We see that this happens more frequently in small populations. And this is again because of SNPs that you need to rescue the 10-1 are more likely to occur in large populations. Remarkably, we do not find that this 10-1 really has a cost or a benefit. So this is these are fitness ratios based on competition essays. And here you see that the 10-1 deletion is essentially neutral. On the other hand, the G238S mutations or this activating mutation has a strong benefit at large enough C4 tax and concentrations and it has a significant cost at low C4 tax and concentration. So it's clear that the G238S is selected for but there is no selection, there's no cost or benefit of the deletion which implies that the reason why it occurs has to be related to the fact that it has a very high rate. And so in some sense, this alternative of 10-1 activation or loss defines alternative pathways to resistance. And so this is again small and large populations comparing the MIG levels or the MIG increases that you achieve if you activate the 10-1, if you lose it or if you maintain it. And what you can see is that activation gives you a significantly higher MIG than if you get rid of it or if you maintain it. So these are sort of, and this is more, this happens much more frequently in the large populations. Okay, so with that I come to the end. So what I have told you here is a story about the contributions of mutation bias and flow interference to parallel evolution. So we saw how the population size sort of selects for different classes of mutational events. Sort of maybe methodically interesting is this approach of inferring mutation rates and effect sizes. And you see that in order to evolve high resistance, the pathway using this term one activation is needed. The experiments were done, as I said, by Arianna Fisser, Martin Frenk and Mark Swart and the theory by Sangmin Wang, who is now in Paris and also my long-term collaborator, Su Chan Park from Seoul. And so with that, let me thank you for your attention. Thank you very much, Harkin. So maybe we have time for some one or two questions, other questions. So otherwise we postpone to the discussion session.


As the world tentatively recovers from the pandemic, democracy is still ailing. Hit by a decade of democratic setbacks and exacerbated by states of health emergencies, the world is becoming more authoritarian. Even democracies are adopting authoritarian tactics, often with popular support, through the likes of media manipulation and politicization of judiciary. Many elected leaders have helped normalize this through polarizing social media and disinformation campaigns. At the same time, authoritarian regimes have used more repressive tactics in their efforts to remain in power. More than two-thirds of the world's population live either in countries where democratic freedoms are under threat or in non-democratic regimes. Still, while democracy is down, it is certainly not out. Pro-democracy movements have made valiant stands in places like Belarus, Myanmar and Cuba. Research has debunked the myth that authoritarian regimes are better at addressing the pandemic. But recovering from the global pandemic and addressing the pressing challenges of our time, like climate change, will require a renewal of democracy. International IDEA proposes a three-point agenda for this renewal. We call on governments to ensure democracies deliver new social contracts, rebuild institutions to protect electoral integrity and fundamental rights, and prevent threats through investments in education, independent media, and civil society. The next few years will be a crucial time for our planet. Hard choices must be made, and these decisions will be more effective if made through democratic processes and rights. But democracies must renew themselves. Join us in renewing democracy. Act now by reading our latest report on the global state of democracy and by learning about our global state of democracy data and analysis at www.idea.int.com.


Welcome to Data Doctor's video, Suggestion 585, Find a Grave, multiple profiles linked to same Grave ID. This index lists beginning times of each segment, so you can fast forward to any of particular interests. Suggestion 585 is caused when one or more profiles with similar name, dates and places are all linked to the same Find a Grave Memorial that has matching data. It could either be from an unrelated profiles data mistakenly based on the Find a Grave information, from duplicate profiles that need to be merged, or from one of the profiles such as for a relative with similar data incorrectly linked to Find a Grave. One needs to be a detective to untangle the correct information from the wrong. This segment discusses what to do if an unrelated profile has been incorrectly linked to the Find a Grave Memorial. Here is the Suggestion report for Joseph Hegeman, which shows another profile with the same Find a Grave link. The birth and death dates agree. The only difference is the spelling of the last name. The info column states only to compare. Click on Compare. This takes you to comparing branches on WikiTree Plus. This gives a generational comparison of the profile person, making it easy to see relatives who also might need their profiles merged. However, it does not compare the biographies. That is done in WikiTree. To get there, click on the first link. Here is the side by side comparison. Hegeman 36 shows a daughter, Catherine. Hegeman 225 shows a father, rim, and son, Jeremiah. The date of birth and date of death are identical. For Hegeman 36, the biography section lists Find a Grave as the source, though there is an ancestry family tree listed under See also. Hover over Catherine's name until an info box appears. It shows that she was born in 1786 in North Carolina. Now look at Hegeman 225. In the biography section, there is a baptismal record for his son and a source from Find a Grave. Hover over Jeremiah's name until his info box appears. That shows he was born in 1786, the same year as Catherine, but in New York. In the sources section, click on the link to find a grave. The memorial names his father, rim, and has links for his wife and some children, though none of the children are for Catherine listed with Hegeman 36 or Jeremiah for Hegeman 225. A close-up of the headstone photo shows the name spelled H-E-G-E-M-A-N. The conflict with Catherine and Jeremiah's births means that research is needed to see if the profiles represent the same person. On Hegeman 225, click on Root Search on the right. Root Search offers several sites to choose from. Let's start with Family Search. Note you have to be logged into that site first. There is one birth record listed. Click on the icon on the far right. On the record, click on Document Information. Copy the source citation that appears. Return to Hegeman 225's profile and click Edit. In the biography section, enter the birth year in the first sentence that lists his parents. Place the cursor at the end of the text and click the citation button above. Paste the source between the ref tags. Name the tag Birth. Replace the find a grave tags by the name and birth information with this one. Don't forget to add the forward slash at the end of the tag. Add a research notes subheading. Tell that his last name at birth was spelled Hegeman with two E's, but during his life other documents show Hegeman with one E. Click on Preview to check your work. Make sure that the inline citations are properly showing in the biography and sources sections. Go to the middle of the profile page and explain your changes. This is strongly recommended for all Wikitree users and is required for data doctors. For me, I identify myself as a data doctor and explain what I changed. Normally, I would also add the suggestion, name, and number, but in this instance I am only adding documentation not directly related to a suggestion. Save your work. Now, in researching Hegeman 36, there is an abstract of his will on ancestry proved October 1, 1792, the date by which he had died. It is clear these two profiles represent two different people. The find a grave link needs to be removed from Hegeman 36. On Hegeman 36, click Edit. In the data section, delete the date of birth. Since the date was originally marked as certain, mark it as uncertain. Change the date of death to 1792. Mark it as uncertain. Add New Jersey as the place of death based on the will and mark it as uncertain. In the biography section, delete the burial information and the find a grave record. Add information about the will. Create the inline citation. As before, click on Preview to check your work. Explain your changes and save your work. Return to the Suggestions report and on the far right, click on Status. On the Suggestions Status page, make sure your wiki tree ID is showing. Of the five status options, choose one. In this case, correct it. Leave a comment from the comment tense or make one of your own. I made one of my own. Click the Update Status button. The last screen shows the status history has recorded your changes. And you're done. This segment discusses what to do if the profiles need merged. Here is the Suggestions report for Fly 78, which shows one suggestion, 585. All the dates are the same, but the spelling of her current last name is different. The Info column says Compare. Here is a side-by-side comparison of the two profiles on wiki tree, not wiki tree plus. Fly 78 shows both parents and lists a place of birth and death. It also shows her husband and marriage information. Fly 226 shows only one parent, her father. While the dates of birth and death agree with the other profile, there are no places listed, nor is a husband shown. There is, however, a daughter, Birdie, listed. You can see in the list of siblings that each one has a half-sister also named Mary. That is because these two profiles are linked to the same father, Boone Fly. Now, read the biography section. Fly 226 has a source for her marriage to Henry Langeberger. There is also a census record showing Birdie as her daughter. They both have the same 1900 census record. It's certain that these profiles need merged, but first the spelling of the current last name needs to be determined. Click on the Find a Great link. The memorial has her name spelled as line B-E-R-G-E-R. There is a photo of the headstone showing that the last name is spelled with an E as well, which matches the marriage record. It's time to propose a merge. Return to the comparison screen. At the top, click on Merge Them. These profiles have already been approved for a merge. Be sure you are merging the highest ID into the lowest. Then, check for the correct information with parents, name, and birth and death. The only thing to change is her current last name. Combine the biographies so that it reads smoothly. Delete duplicate 1900 census and find a grave sources. Preview the work. Click Confirm Merge. The next screen shows the merged profile. Notice the half-sister Mary is gone. Go to the Edit page and explain your changes. Next, check the daughter Birdie's profile to see if her father is listed, as he wasn't when she was attached to Fly 226. He isn't. Make a note that his profile ID is Line Burger 10. Click Edit on her profile. On the right, click on Add Father. In the existing Wikitree profile box, add his ID and click Go. Her profile now shows both her parents. Return to the Suggestions report and on the far right, click on Status. On the Suggestions Status page, choose the status, leave a comment, and click Update Status. The last screen shows the status history has recorded your changes. And you're done. Please note, if there had not been an approved merge, as there was here, after proposing the merge, check back in 30 days to see the status. From your Watchlist page, in the top middle, click on Pending Merges. On the next screen, click on Pending Merges initiated by me. If it hasn't already been merged, rejected, or set as an unmerged match, it will be there. You can complete the merge at that time. For now though, on the Suggestions Status report, you would check the status proposed merge. This segment discusses relatives with similar data. Both of whom are linked to the same Find a Grave Memorial, but one of them is wrong. Here is the Suggestion report for Charles Guthrie, Fillingham, showing three suggestions, all concerning Find a Grave. 585, 575, and 578. They also involve the profile of Charles Foster, Fillingham. In the Info column, click on Compare. In Wiki Tree, not Wiki Tree Plus, here is a side-by-side comparison of the two profiles. Looking at the relatives, it is clear that Charles Guthrie is Charles Foster, Fillingham's son. Click on the Find a Grave link. The Memorial is for the father, Charles Foster, Fillingham.  Create a subheading, see also. Replace the current link with the full Find a Grave source found on the Memorial. Add the Wiki Tree Find a Grave template with the addition of same as equals no to indicate this profile does not match the Memorial. Delete the first URL. As always, click on Preview to check your work. Explain your changes. In this case, there are three suggestions to note. Save your work. Return to the suggestion report and click Status. On the suggestion status page, check the status corrected. Be sure to check the related suggestions boxes since they have also been addressed. Leave a comment and click the Update Status button. The status history lets you know the changes have been saved and you're done. You are invited to like this video and even leave a comment if you wish. Also, keep up to date with new videos by subscribing to our Wiki Tree YouTube channel. On behalf of the Data Doctors Project, thank you for watching.


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 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.  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 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.  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.