I want to talk about scaling up, and in particular in the context of how engineering comes to play with that kind of idea, because I think it does. A good place to start with that is what is it that makes scaling difficult? There are a variety of things I think. But often, one of the sorts of things that we think about is stuff like this. One of the responses to needing to scale up is to come up with ideas like this, a production line style thinking. And there's a fundamental difficulty here because this is not our problem. This is never ever our problem. This is not even close to our problem with software. And so any idea that's about scaling up like that is wrong. Our problem is very different. So we develop software. We crystallise ideas into a form that can be executed by a computer. And the result of that is a stream of bytes. And one of the things that is unique about a stream of bytes is that we can reproduce that essentially at zero cost for as many times as we like. So we never have a production problem in the sense of physical things. Our problem is something else. So when we're talking about scaling up, we're not talking about scaling up in the same way as anything else. We're talking about scaling up something very different indeed. And that ought to change the way that we think about it. So this is not a production scaling problem. So that means applying production line style thinking, which to some degree we're all kind of acclimatised to thinking that way because we grew up in industrialized societies. We're primed to think that way. But that's the wrong way of thinking about this. So waterfall, for example, is a software production line. Waterfall people even sometimes talk about it that way, which means it's not suitable for software. It doesn't work. It has never worked. The only time I've ever seen it work is when people cheated the process. So that's not the right answer. Or any really reproducible, standardised approach, cookie cutter style approach to developing software. That's not what software is and it's not how it works. So software development, I would argue, is very strongly an exercise in learning because in whatever context we find ourselves in, we are always creating something for the first time because otherwise we'd create it for free from what we had before because production is free for us. So we're always doing something new. It might not be new in the world. It might only be new in our context in our team, but it's always new. And that means it's always about learning and discovery. There's another aspect to software development that's certainly an increasing part of our daily lives which is that we build systems that are much more complicated than any human being can hold in their entirety in their heads and understand every ramification of them. And so in order to be able to deal with that, we've got to also worry about managing the complexity of the systems that we build. And there are tools for us to be able to do that, mental tools that we need to apply to be able to do those sorts of things. So how do we scale those kinds of things, those kinds of activities? How do we scale learning and how do we scale managing complexity? It's not an easy question to answer. Sorry, I'll just move my cursor up the screen a little bit. I've got ten things, five in each category that will help us to do these things. And certainly for people here at an agile conference, you're going to recognise many of these things, particularly on this side, which is agile is fundamentally about learning. So iteration, feedback, incremental development, evolving our systems step by step, working experimentally, learning and expecting and adapting, but being empirical, learning from production and changing our behaviours from there. Those are all at the heart of what real agility means. You can do all of these things without big ceremonies or anything like this. And if you're doing these things, you're definitely being agile. If you're doing the ceremonies without those things, you're not being agile. These are at the core of what it is that it takes to be able to really learn and be good at it. And then we need to optimise to manage complexity. We need ideas like modularity, cohesion, separation of concerns, reducing coupling, abstraction, so that we're able to make changes in one part of a system without worrying about what's going on in another part of a system that allows us to move more quickly. Now, the problem here when we're talking about scaling is that information is a kind of slippery idea. There's information in our organisation and the way that our teams interact with one another. And the problems are the same. The problems that I've just described in terms of managing complexity are really fundamental to information. They're not really about any particular technology or even software in general. They're true about us as well. A team is an information system and the ways that teams interact with one another have the same kind of problems of concurrency and coupling and so on. And we need to deal with those if we want to do things at scale. One of the difficulties is that, and this is always an increasing difficulty as we start to scale up software beyond a certain size, is that dependencies really don't scale very well at all. As our systems get bigger and bigger, the smallest change can have a disastrous effect. And so in order to be able to scale software development, we need to find ways of limiting the impact of these kinds of changes. So, what must we do?  It's a discipline that's founded around exploration and learning and we need to optimise for that. Dependencies in code and in organisations are caustic, but they are also unavoidable. If we need two parts of a system, whether it's a human system or a software system, to interact in some way, there's going to be coupling between them to some degree. And so we've got to figure out how we're going to manage that, how we're going to deal with that. And so in order to grow our ability to create software, we need to apply creative, I would argue, engineering style thinking to managing those sorts of problems. So here are a few principles that seem to me to be relevant here. So I've already mentioned a couple. We need to optimise for learning and for managing complexity. And as part of that, for both of those things, it's absolutely essential that we control the variables, that we're able to try things out and control the variables sufficiently so that we know what are the result of our experiments are. If I make a change to my software in the hope that it's going to win more sign-ups from users and you make a change to the software which accidentally wins more sign-ups from users, how do I know the impact of my change? How do I control the variables so that I can see the impact of my change and not yours? One way in which I could do that is I could work in smaller steps, release more frequently, I'm more likely to be releasing my change separately from yours then and I'll be able to see the impact. But there are many ways in which controlling the variables matter. If we're writing a test, how do we know that the results of the tests are repeatable and reliable? By controlling the variables, putting a system into a state that we want it to be in and so on. We want to get to the point where we can make more evidence-based decisions. That means that we need to start thinking and working more experimentally. The previous speaker was talking about trying ideas and learning from those ideas and be willing to be wrong. That's fundamental to learning and that must be part of what it is that we do. The way that I phrase it slightly differently but the idea is the same, I suggest that the granddaddy of learning is science and so we can learn lessons from science and we can apply those. That's why I call this engineering. It's kind of a practical form of scientific-style reasoning. But one of the deep philosophical ideas of science is that we're going to start out assuming that our ideas are wrong. Not that they're right and then we're going to try and figure out how we learn where they're wrong and how they're wrong and how we can improve them. That's a much better way of learning than assuming that we're right and trying to prove that we're right. It turns out. So never assuming that we're starting off with the right answer is probably a good starting place. Then we find ways to falsify our ideas. How would we show that we were wrong? That's a better, stronger proof than trying to prove that we're right. I can assert that all swans are white and I can never prove it but as soon as I see one black swan I know that all swans aren't white and that's falsification at work. It's a stronger statement and this is one of the lessons that we learn from science. The other aspect of scaling and taking this more engineering approach to thinking about this kind of thing is to check where we are all the time in our progress, essentially real-time monitors of where we are in our progress, in the safety of our changes and so on. I've led up to I suppose asking this question. What is it that you think of when you hear the phrase continuous delivery? I suppose I'm one of the people that's responsible for helping to popularise this as a term and as an idea. Although I'm not the originator of the term and neither is Jezz. Continuous delivery is one of the first principles of the agile manifesto as an idea. Optimising continuous delivery is really what Jezz and I were talking about when we wrote about it in our book of the same name. I'd be thinking of stuff like build automation and you'd be right, that's part of it. Deployment automation, DevOps, deployment pipelines, always deploying to production, maybe sometimes, automated testing for sure. I'd use this as a definition though. None of those things are definitional. All of those things are activities that we might undertake to achieve continuous delivery, but I'd say that this is part of the definition. Working so that our software is always in a releasable state and we want to try and keep it in a releasable state for as much of the time as we possibly can. That's a big idea and it's a challenging idea and it goes to the heart of pointing out where scaling is difficult. I'll try and point out what I mean by that. But let's start with the words always, always in a releasable state, always sends quite difficult. So how do we do that kind of thing? Well, we optimize for, sorry, let me just step back, optimize for fast feedback. I pressed it again twice. The delays are on that slide. Optimize for fast feedback, frequent feedback on the releasability of our systems. We want to try and get our system into a releasable state after each small change and evaluate that. That's at the heart of continuous delivery thinking and we want to do that all of the time as frequently as we can possibly achieve. Releasability determines the boundaries of scalability. If we can work so that our system that we are working on, whatever it is, is releasable by definition, then we're in a good state. It's tested as thoroughly as we're going to test it before we release it because now it's releasable that we'll be silly to test it more after that. So it's ready to go at that point. So this starts to put a boundary on how scalable we can go. One of the ways in which practically we can see the impact of that is through building deployment pipelines. A deployment pipeline is an automated mechanism to assert and define the releasability of our system. We're going to build and as automated as possible evaluation of our system so that we can make a change, get feedback on our change and understand how it stands in terms of its releasability. I can say this with more assertive more assurance than I can say most things that I say because I'm the person that invented the term deployment pipeline. A deployment pipeline goes from commit to releasable outcome. If we have a deployment pipeline that goes to something else, it's not a deployment pipeline. It's about getting to releasability. It's about being definitive for releasability. That's kind of at the core of the idea. This means if we have this feedback that we can be confident to make progress. We can gain confidence by testing our system very thoroughly within the bands of the deployment pipeline and testing thoroughly in this context because we can test it many more times than any army of people can do and I genuinely think that this is real software engineering. This is part of an engineering discipline and I find it hard to imagine how you can count it as engineering if you're not doing this kind of level of testing. This gives us a huge step forward in a confidence of our systems and our ability to release them safely. So what does it take to be confident? Well, here's my deployment pipeline again and first we want to make sure that our test pass locally. That's going to be the fastest feedback that we can get as part of the development process. Then we want to know that the code does what the developers think it's doing verifying those. This catches about research says this catches about 58% of production failures just that style of testing. Then we want to test, verify that it does what the users want it to do. Evaluate it in life-like scenarios in production-like test environments to get feedback on that. Then we may want to check that it's nice to use with human beings, not regression testing exploratory testing to try and learn just how the system is to use as it's being developed not afterwards. Then maybe is it fast enough? Is it resilient enough? Is it scalable enough? Is it secure? Whatever it is that determines feasibility. Is it regulatory compliant perhaps? I've built pipelines with all of these checks in at some point. At that point if all of those things have been determined by the pipeline we can be confident in releasing into production. It's a releaseable change. In terms of what do we mean by fast feedback which I said earlier well for the first part the development focus part I recommend that you aim for a target of feedback in under 5 minutes and for the whole thing to determine the releaseability I suggest that you aim for a target of under an hour. That may sound extravagant but people have done this with highly complicated systems highly complex systems and very very large systems too. One example is a company that I worked at. We built a financial exchange and just to put this into context of how many tests we'd be running hundreds of tests before a commit, about 35,000 commit stage tests under 5 minutes, about 20,000 acceptance tests user scenarios and that was exploratory and then hundreds of performance tests and we recorded the worst hour of our system in production and replayed it at 5 times load and these kinds of things and then thousands of other kinds of tests. So there's a lot of testing going on as part of this effort but this is what it takes to get to releaseable and getting to a releaseable state in under an hour ideally. If this were real engineering though it would improve the efficiency and the quality of our work and the data says it does both. The data says that if you can get this kind of picture at the kinds of speeds that I'm talking about the people that are working on it will have more fun, they'll be less burn out they'll enjoy their jobs more, they'll be more committed to the organisations that they work for. The development approach will be more scalable within the context of these things and we'll talk about the reasons for that in just a sec. But also the businesses that we're working in will make more money users will be more happy, the software will be more stable. I use a tagline for my business which is Better Software Faster and that's not an idle promise that's what the data says if you read the state of DevOps reports, the writings about Dora, Google and the Accelerate Book this backs this up with some evidence that says that this is a better way of working. When we're talking about releaseability strictly if I'm being very pedantic deployability is really what I mean because what I want to be able to do is I want to do a small drip of changes that may not yet add up to a whole feature but I'm going to end up releasing those into production and this is a tool that we can use to define the scope of evaluation because I'm going to evaluate my change to the point of its releaseability. That means I must be evaluating a releaseable unit of software. If at the conclusion of my deployment pipeline I now say oh I've got to go and test that with these other services over here before I'm happy to release it it's not a deployment pipeline. What this means is if we're going from commit to releaseable outcome in this way then that's the scope of version control, that's the scope of the deployment pipeline, that's the scope of release and so we've got a concrete reason how to apply that scope, what that scope means in the context of continuous delivery. It means that there's no more testing to be done at the end of the pipeline transit no sign-offs, no integration tests with other components of the system. There are two ways in which we can scale this. We can either grow the pipeline and invest in the engineering that's necessary to get answers quickly enough from it or we can decompose our system into a collection of independently deployable pieces each of which we're comfortable to deploy without testing alongside the other pieces. That's the real definition of microservices, it's not what most people that practice microservices think microservices are very often but that's what is in the definition. Microservices is an organisational scalability play. It's the most scalable way of building software but it does this at cost. This is a more difficult way of doing things because now we've got to be able to design pieces of a system that talk to each other but that we can release wholly independently of one another in order to gain the benefits of microservices and the scalability. It's a new presentation and I've got two versions of the slide, sorry about that. So in software though, scaling is more complicated than it seems and one of the ways in which it's more complicated is it's really this, we can scale the size and complexity of the systems that we create and what most people think is that that means that we can scale the size of our organisation to create things more quickly and we've known for a very long time that that's a really, really slippery slope. As we've just seen with microservices, it's possible but it comes at a cost in terms of complexity, operational complexity development complexity, architectural complexity to coin a phrase by the recently deceased Fred Brooks, a genius of our discipline. You can't make a baby in a month with nine women. There are some kinds of problems that have a fixed period of time a fixed amount of effort. You can't scale up by just throwing people at a problem and in software this is a very, very fragile thing. I like this piece of metadata research it's not deeply academic but they analyse the results of 4,000 different software projects of all different kinds and sizes. They divided the project up into teams of 5 people and fewer and of 20 people and more and then they measured two things. First, they measured how long it took each team to get to 100,000 lines of code. As you might guess on average the teams of 20 people beat the teams of 5 people but on average it took all of the teams about nine months to get to 100,000 lines of code and the teams of 20 people on average beat the teams of 5 people on average by one week in nine months. So on average a people working in a team of 5 are nearly but not quite four times as productive as teams working in a team of 20. Small teams matter, small teams are deeply important if we want to do good work in terms of software and that's about learning and about managing the complexity and those sorts of things. The other measure that they did incidentally was that they also looked at the number of defects that were created and the teams of 20 people and more created five times as many defects as the teams of five. This gets us into ideas of like organization or scaling and an idea that I learned of from my friend James Lewis of ThoughtWorks who got really interested in a field called non-linear dynamics and complexity theory and this comes from there. The traditional way of scaling an organization is something like that you build sort of a hierarchy and you have bosses and you have teams of other bosses and you have hierarchies of bosses until you get down to the bottom of people that do the work. Now the interesting thing is that there's some maths around this. These kinds of structures appear all over the place and the maths is about the scalability of these kinds of structures these kinds of informational structures is interesting. If you look at this for these sorts of directed graphs of information, people resources, whatever there's this number that keeps cropping up 0.85. If you have a team an organization company that's structured like this and it doubles in size its productivity its capacity, its profitability will go up by 85%. It won't double. There's a loss each time it scales. The flip side is is if you've got a team like this then if you double in size you only have to pay 85% in terms of infrastructure cost to keep it going. This kind of crops up all of the time. Double the head count, revenue increases by 85%. There's another way of organizing things though if you've got this and this is this kind of loosely coupled social network linked graph kind of approach. This is the micro services team approach. This is dividing the problem up into a series of small independent teams who make progress independently of one another. These are more autonomous. The number here is 1.15. This is what Amazon does and the scary thing about this is that when Amazon doubles in head count they more than double in profitability. That explains their explosive growth and this was a conscious choice. Interestingly, Jeff Bezos is one of the funders of the Santa Fe Institute of non-linear and non-linear dynamics research that's going on there. So he knew about this when he came up with the idea of this famous idea of two pizza teams and how that scales better. Now there's a cost to this. There's a problem with this because what you do is that you trade off consistency, co-ordination for scalability. You want these teams to be more independent. You want them to be in control of their own choices, their own destiny in order for this to work. If you want to be able to tell them what to do and apply more constraints to them it breaks this model and you end up more like this model and your scalability factor changes. It's a choice. You can do either one but there's more limits on this one but some advantages and there are fewer limits on this one and some disadvantages. The picture on the right is Amazon and the picture on the left is a scale up problem solving needs to be distributed. That's how we get to scale up. To scale up what we need then are strong motivated autonomous teams. We need teams to take responsibility. This is born out in the research done by the state of DevOps people. Their data says one of the strongest predictors of high scores is stability which measures the quality of the work that we produce and throughput the rate at which we can produce work of that quality. The highest predictor is the team's ability to make its own decisions. It can make progress without co-ordinating its work or asking permission from anybody outside of the team. Those are very different kinds of teams to what often we see in organisations. What does this look like in an organisation? How do we think about managing such teams? This is taken from somebody else's work too. This is from Gregor Hope and this is his advice of the way of thinking about leading autonomous teams. The autonomous team is responsible for nearly all of their work. They're responsible for making progress independently of other teams. First, we've got to find a way of carving up the problem in a way that we can give them that autonomy and then we've got to leave them to it. We've got to let them do the work experience the problem and they're in the work so they're going to be best placed to see any problems with that way of working and improve those things. But to do that we've got to give them some direction. So leadership in this context is not about telling people what to do it's rather about defining the strategic defence. It's about defining the boundaries within which their autonomy can exist and that they can make progress. But we also probably need to support those. I think one of the most important books of the last few years is the Teen Topologies book and in the Teen Topologies book you talk about using team structure as a tool to better organise software development and they talk about four different types of teams and the core is what are called stream aligned teams those are the teams that are building the software that people want that they're solving problems for our users that the users care about. And then you have platform teams, enabling teams and complex subsystem teams who support those and the idea of these other forms of teams is to use the cognitive load within the stream aligned teams so that the stream aligned teams can stay focused on the stuff that really matters. The outcomes that we're shooting for. So the idea is that we define tactics, common tools, common patterns those sorts of things to support the work of the stream aligned teams and allow them to make progress independently of one another. The first part is really about setting the goal. Leadership is about planting a flag on a hill and say wouldn't it be great if we could go over here imagine how wonderful it would be if we could do these things. That's it. It's not about how they get there. The job of the team is to figure out how they get there. So the job of the team is to do the work and all of the work to make something that is genuinely releasable and then the idea of everybody else is to support their ability to do that work and to maximise their ability to move quickly and deliver changes that users, outcomes that users really want. There are some techniques that we can use to try and breed this sort of autonomy in teams. I would say that this autonomy it doesn't really matter whether you're talking about the distributed graph kind of thing or the hierarchy kind of model the best model for software development this is going to optimise us to allow us to solve hard problems within teams without relying on coordination. If you go back to what I said earlier on this is a way of reducing the coupling between teams aiming for these autonomous teams and allowing them more independence and they can move at their own pace rather than being held back by other groups of people. So some of the techniques for breeding this kind of autonomy are goal or mission based planning what I've just said really wouldn't it be great if we could do this fundamentally focusing on the outcomes rather than the techniques that we use to get there. It's called mission based planning because this is a lesson that the military learned a long time ago for teams senior officers don't say go down this road turn left through that gate go up that road and then shoot those people they say take that hill sorry about the war like reference but mission based planning is kind of a way of maximising the effectiveness of people. You want the people to understand the problem and then figure out their own solutions to that problem. So the other part of this is to define simple well understood constraints we'd like people on these teams to understand what the goals are understand what the guidelines are for the organisation understand where they can compromise where they can't understand what are the parameters for their autonomy. You can't just go to a bunch of people that are used to working in a more traditional setting and say you're all autonomous now because they'll sit there and they'll go yeah really I know you don't really mean that if I'm autonomous I'm going to increase my salary to 3 million pounds it doesn't work like that so you've got to say what the boundaries are you've got to help people understand and allow them to genuinely be autonomous but within some constraints so setting some guidelines is a good idea the other key part here is what I mentioned earlier to manage the cognitive load of the team allow them to be able to make progress on the things that matter to their users and take away work supporting technology practices processes whatever it is that help that team make progress but don't get in their way the job of a platform is not to come up with some beautiful ivory tower solution that nobody understands it's to service those teams it's a service function teams need to understand the problem that they're working on I work as a consultant and I usually work in larger organisations one of the things that I see all of the time the anti-pattern that I see all of the time is something that I call programming by remote control using the requirements process to tell people what to do the commonest form of this is having a UI team that define what exactly what the UI leaves and that's given as a requirement to be handed into the development team defining the UI is part of the development somebody might come up with a better idea than a bunch of people doing that somebody might find out that that idea doesn't work very well and need to change it putting that responsibility into the autonomous team is part of this and to do that the teams need to understand the goals but deeply understand the problem that they're working on and they need to own the problem that they're working on again the previous speaker was talking about teams that were interested and going out and discovering the details of the problem talking to real users and so on this is something that we tend to have lost sight of a little even within agile teams but understanding the problem and the ownership of the problem is a core of being able to do a good job it seems to me I just want to give you a simple example really this is in terms of architecture because I'm a technical nerd and that's where I kind of think about things but one of the ways in which you can kind of constrain things is with architecture and one of the ways that I think of architecture is not as a prescriptive thing that tells you exactly what your answers must be but more like a tourist map so you want an architecture that kind of gives you a rough guideline of where stuff goes and the context of where the thing that you're working on is and how it sits I use these sorts of things these are things that I call whiteboard models and they're called whiteboard models where they're kind of a consensus of the architecture for a team and at least any senior member of the team is able to draw this from memory on a whiteboard that puts a limit to how complicated and how detailed it can be because you should be able to do this even for a big system but it's enough for you the reason I call it a tourist map is it's like if you go to the zoo and you want to know where the gorillas are and follow the path even though it's not geographically accurate these kind of maps allow us to have conversations about how software works together without worrying too much about detail these are useful tools that allow us to move forwards growing the responsibility and ownership in the team the best tool for this is ensemble programming mob programming or pair programming I'm an old school extreme programmer I'm a believer in pair programming mob programming is fantastic too though I have had an opportunity to try it but the idea is that we get to learn from one another it's the best tool to help us to lever up the culture in a team and the ownership and the sense of responsibility for the things that we're working on and the understanding and actually pair nearly everything not just pair programming they're most creative and to do that people they're most creative when they're working together on things talking about things learning from one another all of the time so we don't need to formalize that kind of training other than trying to encourage people to work together I would argue that the primary role of leadership is to teach not to command the goal is to help people do the best that they can if they have skills there understanding their talents maybe plant the flag that I was talking about before but it's not to say you must write this code like this this is your software this is the solution that you must abide by we scale decision making by making it pervasive distributed and continuous if you've got to go and ask permission from someone three layers up in the management hierarchy in your organization to do something that doesn't scale very well that person is a bottleneck your feedback loop is too long and we scale implementation by optimizing for fast feedback on releaseability if we can do both of these things that gives us an opportunity and if you look at the organizations that we think of as being good at this kind of thing able to operate at big scale they do both of these things thank you very much that's the end of my talk I hope I've got a few minutes for questions anybody no there's somebody at the back so it was amazing presentation thank you for this so my question is related to the latest trend what we are currently looking at let's say US market or European market or let's say world market we used to think from a technology point of view everybody's dream used to be MANG M-W-A-N-G companies but I believe if you really see today's trend from past one or two months I believe these five are the main companies which are basically coming down on their kind of like budgets number of people who is employed do you really think the model you just demote right now let's say with respect to say Amazon any step which they are trying to take back with respect to think which is backfired to them telling that why are they kind of like going for something like 20,000 30,000 people cut down in there is it because of overestimation or something like overconfidence with respect to their own decision making so if you're asking does this really scale this approach I think this is the only way that really scale the distributed approach that the trade off there as I said is that you kind of lose consistency to some degree but it's the fastest way it's the fastest way of scaling Amazon for example they have tens of thousands of developers and they are releasing change all of the time it's been a few years since I looked but the last time I looked the number of changes the number of new services introduced on AWS in one year a couple of years ago was about 2000 changes and there were overlaps, there was redundancy in those sorts of things because the teams were working independently of one another the if you work to try and keep things together and to develop in concert and rely on evaluating everything together that is possible ultimately it's less scalable but then you've got to do the kind of engineering that I was talking about getting the feedback Tesla is quite a good example of that they've actually got relatively few people working in software development at Tesla but they work very quickly they're a continuous delivery company they get very fast feedback on the system as a whole and they can make a change they can make a change to a car and that results in the production line churning out the new to design of the car in under three hours so this is the kind of thing that we're talking about does this scale, yes I didn't get all of your question I'm sorry but if you're talking about the distributed teams then more autonomy is better if people are trying to do command and control across time zones that's probably the worst of all worlds in terms of the organisational structure because then the people that are making the changes are going to see problems and they're not going to be able to solve those problems without going back to people that are somewhere else and don't understand the detail of the problem so you need the people in the work making some of these decisions and I think that's a deeply agile way of thinking personally and now I'm not entirely sure whether I've answered your question definitely yes, thank you this idea of having the problem distributed is interesting but I would like to know more on how to make it possible because the reason is that usually the organisational structure is more of a top down approach where we get a larger problem and define some strategy to solve it and that's the way it's flowing top to bottom so how you go about it is it depends on which route you take to some degree or are you going to build so the first thing I would say is if you're looking at continuous delivery as part of the solution and I think it is then the simplest way to do that is that you build everything together and evaluate everything together and release everything together doesn't mean your system can't be nicely modular nicely service oriented all of those things but if that's your scope of evaluation that's the simplest way of managing the dependencies between things and reducing the coupling so that's a world of continuous integration shared code ownership, very fast feedback and lots of engineering to get that fast feedback that's one way of doing things at the technical level the micro services approach the things to be doing then are thinking about contract based testing ports and adapters, architectural patterns at the technical level but both of these, the technical things aren't really the stumbling blocks for either of those the one big system is remarkably more scalable than you think it can work for literally tens of thousands of developers in a single repository if you want it to but you have to invest the engineering but the real hard part is getting people to start thinking differently I think that what we're talking about here with modern software engineering techniques modern leading edge of agile is a paradigm shift in thinking for software development and the trouble with a paradigm shift is it's going to simplify things maybe in the new paradigm and the picture's better in the new paradigm but it means that some of the questions from the old paradigm don't make sense anymore and they're not answerable and so trying to convince people maybe non-technical people in your organisation to adopt these changes is the really hard part the technicalities of it I think are reasonably well understood they're not spread all around the world but I can point to people that know how to answer those problems but I think that how you translate that in your organisation is a much more difficult cultural thing as a result of that one of the downsides of continuous delivery is very hard to adopt it's better than anything else that we know how to do I think that's hyperbole on my part I don't think that's hubris on my part I think that's backed up by the evidence but it's saying it's very difficult to adopt and that's a shame because it works better so if you're starting from a start-up start with continuous delivery because that's the easiest time to start but if you're trying to retrofit this to an organisation you're going to have a long journey I usually say to my clients if you're in a normal starting pace forgive me if you're in the realm of a flaccid scrum not really very good agile if you're in that kind of place it's probably going to take you two or three years before you're good at continuous delivery but the good news is that it's only going to be a month or two before you're at least as good as you were before and from then on you'll be getting better and better and better so it's a difficult change to make always and there's an awful lot to it it covers a lot of territory thank you hi the lmax slide you showed so which is like the cycle of tests in each so in that I have a curious question about like the local and dev environment you said that's going to be like hundreds of tests and in the UAT it's going to be 20,000 plus tests so it's probably going to be an automated test yes virtually all of the tests with numbers were automated tests so what kind of tools that has been used for making it work mostly it was JUnit and then stuff that we wrote the technique for the acceptance tests is based around building domain specific languages to evaluate the releaseable unit of software for our system and those sorts of things so there's a structured way of building those kinds of tests which drives the development process and helps development teams to understand the the outcome that they're striving to achieve as part of the requirements process so we build these things called executable specifications that define the target outcome so there are some technicalities to it but the technology itself doesn't really matter, you can do it with almost anything so it's going to be mostly of micro services related tests and not based on UI right? no they were UI based tests so we hid that, the test cases themselves didn't know anything about that that's a testing technique, if you want to learn more check out my YouTube channel there's some examples on there but in the plumbing of our testing at Elmax we were using Selenium to actually talk to web based interfaces for example and we would use all the technologies here and there but it doesn't really matter which ones you pick okay so in this case sprint timeline you guys have to make this process end-to-end cycle depends what you mean so we built the first version of the pipeline in the first iteration of the project so it took two weeks to have the first working version of the pipeline it wasn't as sophisticated as the picture that I showed you that evolved over time as need demanded it to evolve so the easiest time to start is right at the start with the first features that you write, you start writing some tests you build the deployment pipeline to execute those tests you deploy the results of your work even though that doesn't make any sense for users yet but if you build that then it's then easy to add to in future if you wait until you're nearly finished and then build it, it's hard okay and you'll show a slide for the distributed pipelines and scale pipeline so I wanted to know in the distributed pipeline the merging and integration testing grows high isn't it is it going to be the difficulty so we didn't we didn't do we didn't do integration testing as part of our strategy we did it occasionally but I think you need to stop because I'm going to have to charge a consultancy rate soon but there's a lot more stuff on this, on my on my YouTube channel so do check it out, there's a playlist about acceptance testing thank you, pleasure there's somebody over here hi Dave I'm a believer and promoter of continuous integration continuous delivery deployment so I relate to what you say very easily and thanks for all the work that you're doing in this space thank you there's one point what I have seen is that whenever we talk about continuous delivery it's primarily around engineering the tools, the automation it starts when the code gets committed that is when it begins and it ends when we deploy it in an environment now in this entire process to be truly to imagine that my product gets to the production on a regular basis there has to be also a mindset of identifying the change in the right granularity of the right sizing and if that is not done or if this entire impact of the change in the production in my software if that is not being identified in the right pattern then this is not possible I mean the code won't get I mean if we continue to create monster epics that continues for four sprints, three sprints we won't be able to release it so that part in the pipeline neither it is the engineering aspect there are a lot of sessions like feature mapping sessions or discussions that are happening right but that part doesn't get often covered when people speak about continuous delivery do you think I do agree and I also I also think that continuous delivery is wider than just deployment pipeline the trouble is is that deployment pipeline is the easy part to talk about so I have a training course for example that does exactly what you're talking about it talks about stories to executable specifications so how do you identify the ideas how do you analyse the ideas how do you get those to the point of being executable specifications and I think that's part of the engineering discipline as well but it doesn't often get talked about I think it's most often discussed in the context of domain driven design and behaviour driven development and those are fantastic tools I think of those as tools that are part of the continuous delivery process for the reasons that you just described but you're right they tend to get talked about separately the deployment pipeline isn't all there is there's more to it than that I think the best way to think about continuous delivery is working through our software is always in a releaseable state but that's also about more than just the pipeline that's about thinking about what's coming next thinking about the things that are out in the wild mean determining what's going to come next and so on the whole thing is a feedback loop that we need to optimise for I do talk about that in other contexts so once again forgive me advertising but my youtube channel has some stuff on those things today thank you one last question Dave you said we need to think of software as a creative discipline whereas I've heard terms like factory model industrialisation of software so these seem to be at odds with each other I think they are at odds I think that calling for a factory model or industrialisation can only be from people that don't know anything about software because it's not how it works thank you so much everyone thanks Dave thank you very much


Hello and welcome to the session. I am Deepika and I'm going to help you to solve the following question. The question says Find the value of k if the function fx is equal to kx here if x is greater than equal to 1 And fx is equal to 4 if x is less than 1 is Continuous and x is equal to 1 So let's start the solution so we have Fx is equal to kx here if x is greater than equal to 1 So right-hand limit x is equal to 1 is Limit to 1 plus f of x Which is equal to limit x tends to 1 plus which is again equal to Which is equal to k? This is less than 1 the left-hand limit x tends to 1 minus f of x which is equal to 4 and we have f of 1 is equal to K into 1 square which is equal to k Since we are given Fx is continuous x is equal to 1 therefore right-hand limit at x is equal to 1 is equal to left-hand limit at x is equal to 1 is Equal to value of the function at x is equal to 1 Now we have right-hand limit at x is equal to 1 is equal to k and The left-hand limit at x is equal to 1 is equal to 4 and f of 1 is equal to k So this implies K is equal to 4 Thus x is continuous x is equal to 1 if K is equal to 4 Hence k is equal to 4 is the answer for the above question This completes our session. I hope the solution is clear to you. Bye and have a nice day


Good afternoon, everybody. My name is Kathleen Mackie and I'm an engagement leader at EduServe. With me is my colleague Colin Blake, who is one of our solution consultants. Today I'll be providing a summary of the findings in our joint report with SOCTIM titled Local Government Cloud Adoption in 2018. Colin will then delve a little bit deeper into the technical perspective of the journey to the cloud. You'll notice on your control panel that you have the ability to ask questions. If you have any questions as we're going through, please feel free to submit them. We'll come to all the questions at the end. So for those of you that don't know us, EduServe is a trusted technology advisor and ally to the public and third sectors. We work with our clients to help them get the most out of public cloud through our suite of professional services, managed services and application development services in partnership with Microsoft. We help clients to understand their infrastructure, build a business case, define a strategy, migrate to the cloud, optimize their use of public cloud once there and develop digital services using the tools available. We believe in knowledge transfer, helping our clients to become skilled in delivering their own services. As a not-for-profit, we are free to align our objectives with our clients and are able to reinvest our profits back into the communities that we earn them in. We do this through our education programs or investing in community projects. One of the main ways that we do this is through the executive briefing program. The EBP has been conducting research and connecting the sector over the last three years. Our recent research includes skills for digital change with the PPMA, which is the Public Service People Managers Association, looking at the cultural impact of digital change, engineers for change in partnership with the CFG or Charity Financials Group, looking at the role that financial directors play in digital change. In the same vein, we are also running a project with SIPFA, the Chartered Institute of Public Financial Accountants, which brings us to the report that we have worked on in partnership with SOFTIM that I'm here to discuss today. The project ran from November 2017 until February 2018 and was made up of two main parts. Survey responses from 373 UK councils covering a range of information and in-depth qualitative interviews with 11 IT leaders representing 15 organisations. These organisations have varying levels of cloud adoption and a range of perspectives around the future of local GovTech. So through the interviews, it became clear that the main drivers for cloud adoption were resilience and flexibility. Our IT leaders spoke often of data centres that were really not much more than aging hardware in a shed. Maravon Hassell from Ailsbury Vale spoke of the increased resilience of standing on the shoulder of giants such as AWS and Microsoft and having accessed the state-of-the-art data centres that have millions upon millions of pounds invested in both the hardware and the physical buildings. Something that would have never, ever been possible in the district council before. Added to this are the security measures taken by the hyperscale public cloud providers to satisfy the needs of their defence and intelligence customers that becomes the standard service for all users. Rob Mzakiva from Enfield Borough Council spoke about the flexibility of being able to turn things off when not in use and spin up new service or autoscale to fit demand. This is a huge step change where historically capacity hoarding was essential to meet the unknown future demands in the estate. In the new world, capacity is waste as you only use what you need and you only pay for what you use. These factors combined mean that the councils that have begun to adopt the cloud have the opportunity to enable a more agile workforce to develop and deliver better services to the citizens that they serve in the way that they expect and deserve. Roy Grant from York City Council said it best when he said that what we have is a large oil tanker, but what we really need is a flotilla of smaller boats that can move in any direction at a moment's notice. We asked all of our contributors what they thought success looked like to them and Omid Sharaji made an important observation. He said, and I'll quote him directly, For us, success in IT would be when nobody is having a conversation about cloud. When the dialogue in your organization shifts to asking, is our portfolio the right portfolio? Are we designing services around citizens and exploiting the tools that are out there in the marketplace to do that? Is the data flowing through the organization in a way that is consistent and enables us to get new insight to automate? When we are having those kind of conversations and you are not talking about cloud, it's just a delivery mechanism. That is what I think success looks like. We can say with a degree of certainty that the majority of IT leaders in the sector believe that the question surrounding cloud is not if, but when. We wanted to find out what was holding organizations back and a few key themes were repeated time and time again. The first of those being cost. The impact of cost on decision making was largely based on two factors. The first of these factors is the shift from CAPEX to OPEX. We heard from our contributors that the effects of austerity have been felt most severely in the revenue budgets and that this made it difficult to build a business case. As I mentioned at the start of this presentation, we are currently working in partnership with SIPFA. So I took the opportunity to pose the question to the chief financial offices on our panel. The answer that they gave was somewhat surprising. The reason that business cases are failing is not based on the CAPEX OPEX debate, but rather on the cost-saving focus of the business cases submitted. The business case for cloud is not a cost-saving business case. It is so much more than that. It's about providing an environment that enables the business objectives of an organization. The second blocker related to the cost is also closely linked to this idea. We heard that many organizations have completed like-for-like comparisons between their on-prem estates and the same estate on cloud. There are two considerations for the argument. Steve Achella told us, I have never known a facility's team who can tell me how much our data center costs to run, let alone are able to help with the calculation that we might save if we moved out and sold the building. The significant proportion of the costs of running a data center are bundled with other costs that make it difficult to fully understand total cost of ownership. The other consideration is that you will be unlikely to need to move your entire estate to the cloud. To quote Steve again, The challenge for us is we identify what we can get rid of, what we don't want and get it to the right size. Furthermore, work undertaken to rationalize your estate prior to migration will decrease the cost of change in the future. And as more and more organizations move to the cloud, we would expect the cost of hardware and licensing to rise in line with the declining demand. So when you are making a business case and looking at cost, it makes sense to look at the return on investment two to three years down the line and not just a TCO comparison. The second major blockade to cloud adoption spoken by our IT leaders is legacy IT. Many councils are locked into long term contracts for specialized services. This would not be as much of an issue if the suppliers were moving more quickly to provide cloud native or at least compatible replacements for their services. Councils rightly want to get the most from their investments and are reluctant to reprecure procedure reprecure a solution before the contract completion. Even when the services do become eligible for reprecurement, there is still a delay in finding a cloud native solution from vendors. Simon Hughes from Mid Sussex Council said, if there isn't a good market in terms of supplier choice, we aren't moving. At the same time, we are also moving other areas of our IT estate towards infrastructure as a service. So we have less to worry about in terms of maintenance updates and patching. This is one approach and Colin will speak more on the other options available shortly. The last major blockade to cloud adoption from our panel of IT leaders surrounds culture and skills. I have chosen to use Marivon's quote here because their approach was very much on one end of the scale. Ailsbury Vale District Council put all of their staff through assessments to determine their fit within the culture that was needed to embrace the council's trajectory to become tax free by 2023. Only the staff that matched the behaviors and attitudes needed to make this goal a reality remain part of the journey today. This approach may not be for everyone, but is often said the culture eats strategy for breakfast and for good reason. The most successful transformation programmes will engage everyone from members to data protection and governance colleagues all the way to frontline colleagues at the earliest possible opportunity, providing education every step of the way. IT is no longer a support service for the business, but rather how business is done. We all work in IT. In other words, there is a question surrounding the changes to the traditional IT teams. We asked our IT leaders how they thought that these roles would develop. Gareth Paulett from Cheshire said it's true that move to the cloud means that we won't need to do everything that goes with managing our data centres in house. And yes, part of our business plan is to release expensive contractors. However, we still need people to manage plan and deploy IT. Any capacity that we can free up is resource we need to take the organisation forward so that we can act as business partners as we undergo further change. A sentiment that was echoed amongst the group was that colleagues who have been used to fixing broken things and stroking tin will be able to focus on higher value work that contributes to the business objectives in a quantifiable and meaningful way. We know that there is a skills shortage in the public sector and providing these types of opportunities will go a long way to ensure that you can attract and retain high quality staff. So in summary, our advice and the advice that we got from our panel would be make sure that you start with your business objectives. It's not about cloud. It's about the business objectives that you're trying to meet. Work with your finance team to understand the business case. Start early, engage with all levels of the organisation as early as possible, educate where necessary and bring everybody along for the journey. Find a partner that will transfer their knowledge to your team. This is vitally important because once your partner leaves, you need to have the skills to maintain your services. A phrase that is often heard in our office is that while the technology piece is complex in many ways, in comparison to the issues that I've spoken about here, it's the easy bit. So I'll hand over to Colin to take you through the easy bit. Thank you, Cathy. Just a little bit of background on myself about myself. I was working as an engineer in the field up to six months ago. I was working on a large scale, blue light deployments, police force in the Midlands. As part of that, I did a migration to the clouds with a tour jaune and a lot of loads there. And during this process, I was hit with the absolute certainty that the cloud was our future. And as such, I got re-certified and changed my job role within a couple of months. And I found myself here very much an evangelist of the cloud. We EdgeServe have spent a lot of time mapping out journeys from on-premises platforms to the clouds. And the reason why we have done this so many times is we had our own private cloud ourselves and recognising the breadth and depth of the services on offer by the big players and the rapidity of change we were unable to effectively compete. And so we made the decision to move ourselves to the cloud. And being a trusted tech ally of our customers, it would be disingenuous of us to move ourselves but not to move them. And as such, we've migrated them to the cloud as well. So we've been through this process many times, many different application servers and cloud providers. And in our experience, the journey follows three distinct phases. Discovery, migration and optimisation. Discovery is possibly the most important part of the whole process and the most difficult to get right. We were working with a local unitary council and we managed to get contracted to do the discovery phase for them. There was no effective documentation. SCMDB or Configuration Management Database was all over the place. They didn't know their servers, they didn't know their licensing. And as such, if you don't know what you have, how do you plan to migrate it? There were so many unknown facts we had to have a mix of approaches. Firstly, he started with workshops. He just gave us an opportunity to speak to the people that work with the platforms and know them the best. This is an invaluable source of knowledge and should be overlooked. There's good opportunities to sell the benefits of the clouds, what they're going to gain, they're going to free themselves up and be an opportunity to do more interesting and meaningful work for the organisation. Or a layer of fears, in fact, as a lot of people think, as their servers go to the clouds, that's where their job goes as well. And they'll be left high and dry. On a side note, I was looking on a website just recently and it was, will I lose my job to a robot? And people with cloud and IT skills were in high 90% unlikely. So in fact, getting into a cloud and obviously job security. Regardless of the tooling, there's many tools, including Azure Migration Center and AWS Migration Hub. The players have spent a phenomenal amount of money making it as easy as possible if you get your kids up into the clouds. They want you to be hosting off them. And that is to identify cost sensors and applications. It helps you as an organisation see who are the biggest consumers of IT in your organisation and then reflect that in costings and budgeting and things like that. It also helps highlight where SaaS offerings may be more effective than physical deployments. Talk about Beryl and Bob in finance, having their own server, their own sand, electricity, power, backups, offside backups and all these for just a couple of users who have a SaaS application software as a service out there. So simply retire the platform and physical platform and move them to a SaaS. Offers, this also allows us to offer comparisons of analysis between public clouds. There are so many variables and these are changing all the time that the marketplace is incredibly fluid. They're very, very competitive. They are keeping each other honest and in real terms the price is being driven down. And if one supplier gets an advantage, it's always very short lived because the other will pull them in. We're talking about AWS and Azure but it's also Google Cloud and so the market's becoming more and more competitive. And the other thing to consider is no matter how much work you do on your pricing, it is a snapshot of that time. And from that point forward, like an uncontrolled printed document, it starts getting more and more out of date. So it's easy to get your information together, look at all the different variables, make a decision and then decide to go with it. Finally, the discovery phase can be used as a blueprint for your cloud migration. It allows you to traffic light all your applications. Yes, no, maybe. Is it gonna be IaaS, infrastructure or service, PaaS, platform as service or SaaS, software as a service. You need to determine all your interdependencies between the applications. If you lift up your web front end away from your database and you have one part in the cloud or one part on-prem, the traffic up and down and latency is going to be expensive and produce a poor performance. And finally, this allows you to finalize your order ensuring your dependencies are addressed. As I said, this is a print and it's a living document that you use in discovery. Then go into design and then it just keeps evolving all the way through and eventually this should be the document that you have that has a blueprint of your cloud deployments. In our experience and understanding the implications of licensing regardless of which cloud provider you use are significant and it really does have an impact on the affordability and return on investments. In fact, there are many organizations that have full-time professionals just working on licensing. solely and nothing else. There's license mobility. So in the simplest form, mobility is moving the license from physical kit that you have already in your data center and applying that up in the cloud. A really good example is SQL. Most people have SQL. You have to license the OS, license the application. You're doing it per core. You're paying a lot of money for it. Your SQL server has to be able to handle the highest load of thrown at it. And as such, it needs to be a fairly robust system. You can host your SQL in the cloud using an iOS deployment and your SQL license in is fully mobile and that's across both clouds. The Paz offering, which is a platform as a service varies between the clouds. So AWS have a pricing system which is licensed included but it's sure you can use what's called a hybrid juice benefits, which I'll cover in a moment. Network, virtual appliances, firewalls, load balancers similar objects or appliances. Very much most of the big players now are offering mobility of licensing or hybrid deployment. So you can just lift the licensing straight off your physical device and put it on a VM in the cloud and then you would have the same functionalities you had before. Generally speaking, server OS is not mobile but there's one exception which is enterprise agreements and software assurance from Microsoft. These allow manageable volume licensing program and the main benefit of this is hub as I alluded to earlier. Hybrid use benefits allows you to use your licenses for Windows standard and data center to be migrated to the cloud. You can then run your Windows servers as at the same price as Linux servers and effectively recoup the cost of the OS. So in this Unitary Council, where we've just been at before, they had a SA for 1,532 calls. This allowed them 191 VMs with eight calls and 28 giga RAM to be licensed and reduce costs. These are really about servers and the core OS systems and they realized a significant saving. Okay, once you complete the migration phase, sorry, once you complete the discovery phase, you move into the migration strategies. These are all, can be implemented to migrate your platforms to the cloud. The strategies were built on the five bars by Gartner in 2011, but AWS had an additional few years later and this is a process that's run after discovery. It succeeds only by having certain clarity around interdependencies of services as I discussed previously. So in the first instance, we have Retain. This essentially do nothing. Your application isn't cloud ready and you only migrate what makes this sense. In all cases, I would say change for change's sake is to be avoided. Retire the application or decommission it. Each application owner needs to honestly state is it still necessary? Now some people would have been working with these for many a year and they hold a soft spot for them but this is a time now to say, is it really relevant in the current marketplace? Rehost or lift and shift. Arguably the most common migration at this time, you're lifting your kit straight from your data center and putting it into the cloud. It is easier to make changes once you are in the cloud and metadata has been gathered. Replatform, which is optimizations. So this is making changes in flight. Essentially lift and shift with some changes as you go. Again, I would say it's always easy to make your changes once you're in the cloud and changes for change's sake should always be avoided. Repurchase or buy SaaS. Here's a product out there that already meets your needs. Do you really need exchange in the cloud or should you use exchange online on Office 365 with all the support that it has? And finally, rearchitect. This is creating your platform from a green field deployments. It needs to be cloud first in nature using decoupled dependencies, making it resilient and scalable. So you've discovered your estate and you've classified it and now you need to get the data into the cloud. This is the journey. There's multiple tools for migration. There's native tools which each cloud provider have. They're always striving to make your journey to the cloud as easy as possible. AWS server and migration tools are very good as is the Azure site recovery. You can simply replicate your VMs from your data center into Azure. There are many third-party tools and these typically cost per VM and they may offer you additional functionality such as rollback after deployments. Or you may choose to use a partner with experience for migrations. In many ways, once you're in the cloud, it's just a start to your journey. The iterative and continuous improvement of your state is a goal that's always to be achieved and this allows you to gain maximum throughput, resiliency and efficiency for every pound you spend. You're really looking to squeeze your pounds and get as much process and power as you can. In the first sense, you monitor your platform when it's once it's live and use sources of information to gain metadata, CPU, RAM and utilization of VM. Errors and latency may be on an application. Then you look to make changes through informed decisions about what you'd like to change. You can scale in or scale out, which is additional or reduction of identical instances on the platform tier. You can scale up where the instance size is increased and within a single tier. Or you can move to or from IASL, PAS. There's many choices that can be made. Once you're there, then, you need to test all those and make sure that it's working. The metadata that you highlighted in the first instance, you need to test again and make sure that you made improvements to the service. If you've made changes and it hasn't improved service, you really want to roll back as you're making more changes onsites by not improving service. Finally, we have a look at the different model types that we have in the cloud. As you can see here, IAS gives you more control, but it's more complex, whereas you have less control and less complexity with SAS. IAS treats the service as cat or not pet. There's no more stroking tin and hoping the next hardware changes are fatal. If an IAS resource is not performing, as expected, simply tear it down and rebuild it. If you have a specific configuration that can't be supported further up the stack, you want to look at IAS. You remain responsible for the performance and management from the OS level up, and it's vital that you have the workforce to support this. An ideal candidate for this would be like a line of business SQL server with dedicated configuration. Moving up the stack, you might look at Paz where you have a shared management model where you simply consume the processing capabilities and relieve yourself of the management overhead. SQL is a managed service where you deploy your databases for your data only and applications consume that. For instance, you can have a single instance or a managed pool. It's tempted to use pools in most cases because you get shared resources, but you could get contention leading to poor performance. So for instance, a SQL database that runs overnight and one that runs during the day would be an ideal one to have on the same environment. And finally, on SaaS, you completely move away from management and the user only consumes the data of the resources. You have the least amount of complexity but also the least control. Essentially, you get where you're given, but it's ideal for services where you don't have the internal capabilities. And then we look at sort of reserved instances. So going back to the previous discussion, we talked about the load of business SQL server as a steady state, 24 hours a day, the load is fairly continuous. And as such, you see the load here on the green line. You need to over time get some metadata about where your peaks are, no matter how shallow they are and make sure you have an instance that addresses that. And you pay for that over a one year commitment or a three year commitment and you get a reduction in price based on that. And that can be seen here. So on the left, we have a model of pay as you go and these I ask load costs of 50K in the first instance, with a one year commitments to a reserved instance will drop to 40K. And then over three years, it'll drop to 30K. The one issue that needs to be addressed here is you need to be certain that your load isn't gonna drop over time because if you have a drop in load, then you won't get the same cost effectiveness by having the new I ask instance. And also then we look here, auto scaling. So this is where you respond to erratic or burstable loads that's gonna be represented here on the green line. In your data center, you would have had to have had a box, a square that would have covered the peak of the loads and then that would have been there for that entire time. So much over capacity. So what we look at here is looking at a smaller instance that covers the 95% of your loads. Checking metrics of the application or VM. As soon as you get to peaking loads, you add an additional instance and that is called scaling outs. And we can see here that we follow the bell curve of the line and add additional instances as the metrics are triggered. Equally on the downside, as it calls off would be removing instances as well. This allows you to get the most throughput but agile response to loads from your I ask platform. So in summary, your results will only be as good as your discovery. Without a clear understanding of your starting place, you will never reach your goals. Use all the tools are available, especially talking with people. If you can sell the move to people early, the whole process will go much more smoothly. Licensing, it's very important to understand your existing profile and make efficiencies where possible. License mobility has real benefits. It is worth bearing in mind that on-premises may be more viable in the future as the marketplace changes. Microsoft may more aggressively markets clouds licensing and when you need to license something in your physical data center, you could just put it down from your software assurance. And management, this is a never ending process. The market is fluid and always changing. It's always good to have a trusted partner that will help with horizon scanning and optimization suggestions, thereby ringing out as much as you can from the money you spend. Thank you, Colin. I hope that that's been useful to everybody so far. We are going to take some questions. So if you wanted to type in your questions straight away, we'll get to them as we're going through. I think we have one question here. So the question is, I have used lots of data centers in the past and it is extremely difficult to get your data out. What is stopping the cloud providers from raising prices and making it impossible to leave? Do you want to take that one, Colin? Yeah, there's nothing that we can predict in the future or give a definitive answer here, but I will just go back to where I said before about the competitive nature of the marketplace. The way that cloud works, you would move your infrastructure to the clouds and then you would have everything coded as infrastructure as code. That makes the process of moving away from a cloud provider much easier once you're already there. And the other thing to remember is that your skill sets in the future, if you were to remain in a data center may become so obsolete in the marketplace that you wouldn't be able to have the workforce in place to make any changes even if you needed them. So in my opinion, although we can't predict the future, we can predict the competitive nature of capitalism and as such prices should remain competitive. Great. So we'll give it another couple of minutes just to see if any other questions come through. While we're talking about that, I think it's probably good to note over here as well with that last point that one of the best things that you can do is you can find a supplier, a partner that's gonna work with you that'll help you to rationalize your estate so that the cost of change will be hugely reduced. I know from our perspective, what we do is we provide our customers with infrastructure as code, which means that although we hold the IP for that, you can take it away and reuse it as you need to. Just another couple of minutes. Any other questions at all? Yeah, if I could just expand on that a little bit perhaps. So as I said in my section, once you get to the cloud, that really is the start of your journey. You have an iterative and continuous process of improvements. So you have the monitor change and test. And as you go through that, initially your changes may be fairly large, but over time you'll just be refining constantly. And as new products and services come online, you need to look, can you get more for your money? Can you get more throughputs, CPU or RAM on VM instances? Or is there a new service? So for instance, moving from IAS to PAS, that would give you the greater efficiencies that would allow you to give the same service but at a lesser price. Thank you Columns. Right, I think it was probably quite a lot to digest. So we've got my contact details up on the screen. If you have any questions at all, then do feel free to either contact me by email or give me a call. Everybody that's been on the webinar today is going to get a recording of this webinar, so you'll be able to re-listen to it. You'll also get a copy of the report that we were talking about. I suppose that leaves nothing, but for me to say thank you so much for your time. We hope that you found it useful and we'll be in touch. Thank you.