 Hello, everyone. Thank you very much for gathering here. So, I don't know if you remember, but I did a similar presentation. Well, a precursor to this presentation at last summit. I don't know where any of you present when I did our enterprise ready to the enterprise to the open sector transformation a couple hands. Okay, so About me, I currently work at in advance and In advance being bought by red at I work at red at and actually I have two roles at the moment I'm at the same time VP products at in advance and I'm director of product management at For open stack at red at I've been working on open stacks since the very beginning Started the Cilometer project a while back I've been traveling the world a few times doing open stack and You can reach me on RSE and on Twitter at Nijaba If you're wondering what Nijaba means, it's the first two later for my first name middle name and last name so a year ago Six months ago actually times go very fast in open stack. I presented Talk our enterprise ready for the open second formation and this slide is the conclusion Which I drew? As a reminder, I think that open stack is not a product I think open stack is an engine which can be made to become Any product that you want? So that means that this engine will never be enterprise ready by itself however given that We are not going to be transforming to open stack because we want to save on money just for that that doesn't make sense There might be a reason a good reason to be transforming to open stack Which is transforming the way your enterprise actually deliver services and Today I want to follow up on this presentation by showing a sample roadmap of a project that goes toward that transformation, so Transformation What is it about we? Actually when we are going toward the cloud project very often the goal is to become more DevOps and Because there are as there is as many definition Of the word DevOps. There are people. Let me give you mine so I think that DevOps is something that has two dimension and that's why it is so difficult to define very simply There is obviously a first dimension which is a dimension of automation Where you want to go from standardization? to automation in order to do continuous Improvement of what you're delivering and there is a second dimension which is the way your People your processes and your technology are going to be interacting together So it's not a that's simple a problem You have to be watching for these two dimensions at the same time To give you a little bit more background in terms of standardization We have to be standardizing on technology and Standardizing the processes so that mean that if you want to be in a DevOps model You will first need to make sure everybody that is going to be engaged into This DevOps model agrees on these standards and that touches about everything That is going to be the basis on the way you're going to be delivering these projects there is Automation and automation may occur at all or any of these levels Today, I'm going to be focusing on the automation of the infrastructure since we're going to be talking about open stack but you may want to be Going up the stack once you're done with the automation of the infrastructure You may want to be automating the platform You may want to be automating the application lifecycle in terms of How you make this happen How you're going to be making sure that everybody is Working correctly one thing that we found out is that the agility is a key element in the process and here don't take this loop here and The thing that happened in sequence you don't need to go from a to b to see you need to do all of this all the time so in order for your project to become Better and better over time You need to be iteratively improving it by making sure that you're learning from the previous mistake and one of the thing that is very important in agility is To give the right for people to make mistake on the basis that you're going to be catching these mistakes very quickly and Fix them and improve from them when we're talking about transforming the people Transforming the people might be one of the hardest things Because you're going to have to transform the way that people think and in order to do that you cannot do that against their will people have a natural resistance to changes and Transforming those people is going to be involving showing examples demonstrating effectiveness training the people a lot of things That you need to build into your project for it to be successful When we're talking about the processes well, it's Very important that you always skip on focusing on What is going to be the desired end result and how you're going to be measuring this success If you don't have measurability, it's very hard to ensure success and regarding the technology well The automation is clearly the key as we were saying before And here we are going to be focusing on automation through open stack and automation of open stack You don't want that the to put together a platform that is going to be allowing you to automate the deployment of your application without fully automating the deployment and the upgrade and The handling of the full life cycle of the platform using the exact same principle In order to go faster Automation is the key if you have people processes In between key element of your flow your flow is going to get constrained and you won't be able to go any faster Now that this introduction is done. Let's go into the real meat of this presentation, which is a sample roadmap Something that is very similar to actual to actually a customer use case that we've dealt with on how we've We think it's best to go when you want to do this transformation When you're doing an open stack project so in this case we have a customer That has a few problems. His problems are that his it has been externalized They're It's actually they are working in a separate Sub-entity of their group. So that means that all the BU's that This customer is interactive with Do not have a strong requirement to be working with him they have the right to go elsewhere and Elsewhere means that very often The IT department customers are going to AWS and Are going to external competitors and so that's causing an issue for this customer because He's afraid that his very job is going to disappear in the near future another problem is that The Management of the wall entity is still asking him to make sure that compliance is still in place They don't want to see user data being stored outside of the authorised area for for this They don't want to see deployment of financial tools That would not comply with the specific norms that are applicable to where the deployment is occurring PCI DSS for example their Conclusion is that they need to be offering something that is similar or better Than what their competitors are offering. So they decide to go Toward building their own cloud environment, but the main question They come to us with is how how do we go at it? So That's in advance. We've developed a methodology which Starts every project with a two-day workshop and when I say workshop. I mean a Session where we work on making an assessment together with the customer. It's not in advance presenting to a customer how to do things it's In advance and the customer teaming up to try to find the best solution to the problem that are being brought to us The key element in this workshop is that the customer should come prepared with a list of use cases This list of use cases or is the list of things that needs to be accomplished By what we are going to deploy for for him and with him at the end of the day From this list we develop a common understanding of what the project is about and We have The first element of what we'll later on constitute our backlog We also think that another key component for this workshop to happen correctly is that all of the key Stakeholders for the project are present in the same room and that's for a very simple reason It's because people Within the same organization often Never had the time to really discuss the use cases And one we are once we start discussing the use cases very often these agreements occur And we if we have all these people we can identify the disagreement and hopefully find a suitable middle ground If we are missing one person in this room The agreement or disagreement will never occur another key element. Oh, this slide is ugly Another key element In this is in this workshop is to be assessing the maturity of the customer. You don't go from Zero to DevOps The same way depending on where you're from and this ugly slide behind me I was trying to make it nice But something happened in the middle Um Describe the different levels of maturity that we've seen to in organization trying to go toward DevOps It's not a rating system and In fact, you can have people that have a mix of these different cases But it's very important to understand where someone is before you start doing a project so Once we've got this common understanding of where we are at What we want to accomplish then the use cases and the way to solve the use cases start to take shape and The very next thing is to find a way to Time the project to define a roadmap to cut the project in simpler steps that will be Manageable within a reasonable amount of time and from our experience a reasonable amount of time should never be more than three months between the start of a milestone and its end Because if you go over three months things that seems to be very far away for everyone and Things starts to lag for this particular use case for this particular user story we Had a customer that presented us a series of use cases That fell very easily into three different types of populations that he was trying to address The first population that was identified was a population of administrators the people are going to be maintaining the cloud The second one was a population of developers the people that we're going to build application on top of this cloud and the third one was a population of end users and This division was the thing that Became obvious during the workshop that could be the different milestone that could be Giving a real rhythm to the world project And that's how we ended up with a high-level road map Where we Identified the specific use cases that the customer wanted to cover that we're matching XY and Z population Okay, so we defined three milestones as We would grow the cloud into Giving more and more services to more and more people in milestone one the first thing we did was Define an overarching theme for the milestone and for milestone one standardization and commoditation where the first two keywords we wanted to work on and In order for this to happen For automation to occur We needed to start with a small platform that would be our ongoing test bed the playground for admins that we could redeploy automatically as much as we wanted and On which we could automatically test if everything that we Were doing was working So we created a CI and we ensure that this platform was continuously deployed Based on the changes that we would make in a standard environment This had two goals in mind first and sure that we understand what the environment looked like what the customer would and define what the portal to access this cloud would be and To to start imagining what kind of SLA this administrator population would have to expose To the developer population because the the the customer of The admin population is clearly the developer population in milestone two The joining of forces of ops and dev Was one of the first keyword the other one was Focusing on the next population which was the user And to do this we created a second platform that would be dedicated as the developer environment Where we would produce a first application as a test case where we would develop the reporting and billing capacity and Which would in turn give us the tools that we needed to Define what would be the our standard templates which would help us define what would be the SLA that we would be using for the users and Define the user interface of the provisioning environment milestone three evidently was doing the first deployment of a third platform that would be the user targeted platform the real production environment and This was the most ambitious part because we would deploy the same environment in three data centers around the world So that the environment would always be as close as possible to the user population We wanted to add the ability from the graphical user interface for people to be asked a few questions that would allow them to Have a smart deployment of the application where it needed to be for example if I have an application that is aimed at Selling things to people in Asia it would make more sense to have this application Deployed in an Asian data center but you can add many more rules based on compliance based on what you know of the data center security and if You do that correctly then you do not need to have any more People interaction when you want to deploy a new application This platform would be the one that would be in production and would be where all the workloads would be deployed in the end and In this platform on its first deployment during the first milestone We would be able to validate the SLA cascading that we had defined previously and of course That would be the trigger to define what would be the next application. We would do so In the end of the at the end of the workshop we came up with this high-level design which is More a design of how we were going to produce the environment than a design of how the environment would be structured Well, we did actually during the workshop also provide a high-level design of the deployment But that's a little bit less interesting than this idea that we would have a single environment That would be consuming various upstream Combining them with the local modification. We needed to make configuration Additional UI etc all stored in a central git repository That would be the feeding point for a continuous integration platform Which would have the standard test that opensack provide Combined with the customer specific test that we would continuously Validate on the test or admin platform and once we felt comfortable that The modification that been made are working correctly on the test or admin platform We would then allow the automated redeployment of the development environment where the devs could then Validate manually that their application are still working or if they're smart they could add the test into the continuous integration platform to make sure from the source That we would never break their application And as a follow-up once that they are satisfied then we could automatically Redeploy the changes into the production platform. So Using reddit Tools based around open stack. We've got up about all the tools that we need to do this Continuous delivery of a cloud. It's a combination of multiple components Which go from the tool that will be used by the product manager to the tool that are used by the operations people We absolutely need to have this full range of tools to do the automation because this is the real Goal of this project transform the way we deliver it to people But the tools Needs to be combined with agility as we say before and in terms of agility at in advance. We've been advocating the use of scrum Into the project that is targeted at deploying a cloud the same way you would use scrum when you're developing an application and That means that you need to define your product owner and in our best practice the product owner is always Somebody from the customer Population it cannot be someone from in advance because Clearly in advance doesn't know very well what the customer wants So the product owner is always a customer person a scrum master and team members this should be a combination of people from the customer environment and From us so that Along the project we could transfer our skills to the end customer because the goal here is not for us to create long-term ties with the customer is to and Empower the customer to continue at the end without us and By using short sprints of two weeks that would produce small Increments over a three-month cycle we would ensure that we had result delivered and Measurable and verifiable by the product owner at the end of this short cycle we would and globe The notion of sprint within another cycle, which is the milestone Which has a three month duration? Which would be the exact right time at which to Revalidate with the business owner of what we are doing that we are going towards the same the right direction that what we've delivered match this expectation and Sometimes the market changes around the project. So you may want to course correct What you've been doing and of course this happened, but another thing that I didn't tell you is that Across the project We've been doing a little trick. I told you about the product owner that should always be the customer But if you remember correctly when I talked about the population I was saying that the customer of the IT team Was the deaf population that the customer of the deaf team Was the end user population so we decided from the get-go with the customer to Use a product owner That would be someone from the developer population and as we move forward in our milestones We change the product owner to be someone from the end user population Another thing that was quite important was this What we call the contamination principle as we want this new process to be adopted across the enterprise we decided with the customer that we wanted to Demonstrate an example of something simple that was the test environment and as we Demonstrated that we thought that we would have a lot more ease at finding people that would like to join this new process so basically you take a small group of people that are Sharing the same idea that you are you always find a few people that share the same idea the people that want to change Stuff there is always a little group that wants to do that and you use them as an example to Attract others in the second phase and As you move forward you split the teams So that means that once you reach Maximum number of people within a team which we set arbitrarily at 10 as we think it's a pretty good number to start splitting the teams You add new people to a team where you already have people that knows the process that knows how to work with the environment and so the the cross-training happened very naturally in that case and through this cross-training mechanism you very quickly have a population of Users developers and admins that becomes very familiar and got to your new way of Developing application developing environment that is As close as possible to what we targeted as a DevOps model This makes sense So in the end We had a customer that had a bunch of problem, which I Describe earlier For which we offered an internal infrastructure as a service and later on Even a platform as a service for which we built the three environment with self-service portals for which we organized the work in small team dedicated on delivering consumable items by size with a scrum methodology and with use of agility has the mean to organize the work process The result we got from that was Well, first of all, we use the cloud deployment as the opportunity to grow to DevOps second we Clearly saw a reduction in time to market for an application to be to be developed and deployed We were able to Have the customer regain control on where the application were being deployed and therefore They were able From the fact that these applications were now running on their infrastructure to produce the reports That they were asked to produce on a very regular basis it's also the way that certainly What each group wasn't doing became really clear to the other groups Once you start having your product owner There is not anymore somebody from your own team, but it's somebody from the team you're delivering to It's very easy to understand what you're trying to achieve a lot more than in the previous model that this organization was using and In the end this IT organization Became again the IT organization of the more global environment it became not any more a cost center but a place where people would go to generate profit and This change in mindset is really key because that ensure that the perception of what you're doing is now shared across the organization and as a mirror to that They also became a lot more business focus Focusing on solving the issues that the business had instead of focusing their what they thought were the internal Problems that they should be solving any questions Yes Can you can you speak in the microphone because this is being taped and does this work? Yes So one of the key success factors I've seen when you use scrum or agile in general is to actually get that feedback after each cycle So you get actionable feedback that you can base improvements on is Is that a challenge that you have seen? It's not a challenge. It's actually the the world point of it But getting it can be difficult if you don't have Customers that are willing to invest the time and effort. So, yeah, so that's a very good point getting this PO from the the customer population He is a hard thing to get and This is why we need to identify that from the workshop from the very early beginning of the project we need to have the business owner of the project to Make sure that they have people in their team that are going to be willing to be playing that role and Of course identifying these people is going to be key to the to the success because otherwise as you said You won't get the feedback that you need to improve Thanks So this can be an either bigger challenge if you're developing an application, which is outward focus In which case your internal product product owners or product managers needs to be reviewing what you're doing with willing sample set of of customer and that's a Challenge in itself microphone. Thanks. So when you when you scale up you have all these teams How do you monitor them when it comes to their willingness willing the to change? Because I think this is a is a big issue because when you scale up you you don't have an individual contact anymore But you have team contact How do you keep them with the mindset or how do you get them with the mindset? So this contamination principle that I was trying to explain in the little graph here is Based on the idea that once you've convinced someone you'll be able to convince someone else so once you've convinced a team that No, that's not the right line I went one two four when you convince a team that this is the right way to work when you make it grow The additional people that are going to complete the team are going to be to be convinced by the one that we're already there on The well-being of that of that process How do you monitor when you're in the next phase in the m3 and for how do you do things like that because? It's based on that the one person that's going to the next. Oh, how do you monitor the? Whether that's happening. Okay, or not. Well, you have Measurable indicators, which is the velocity of the team whether they deliver new features on a regular pace or not and you've also got the the people feedback That is collected both by the scrum master and the product owner Kurt you had another question What other challenges or resistance did you find in this transformation process? so The the challenges that we that we see is to get the commitment from the stakeholders It generally happens but on about 20 workshop that we've seen so far we've got two cases where The customer was not really completely willing to play the game and The good thing is that that shows up directly at the workshop Unfortunately at that time that that the first the first guy that ever did resist to this methodology Was one of our very early customers and we didn't have yet the gut to tell this guy Okay, we don't we're not willing to work with you. This is not going to work so we accepted the thing and Yeah, we spent quite a bit of time of Under delivering something that finally worked but not as well as we would have liked Second problem that we see is when we Identify the wrong people to be the first core team of the thing And this is something on which We don't know yet how to measure we have to rely on a manager to be pointing to the right people But if we end up with the wrong core team, we'll never have the advocates to go Advertise about this new methodology and give this Feel of oh, I want to be part of it too to the others Any other questions? Yes From your point of view, how should the the team the developer team manage their debates? For example Nova network versus neutron Is it should it be by via emails or cooler discussions or so We generally like to have interactive means of discussions and it will depends on the Habits of the enterprise we're working with some people have a very strong culture of doing video conferencing others have a very strong Culture of all being in the same room. Oh, did I mention that a workshop? Cannot work if not everybody is in the same room just because of the tool that we are using to do the workshop required to have whiteboards and sticky notes and stuff like that but Once we move into the project that the team can be fully distributed Or not depending on the the customer culture and we certainly do not want to be fighting too many wars at once If we want to go towards DevOps, we're not going to go toward Pushing an enterprise to go toward distribution at the same time We may want to do that later on but yeah, let's do one thing. Well at once so Generally the team meeting are occurring either Video conferencing in the same room or even RC we've seen groups of people that are really used to do RSE or any chat mechanism to do their Their daily meetings and that's works very well now Sometimes you need to have a debate that goes beyond a single HL team and How do you bring that to fruition? So it really depends Generally we start the debate via email or any other means like this But as soon as we send that it's very hard to get a consensus we call that to a stop and we bring them into another one of these workshop and The workshop is a great tool to align people because very often disagreement come from a Different perspective on the same problem. I want to solve Three use case art may not be the three same use case that the other guy wants to solve and therefore We are arguing that. Oh, yes, we should be using neutron or we should be using Nova Network While we don't have the same understanding of the problem to start with any other question Okay, so now some room for advertisement. Did you know that you can get? as a limited offer a free Certification exam from Red Hat. So come see us on our booth. Thank you very much