 Goed afternoon. Welcome all for joining everyone. I'm sure that if you shove over a bit we can fit everyone. Today we're going to talk about some key considerations for a successful open stack deployment. My name is Bart van den Heuvel. I'm a EMEA consulting practice manager. My name is Alberto García. I'm a senior architect in the EMEA cloud infrastructure practice. I'm also leading the EMEA cloud infrastructure practice. I'm trying to handle this because I think that he has seen his own life. It's not my fault, it's its fault. Just to make it clear. Bart? We're going to show you the key considerations for the open stack deployment. Can you show me the next slide? I would like to see a raise of hands because we would like to have this a bit interactive. There's also a microphone on that side of the room. I would like you to share some stories or anecdotes where you feel appropriate. We're in an intimate setting, so not too many people. We can really share some of the details of your cloud deployment here. I would like to know who is already building or who is considering building an open stack cloud. I know some of you are already done this. Who is already running an open stack cloud has been through all this pain. I know you have because we've joined you in your journey somewhat. Okay, thank you. Good. Open stack brings many opportunities. We've seen this morning in the keynotes as well, that there are many industries that are looking to deploy open stack. Sorry. No worries. But they're looking for four main factors to do so. It's unifying IT, getting rid of all these different bare metal models, all these different virtual machine clusters and everything. Open stack brings that opportunity that you can really unify all your IT on a single platform that you can really specialize in and invest in. De standardization reduces costs. I think that's why most companies do this, because it's really simple for the eye, but it's also very good for your wallet. Automation, deploying everything via APIs or via your deployment tools, also reduces risks. You can test it as a whole and then press the deploy button en it will do it in a very dependable and predictive manner, hopefully. Most automation will do this in a repeatable manner. It's also a basis for the cultural and process changes. Because your IT is now very simplified and under control, you can really reach out to your dev in your ops and say, let's work together. This is our unified generic platform and focus on automation. This is the basis for a lot of cultural change, because you have your hands empty to work on that. This is the real world. We have risk. It's not all about opportunities. It's the real world. We can fail. These are the four main risks we have seen in our experience in the field. How many of you are techies? So, botanical people love to go. Lot of people. I'm a techie as well. I'm used to go directly to deploy stuff. SSH into the machine, installing things, that's fine. But the risk I have is not getting anywhere, because I don't know where I'm going. I'm just trying to install stuff. It's my goal to install stuff. There is a business driver behind me. I'm installing something because there is a business driver behind me. So, the second thing, the second risk is too expensive. So, how many of you have ended up customizing a lot of code because, you know, we are techies. We can customize a certain driver, certain filter. Let's customize it. I can do it as a developer. Then you end up with a platform that is really expensive to maintain. You need very deep knowledge on your platform. It's not a standard. This is not something you can control. So, expensive to maintain. Bricks all the time. So, how many of you had a tough schedule? I need an Opestack. I need a great Opestack. And I need it tomorrow. So, how many of you? A lot of you, isn't it? So, we want to build the cloud. We want to build the cloud tomorrow. Not in two months, tomorrow. So, build it quick. Let it hard forever. This is the risk. We built it quick. I didn't evaluate what I was trying to do. And it hurts forever. So, I'm with the fire extinguisher. Every day trying to fix stuff. So, or the last one is awesome. I deploy an awesome Opestack environment. But they deploy Opestack for its name, not for its ability. I'm trying to cover a use case that Opestack cannot cover. So, or I tried to onboard the ground users into my platform. So, how many of you have seen this? For all of you that have a current Opestack cloud in their premises. Any of you have seen these risks? Place hands please. Don't be shy. Yeah, good to start. So, business context of Opestack deployment. So, these are the user categories we have in the Opestack organization. So, did you feel identified with any of them? You had to be in any of these categories if you are running a cloud already. So, I think that I don't... Sorry. I think that we don't have to go through them. Also, we will be coming back to this later during the discovery demo. So, just to say what we have seen. Yeah, that's good. So, we've seen a few project modes. Approaches that people doped while building these clouds. So, one interesting one, and we see that with several cloud providers, is build it and they will come. You want to build your IT infrastructure. You don't care too much on who is going to use it right now, so you don't know any details about your future customers. But you do know your way around ordering hardware and setting up these clouds in a very effective manner. So, you will build it and then eventually your customers will come. So, there's not a too close relationship with your future customers. So, no real requirements together. There's also the pure practical approach and that is what the technical people love most. So, you just focus on the technical detail and you try to achieve that. So, probably you'll just install your RPMs and it will work, or it will fail. If you fail, you think, yes, something to learn and then you'll revisit it. If your manager comes along and says, how far along are you and when can I expect some results, he'll say, I think I'm there, but I don't know, could be a week, could be a month. So, that's a pure practical approach and I think that's very valid. You will learn a lot. So, in the end, it's a very practical but workable solution. There's also the pure academic approach. We see that a lot with NFV in the RFP phase. There's a big book that they will release containing all the elements that they need, all the details of what they need and much of this is predicted in the future because you don't really know what will happen down the line if you need to adopt any changes or you need to maybe some details don't quite have to wait in reality that you think it had in the beginning. So, that's why we use our preferred one en that is the modern use case driven approach. This approach is where you discover a use case and you build a minimal viable product around it. So, you check your business parameters, you check your technical parameters and we'll go into what you need to get to actually create your minimal viable product en then go in iterations, stacking use case or use case, you'll end up with a very nice, a very valid, relevant deployment. Each use case will have to discover, design and deploy method and then you can stack them as you can see here. So, the bottom line is the investment you make. It's the time, effort and budget you will invest into your product. First, you start off simple. It's a very easy thing, maybe it will take you two months, three months to build this or any amount of time and then you can manage or you can deploy manage systems. Meanwhile, you can focus not only the project team but also the organization. You can focus on usability. The whole solution will mature inside your organization and it will work wonders on acceptance of the solution. So, not taking two big steps but bite-sized chunks that will help you achieve your success in the long term. Is this clear so far? Yes? Okay. So, here is where the interactive thing starts. I'm keen to hear what you have to say because otherwise it's just me and Bart speaking and this is not the purpose of this session. So, these are the topics we cover during the design session, during the discovery session. Are you familiar with them? Do you see important facts before getting hands on the technology? Because what we usually see and I'm going to use, this is very professional en I'm going to use the pointer. Is that a good goal that I'll hear? Design a high-level solution for something that I have no idea. But it's what customers ask us. So, I want OpenStack, you are the expert, design it. This is not the way. So, what do you think that is the first step of a discovery session? First thing, you have to know. Anybody? The why is absolutely valid. So, we like to focus on the fundamental problem or the fundamental new ability to achieve. What are we actually doing? Why are we investing this money this time and this effort? Can we go back? I think. The wonders of technology. For instance, this could be... This is a difference between your core business drivers. This is actually what is hurting or what you would like to achieve. I think this was the good slide. So, these are very generic things. We sold them in the keynotes this morning. Generic enough to just name them here to put them in the keynotes. Is anyone brave enough to step forward and to explain some of their business objectives in the field? Any of you? It can be a consultant that has done an OpenStack deployment and knows the main business objectives of the customers. Guys, don't be shy. Okay. Thank you. I think that is much better. But I can grab the... Hallo? Sorry. What's your name? Nice to meet you, Brad. Hi, Brad. Back. Why? Do you have already a cloud in your premises or you are thinking of building a cloud? We don't currently have a cloud. We are thinking of building one. Why? We are using a really strange ad hoc developer platform. I've only been with the company a short period of time. So, I've arrived to a company who are doing development on individual blades. So, they've got about 200 blade servers. Each one is allocated to a developer who then does what they want on KVM on that blade. And I've come from an estate where I ran 3,000 VMs on 96 blades. En looked at the hardware cost is about three times higher and the company is smaller. So, it's very inefficient. And you see OpasTech, the way to provide this infrastructure as a service to the developers. So, I've got a lot of experience being there. I've got quite a bit of experience in AWS. I need a little bit of open stack which is why I'm here. I don't know about open stack. But I've come into the company. The company is saying open stack because they're a completely Linux house. There's a lot of KVM in there. And some of the company customers who are running the software are doing what they want to do. So, an open stack platform as well. Apart from providing this API-driven infrastructure to your developers, are you looking forward to a standardized infrastructure? So, I have a common vendor for all the blades using one vendor for all the blade equipment. But then, equally, there are customers who are saying they don't want to be tied to individual hardware. So, you need to have that abstraction layer within there. But it's the time to get code onto the systems. It's the time to build environments. It's the time it takes for testing. So, if you run an overnight test and it times out at 2 o'clock in the morning and no one's watching it, there's so many inefficiencies. Do you think that this will improve the process of onboarding new developers? Because currently, if you have to add a new blade, I think that this is a long journey to get this in production. It takes eight weeks to order a piece of hardware, doesn't it? And how long does it take you to spin up a virtual environment? An entire network with a virtual network in firewall storage, everything. It's 45 minutes. To summarize that, it's actually true. So, these what I call generic things, because you said that they're now busy on individual blades, which is not very flexible. So, you're looking for some new flexible platform where you can do things faster and probably more reliable. One of the things is if someone really wants to... They've got a massive amount of code they need to compile. And they've got the oldest blade, a five-year-old blade sitting in the infrastructure. And maybe Bob, who sits next to them, goes on holiday for a week. And Bob's got the newest blade in the infrastructure. And he's sitting there doing nothing. All of that computing power is wasted. And this poor old guy is going to be sitting there on this really old piece of hardware, taking hours to do anything, as opposed to trying to spread that load. Right. Thank you. Thank you very much. So, this is really interesting, because now you can corner off your project. If you invest some time and write down these stories, then you know what you're building, but you also know what you're not building. You build your minimal viable product, so you think, this is my fundamental problem I want to achieve, and this is my... or fundamental new ability that I want to achieve. Right. So, that also means that there's a whole world that you're not doing. It saves you an enormous amount of time of money, time of money to have a focused starting point and take that into your business objectives. So, this prevents if you onboard a new technical guy, and he says, I've been to the OpenStack Summit. I know what OpenStack can do. I want this, but I also want database as a service, or ironic because you know it's fancy. Then you can say, no, no, we're focusing on these business objectives and that will make your OpenStack deployment a lot quicker and successful. Sorry. So, what do you think that this is the next one? Anybody? Let's go on design. I'm a techie. I want to design something. This is going nowhere. So, nobody? Okay. I'm from the south of Spain. I can speak all the time. Okay. So, the next one... Is identify the core business drivers. Isn't it? We know what your fundamental problem is. Then I'm going to see what is the business that is behind this problem. Guess what? The company is doing business. They build new platforms to get money or to save money. There is a reason always. So, based on the business drivers that are behind your OpenStack deployment, you are going to be categorized in one of those. So, if you are at Telco and you want to save money in the TCO or you want to avoid vendor lock-in and these kind of things, you are going to be placed in the NFV user categories. The same. So, maybe it's good to have another show of hands. So, who is actually building something for a public cloud provider who is in the business of just selling out virtual machines and be the next Amazon. Ok, that's good. Who is more in the NFV space? Working with telcos or virtualizing. Ok, thank you. Enterprise internal cloud, maybe replacement of your current virtualization deployment. Good, thanks. What we also see, and this is very interesting, is to support a specific scientific or manufacturing process, like HPC, where you actually extend the capabilities of OpenStack to something really bespoke. OpenStack is a framework of technology powering HPC or maybe CICD pipelines or along that lines. So, who does something really specific with OpenStack to power a specific process? Ok, thank you. Ok. Something went wrong. Sorry. Yeah, back again. So, next step. Do you think that this is a good idea thinking of I can deploy OpenStack as a green field? How many of you think that you can deploy OpenStack as a green field? I can drop a silo in my ID en I think that this is going to work out perfectly. Totally insulated for all the IT of the company. So, how many of you think that this is going to work out? Nobody. Yeah, you thought. We get it a lot. So, people come to us and say we've got this OpenStack and we want to be bimodal. So, we're going to do this next to my current infrastructure. We're going to assemble a new team so we can do this completely green field. We've got lots of standards. Everything is new. No boundaries. This is going to be the biggest, newest, most strategic OpenStack project in the world. And we're going to start off completely clean. And then we're starting. And then I'm requesting networks because, you know, you need to connect your OpenStack to the outside world somewhere. And then someone slips me a list of security requirements but I can't build my cloud based on that. And then it turns out that the green field is not all that green. It's actually a very smelly brown field where you have to do these considerations. So, it's absolutely unnecessary to be completely honest and to say, what is my current state of my IT? And this is where we actually show this maturity model. It's a bit of an old slide. I think there's no year there. We've been showing this to customers for a few years now. And when we start off this conversation, we ask this customer, where are you in this scale? So, it goes from zero to four. And zero is more or less what companies start out with. So, they have their own builds. So, they have either on paper, automated, or they have some image they can put on systems. It's called the core build and they have a mechanism to provision it. That's where it starts. So, there's no real inventory of systems and there's no real provisioning of other things. And then there's level four where everything is designed and everything is written down in policies. Orchestratie, compliance, self-provisioning. Everything is handled. So, this takes a bit of self-knowledge to actually go through this. So, most of the people we speak to, if they're completely honest, they have some elements of level four but they really, in reality, they are in level one. And for a successful open-stake deployment, you need to have your automated provisioning in order. Because how are you otherwise going to do the automated deployment? All right, so these things need to be in place. So, this is interactive. So, I would love to hear from you. In which of these states do you think that your company is now? Anybody? No answer, no goodie, guys. I don't have a problem of bringing you the microphone. So, what are the aims in one, two, the good days, three, four? Depends, no? That's right, yeah. And then it turns out that from yourself as an IT provider, you can say that you're on level two because your basic deployment is in order and your basic images can be deployed in an automated fashion. But then some other business owner in your organization comes and says I have all these weird new requirements and are you then as an organization strong enough to say, look, you need to develop into automation or you need to invest in automation. You need to make sure that you have developed according to company standards before you can be enrolled in our platform. And that takes a bit of guts because otherwise you will have five or six open-stake deployments that will cater to all these different needs. So we need a very sturdy manager to accept these workloads. Is that the case in your organization? For sure. Yes. And I believe that you also have a very good security officer to enforce them. Thank you. So, anybody else? Before? It's not actually my current company but when we started in my previous, previous life, the company was definitely in the level one, maybe something from the level two. But it didn't even achieve all of the things in the level two. Did they actually go through a cloud deployment? So were they busy with cloud? We first understood that we had to remove all of the manual activities and operations, scripting everything either with simple, say shell scripts or something more advanced. It was a few years ago, so at that time, I don't think that Ansible was even out of the end. We choose pop-up like many others. So we removed all of the manual activities, everything scripted, and we added the testing for everything. And I believe that when I left the company, we were pretty much compliant with, I believe, every points in the level four may be except one. Right. So you accepted that automation is the only way to really make use of your cloud deployment. So you eliminated all the manual steps. So that was your, was that obvious from the start? Or did you try and do some manual action? We tried, but we followed many iterations, so we ended up with... Thank you, good story. I think we can learn from that. So even attempting to make use of your cloud deployment while you still have all these manual steps is probably not a very good idea. It's really necessary to focus on these things. So, I'm back. Do you think that makes sense? So you have a current IT. We have to be aware of where we are putting OpenStack in, isn't it? Otherwise what we have is this bimodal IT, but really bimodal, because you are going to have one IT and another IT, and you are going to create processes for your ITA and you have to build processes for your ITB en you are going to divide your current IT. That makes sense? No? Yes? I can answer myself. Yes, it makes sense. Okay. You are a very tough showmaster there, Alberto. Yeah, because I am very tall now. Okay, so I'll get to the next one. Yes, players. Because this is one I think is really important and often overlooked and that is responsibility domain. We already noticed that as an infrastructure provider, as a cloud provider, you have a level of control. So you know what hardware you buy, you know what operating system you will run and you have maybe some added services that you add as a value add service. That's your responsibility as a cloud admin. It's a very restricted, very clear boundary until you get your first users that will say, I will want to use your cloud platform. I don't care about the infrastructure. I just want to deploy this stuff. Can you give me a Windows 95 image? And that's where you say, okay, how am I going to do this? So it's very good to have a clear view on your responsibility as a cloud admin and also look at this with your key stakeholders to see how you're going to provide the add-on services. Maybe you need an image factory that will allow some tested and certified images before you can actually give them to your cloud users. And at the same time for your cloud users, it's good to set responsibility domains there and it doesn't stop right there. So you have the cloud admin and the cloud user. You've introduced responsibilities for your vendor. Maybe you're accepting a hardware vendor to do some things. So normally when we go into a discovery session, this is quite a thick chapter in the report we make because this is important to get straight from the start. Who is a cloud admin here? Only one cloud user. Who has a story to share here because this is where things are really interesting. I can ask you funny questions. In your company, who is providing the images? The cloud users or the cloud admin? For instance, you because you raise your hand. So in your company, who is the responsible of the cloud images? In our company, we leave that to the cloud admins. Cloud admins? Ja. Why? Because we provide the users with security-hardened images. Okay. So in this, following the security topic, some companies very secure, like I know your company, I don't know it. Security groups, the ACLs apply to the network. Is this something that you allow the cloud users to provide by themselves, or is this something that you control? It's a mix with us. As we're onboarding our applications onto our cloud, the developers, who are the cloud users, are sitting with the cloud admins and working out what ACLs they need for their apps. Occasionally, we're having to tell them that no, any, any is a really bad idea. Ja. Okay. Quite loudly. This is, no, is very important, because so do you have buying from your senior or executive manager, because when there's a, because I can foresee a power struggle where this manager says, there's no way we can accept your workload on this platform in these conditions, because it's unsafe, you will expose your company. But if then the infrastructure manager is not strong enough or the power is not in balance, then he may be overruled and then you're still exposed. Hoe is dat met jouw organisation? Het is nog niet een probleem, maar als het is, dan zijn de cloud admins de dag van de dag uit. Ja? Ja. Dat is goed. Ja. Oké. Oké. Dank u wel. Is er iemand anders? Ideen? Ja. Kan je please come? No, I can do that. I can do the walking. So, I just wanted to say that there are a lot of companies, I believe, in where there's not such responsibility and not a dedicated cloud team. You know, just a bunch of teams working together trying to put out a cloud, but not a dedicated cloud team. So I don't know if it makes sense to put effort into having a specific team for this kind of deployment. It's a question. I can say... Do you hear me? Yes. So, I can say my experience because you know, I'm an architect, I've been in the field, I've seen some stuff. So, sometimes it's not as clear as cloud admin, cloud users, some companies working. Are you a fan of Game of Thrones? Do you know it? It's the same. So we have the kingdom of the Linux system, the kingdom of security, the kingdom of networking, the kingdom of storage en everyone wants to manage something. Then the responsibility domains are really spread. The security team wants to secure everything, so they want to touch everything. The networking guys wants not only the physical part of the network, they want to manage this specific piece of virtual networking in the cloud. And they want to manage it. So at the end, the user is doing nothing because all these teams are trying to handle everything by themselves. So this needs to be set up at the beginning of the project, before starting the project. And everyone needs to be in the same room and they have to agree the responsibility domains. Otherwise, in the middle of the design phase, what you are going to get is when you think that it's done, a new stakeholder is going to come and say, no, no, this is my piece of the platform I want to do this thing. And you will never end in getting new requirements. So this is a really important part of the project. And before the project, I would say. Do you agree? Yes. And this is also a very key argument why you need project management at the early stages of your project. Because this needs to be identified. It needs to be written down. And also enforced sounds like you're in battle. But you need someone to say, look, this is what we agreed on. And yeah, kind of enforce it. Shall I take over? Yeah. I'm not used to single mouse button systems. OK. So, let's look at... No, time line. Time? Yeah. So, last thing is, before you click, what is the, you know, when you start thinking about time lines, what is the date that you usually get? There? No. You usually get the go live, isn't it? So all the project is the go live date. So nothing is happening in the middle, isn't it? So you have to deliver a cloud, 28th of March of 2030. No? But the reality is that... Sorry Bart. No worries. I know my place. Is the theme... It's my laptop. Yeah, yeah, yeah. Things happen in the middle. So these are very easy ones. Could be that certain team needs to certify the new software before you start deploying it. This is two months delay. You don't think about this constraint. Before you start the project, you are going to estimate the ground effort. You are going to estimate ground resources. So I would love to know which are the constraints in your specific environment that will affect the timeline of a possible OpenStack project. Anybody? Okay. Security guy. So one of the constraints is security. Yeah. And you have to think about security at the beginning of the project. If you do it at the end, you lost yourself. What is going to happen is that it's not going to be secure. Because if you try to do it close to the major player at the end of the project, what is going to happen is that all the people are going to say, no, you are going in the next release. Or the stopper. But if you cannot stop the project, you are not going to be the priority, isn't it? The security is just a business. In fact, you have to think security. Yeah, okay. And this is a very good argument why we like the minimal viable product connected to a roadmap so much. If security is this important, then you can have a minimal viable product, start with a insecure environment that you don't put in production, but just install and then make sure that you have a platform to actually test and validate it on the security level, right? And your colleagues is going to be how useful you are if you are involved at the beginning of the project. And then you start out with an MVP that is not secure en one of your future use cases is to actually deploy a secured and validated. But then you really enable yourself to do it because if you want to do all these things in one go, then you may not have the ability to control it because then you have your timelines and you're not really dependable or seen as dependable. Anybody else? Because security is one thing but we build clouds for a living and most times we were asked to join projects when there's already a date for the hardware to be delivered. We have no real control on the actual hardware design or things which I think is a pity. I also really like building clouds so I don't know why all these people do this in such a hurry. I prefer to give you some stories so I'm going to use my experience on that so you can have examples of what I try to say here is that for instance in one customer during the discovery sessions we figured out that we needed four months just to execute penetration tests and the certification of the new software in lab. And plus these four months we had to request the resources with two months in advance. Gee, if you just assume in dates the goal life date was not realistic, isn't it? So you tell me that in four months I had to build a cloud but you have a process that last six months is not going to work out, isn't it? So this is the value of looking at these things before you start a project because if you don't look at this you are starting a project before it even started because you cannot deliver on date. Sorry. I cannot hear you, sorry. So the question is why is this different for cloud? This is true for any project. You need a project management planning and everything so why is it different for cloud? So that is a very good question because in a simplified view a manager sees things as simple as they can. I'm a new manager and I know what I'm talking about here so it's true. So what is the problem? Why wouldn't you do this? So my experience with OpenStack as a framework of technology you accept so much new technology so much new way of working a new way of deploying all these workloads so for defined networking so for defined storage all these concepts are pretty new for a storage admin we don't want anything else than just net app so that's why I think these projects are really different it's a whole new level of complexity and also it's also coming from community it's not you didn't develop this right and you could go down the community road but I'm going into a redhead commercial area because you didn't develop it you're taking it and deploying it so yeah, that's the problem the question that I have is when you build the cloud do you put restrictions to the the cloud team there are teams, squads in the cloud team and there are experts who can fix the problems but how do you control as you build the cloud right from the beginning to enforce how a real cloud should work so the squads will get experience during the building and deploying of the cloud before it even goes live the squads will get experience so we put control so that they put the control in such a way of I think you're on to something here because it does take some self discipline with all these wonderful features of OpenStack that just enable everything and say we will accept any workloads because cloud providers like AWS they also don't care about workloads but now you really have to look at your responsibility domains where you draw the line between cloud provider and cloud user as a cloud user so you have something to decide at the beginning when you look at your business requirements look at your use cases who are my customers and what are the boundaries of what I accept so that's part of the responsibility domains and it does require a lot of discipline and maybe it requires you adjusting your project parameters if it turns out that a big stakeholder has a change in their project en en he's one of the main suppliers for your budget that means that you may have to rethink what kind of workloads you accept and it's also a bit of a commercial for the MVP approach with iterations working towards a new thing because in a big academic approach you would have to go back to the drawing board reset your boundaries and redesign the whole thing and now you can say to this customer internal customer we recognize that this new workload was not originally designed to be on this but we can design a new iteration especially for you where we can adjust our cloud platform and we can give you a date so we'll start this work and then we'll invite you to the table to reset the balance for the responsibility domains and come to a new better solution for the company so you see the further we go into these styles the complexity increases because identifying core elements of your business is one thing and then add time to it and so this will all become clear when we do use case prioritization and the roadmap so you see we have some some props here there are already some post-its mega size thanks to Romain thank you Romain and this material is normally what we use so as you can see here we have the room this was actually in Switzerland maybe we have everyone or maybe you can explain it because actually I am the fat guy in the white t-shirt so ja, when we do it are you familiar with user stories by your hand please yes that's good, that's more than half yeah more than half is impressive so when we do it because use cases sometimes are very fluffy so it's better to use user stories because for a human being it's easier to expose a requirement or a user story as me as the user me as Alberto I want to authenticate against held up so we start to map these user stories in these fancy post-its on the wall we start to categorize them in columns like authentication virtualization storage and at some point we have a clear view of what your users are going to do in your system isn't it is that clear the end result and at some point the product owner or the main architect or the people that is doing the authority of the system is going to decide what is the first release what's in the second release and what's in the third release what is so-called roadmap because you have all the stuff that you want in your system authentication for me is a priority to get it authenticated with held up I don't need federation so for the next release I'm the same with the rest of the categories does it look fancy isn't it and it's an easy how to say natural and organic way of working in this complex concepts imagine that you try to map all of this just talking in a meeting you can do it but it's not going to be as clear as this because human beings are more used to see and try to get the stuff tangible isn't it in our experience I think this is a very active way to get this information and it also enables people to get off their chairs and to fiddle about with the information a bit and you'll actually get some really good results so it's not only collecting the information and storing it on the wall but you also have very active involvement from people that are in there there are some risks in doing this because we've been with customers where they say we need this we need this so we need to have also a very decisive and authoritative product owner to actually say this is something relevant or this is something that is a really good idea but may not fit with our business goals and also this methodology it has and how to say it it's fun so the people enjoys to be part of it so I've seen the guy that has been quiet for three days in the room when you start doing this he starts to collaborate this is awesome because you get the involvement of everybody dus wat doen we? ja dit is ook heel interessant dus we hebben de project-outline is klaar nu dus we hebben de post-its we hebben de timelines gezet we weten wat we doen we weten waarom we doen en nu komt de Greenfield approach dat turned out to be the brownfield stinky dus hier is waar taken inventory of all these brownfield elements this could be technical the hardware is already ordered this is what you have to work with or we have a hardware contract and these are the models that come with it or you have some security things that you need to that you need to take care of but they could also be business a long term business a long term view on how the business is doing is the budget realistic or how are you with manpower really have a good look at it because people get enthusiastic say I can do it, I want to do it we see a lot of companies building a virtual team people that do this along the side so you have part-time storage start part-time database people helping out really see the limitation in manpower no tool optimistic because it will bite you in places you won't expect and the same with process software certification we see it in a lot of companies this does take a lot of time isn't it over at all so we see sometimes it weeks, sometimes it months just people and it's not only the process it's sometimes just the people not being available to accept the request and follow up on it I'm sure there are many people this is the time where you can release some of this energy and frustration that comes with it so if anyone wants to chip in on this one I also understand that you don't want to a bit of the dirty laundry I can ask you can you give me a technical constraint that you have in your company a technical constraint pure technical so on the detail of let's say an OS OS version is I've worked with the company that said I know you have some newer versions of your real enterprise linux we want to work with rel 7 but rel 6 is the only certified version that we currently have so then you need to take into account the time it takes to certify the whole OS so do you think that is much better what do you think that is better we had an earlier release a previous release and deploy now with rel 6 and upgrade when you have your new rel 7 certified or do you think that the best way is use part of the budget of the project to get certify the new release of the operating system in a particular case of the OS and then for instance as a base for your cloud deployment your rel OSP or your open stack platform is going to be into the redhead release so there is no real way around it so you either ask for an exception to this rule or you probably need to take into consideration that you need to build it in an isolated environment for the time being or maybe for a long term or that you go into the process and delay the project for as long as the certification takes it is clear that we have to include this step in the project definitely ok but let's turn it around can you name something in the process category the process category so security is my my preferred topic so my company is a bank we need to pass certain regulations and in order to be compliant with these regulations I will share your design with me and it will take one month for me to be with your design I will provide feedback that I can assure you that nobody has passed this this review all good so there will be something that you have to change and after that once you have deployed this in production I will make sure that what you promise is there is secure penetration testing that is pretty good but this is exposed during a discovery session and what happens if your stakeholder at the discovery session says these regulations they will come later what will you do then what will happen is that the company cannot go to production with something that cannot pass the regulation for instance I can give you an example in Spain the banks has to pass this test from the national bank so you cannot go to production with something that cannot pass the regulation of the Spanish bank so you will be delayed in the project and the problem is the delay the delay you include in the project when some including this team in earlier stages during the discovery session is lower than the one when you want to onboard them at the end of the project when you have a need you are trained to gather the request to make the request for the resources and the guys are not going to be there because they are not available just for you they work for the company so you will have to wait for the resources to be able to be onboarded in the project so doing things in a rush is never the right thing to do and I think this is also again a really good argument why you need a project manager at this stage of the game they need to be enforced and otherwise you will be in trouble because this is not something that you want to put on the task list of your architect this is clearly something that is identified then record it and then enforce it you don't need to put your architect in charge of this last step what is the outcome of this what do you see now we combine everything so it's not the last is it the last what do you think is the last one, the last step I'm excited so I told you from the south of Spain I can speak all the time so guys if you don't want to speak okay I will do it so now we are going to design something we have all the information we know the context we know why you want to do this we know your business drivers we know the timelines we know the user stories we have priorities, we have the pro map so we can start designing the thing now is when we can go to a whiteboard and start drawing boxes don't go to technical because do you remember the risks you go to technical too early I know I have to integrate let's put service now don't write down all the technical thing how you integrate this will come back later during the design phase is it clear so far do you agree how do you do it in your company how do you do the first draft van je architectuur, wanneer het gaat om de ploegopsteek. Iedereen? Ik wil de informatie weten wat je hebt als je de draught draagt. Heb je al deze informatie? Heb je iets gevoelens? Doe je dat dit design een balit is? Of moet je er naartoe een nieuwe bedrijf op de vliegtuig neemt? Ja, dames en heren. Dank je. Oh, ja. Je hoeft te itereren elke keer. Want de bedrijf van de bedrijf zal veranderen. Maar denk je dat het is omdat de bedrijf veranderd is? En je hebt nieuwe gebruikers. En je moet de hele proces veranderen. Dus je moet de bedrijven veranderen. Designen based op de nieuwe bedrijven. Maar denk je dat wanneer je de eerste draught veranderd is of wanneer je de design fase veranderd is? Heb je al deze informatie? Al? De dinelijn? Mijn bedrijf? De bedrijven? Alles? Al? Niet de eerste? Ja. Het kan veranderen. Oké. Dank je. Mijn ervaring is dat je nog steeds deze informatie during de design fase veranderd is. Dus wanneer je de periode hebt, wanneer je de rote map veranderd is, dan gaat iemand in de design fase veranderd en zei, kijk, ik was niet in de meet. Dus ik ga mijn nieuwe bedrijven introduceren. Dus, ja, dit. Oké. Maar op de periode van jou is het de realiteit of is het beter om te gaan met kleinere objecties en dan te maken groeien? Dus we doen... Ik denk dat het beter is om de bedrijven voor alle dingen en dan te beginnen te bouwen of te krijgen met kleinere marktstappen. Laten we dat zeggen. Definitief. Als elke straalhalder die in de project wordt ingevolgd moet worden ingevolgd voordat de project begint. Want anders gaan ze later op het bord. Maar zelfs als je niet gebouwd bent, zijn er objecties van het begin. Kijk, dat is waarom je een rote map hebt. Dat is correct. Dus deze mensen willen iets doen. Op een gegeven moment. Misschien is het niet de prioriteit voor het project, maar je moet weten dat ze iets willen doen. Omdat je niet de prioriteit kan creëren op basis van dat. Dus je is misinformatie. Wat we proberen te doen met de discovereringssession is een volledig misinformatie. Je begint met een rote map met alle verschillende departmenten en dan begint je te starten. Maar uiteindelijk betekent u... het is een interagio. Ja, oké, de idee is met deze hoge cloudprojects dat u in de eerste interagio niet wil zijn. Want u gaat failen. Of als u succes is, gaat u in 10 jaar succes. Want u weet niet hoe een ferrari is. Dus u moet leren hoe de ferrari creëert. Start builden die wielen en bla, bla, bla, bla. Dus het is beter als u iets builde die je prioriteit, dus je hoofdbusiness, wat is je prioriteit, wat wil je achten? Laten we voor het gaan. Want dit is iets wat u kan achten in een certaine tijd. En u kunt het estimeren wanneer u het gaat hebben. En u weet hoe het gaat. Laten we het doen. Dan ga ik u een sample met deze ferrari. Ik moet uit punt A naar punt B. Dus ik kan de ferrari chooseen. Ik kan de car chooseen. Bicycle gaat me naar punt B. Maar op een punt in de rote map, want ik ben een lazy guy, ik wil geen exercice. Op een punt in de rote map moet ik een engine op de bicycle gaan. Je weet wat ik betekent. En op een punt based op de periode en deze, meer of meer periode die je in de environment maakt, je krijgt meer visibiliteit, estabiliteit, de maturiteit van het product. Maar altijd focuss op iets dat kan worden. En dan koop je hoofdgebruik. Dat maakt veel voor u. Oké. Dank je. Nog iemand anders? Julio. Ik weet je. Ik ben Julio. Ik ben de equivalent Alberto in de U.S. Maar naar wat je zei, ik denk dat het belangrijkste van deze preparatie is dat je allebei op de zinbouw krijgt. Dat is echt belangrijk. Alle staatsbouwen zijn daar. En dan naar wat Alberto zei over bouwenbouwen. Je gaat niet om de antwoorden op alle bouwenbouwen tijdens de zesbouw. Want op deze zesbouw moet je kijken van het project van een project, het is als een kickoff van het project. Je krijgt allebei wat er moet gebeuren. En dan, het belangrijkste dat ik probeer te doen, of het project van het project van het project van het project. Het is wat je krijgt van het project van het project. Het is zoals Bart zegt een fantastische terminologie en het is hoe je een minimale bioproduct krijgt dat je kan itereren en je kan starten om gebruik cases door je proces te maken. Want ze laten een graf daar hoe we dit doen in Rehat en die is de fase 1. Phase 2 is je hebt de gebruik cases en dan ga je naar de design fase en dan ga je gebruik. Maar dat betekent niet dat, na de ontdekking, je moet een minimale architectuur hebben dat je kan gebruik dat je mensen van de operatie van de platformen beginnen te familiariseren. Zoals, je komt naar deze eventen en je zegt het is een goede technologie en je moet de technologie gebruiken. Je moet het begrijpen. Dus dat is waarom dit zo belangrijk is en je hebt een goede vraag over hoe je er gaat. Dank u. Dank u Julio. Ik ben heel blij dat we energie hebben tussen IMEA en North America. Dit is een goede punt. Dit is een goede punt. Dit is een bedrijf om dingen te doen. Dit guy is van North America en van Spanje. We doen de dingen in dezelfde manier want we weten dat het werkt. Ja, en we kunnen het hier als een open manier om dingen te doen. Dus de slijten zijn daar en het is niet echt hard om deze conversatie in je bedrijf te hebben. Dus je kunt hier een lied nemen. Heb je het nog gedaan? Ja. Dank u wel. Nu Julio zei dat we een project hebben gebouwd. We zijn in de ontdekking fase. Op een gegeven moment hadden we alles en estimeren de bestaan en zien hoeveel geld ik nodig heb om deze dingen te doen. Hoeveel mensen ik nodig heb en dit is waarom we de baklok hebben gecreëerd. Dit is niet de baklok. Dus, ik had het niet gezegd. Dus, oh, de link... Ja, dus. We hebben een mooie high-level architectuur. Dus je ziet dat we onze opeste controleren hebben. We hebben besloten dat we gaan integreren met een certaine CICD en identity provider is daar. Een automatische tool is daar te ontdekken enzovoorts. Hoe kan ik een project creëren van dit? Krijgen we het project baklok. Dus, volgende raken er zal een task in de baklok zijn die de integratie van de wordload CICD met OpenStack API's zijn. Hetzelfde gaat gebeuren met een automatische tool voor infrastructuur. Hetzelfde gaat gebeuren met de infrastructuur CICD enzovoorts. Op het einde van deze fase zal je een project baklok hebben die je gaat doen. Dus je weet hoeveel tijd en effort je moet ontdekken op een certaine task. Dus je kunt een manpower op een certaine task en dan kun je de project creëren en je weet hoe te planen deze project met de projectbatches. Does it make sense voor je? Heb je meer of minder iets zoals dit? Is dit eigenlijk hetzelfde wat we zien in Agile of het gebruikt van deze technologie's of meten Ja Dus je gebruikt project baklok? De officieel naam is product baklok Ik maak het modificatie Heb je het gebruikt? Is het gebruikt? En ook, ik vind dat project baklok ook gebruikt is voor basis van future iterations op. Dus eigenlijk, als je at some point draai je een lijn waar de current iterations is. Dan heb je de basis voor future iterations voor future improvements. Dat is goed. Ja. Dus, het helpt ook alle andere squads in de internele teams weten elke andere baklok en ze kunnen bekijken en dat is goed. Het maakt het visibel voor iedereen. Oké. Dus, ik moet dit doen, sorry. Dus, zoals ik zei, dit is een open manier waar je werkt. Het is een soort best praktisch maar we denken dat je met projecten moet beginnen en je kunt dit als individueel organisatie doen. Je kunt ook redhead komen en dit doen met je. Dan kan je een heel nauwelijke en geïnteresseerde architecten zoals ons en Julio in Noord-Amerika kunnen zien. En zoals we zien hier, er zijn twee modes in die we kunnen doen. In de Rijnbewoners en de reis-hetitie in deroom kunnen we in en deze topic ontdekken. Je zal meer ontdekken dan we opdrachten. Om te praten, te hebben alle steekhouders in de rijn gegeven met een technische architect of een projectmanager in dit geval is een heel goede idee. Het meest Wat je kunt doen, is dat je alle requirements en alles wat we gegaan hebben gedeelte in een trelleboort en een report. Of iets meer tangibles in GERA en je krijgt een hele projectdescription van het. Dit is wat we doen, dus gebruik cases, challenges, potential technologies and solutions. Meestal hebben we geïnviteerd om op het openstak te praten, maar dan vinden we dat er meer is om te coveren. Dit is wat we doen in de discover session. Het is een een-day-set-up. Soms doen we het met verschillende dagen en we gaan door de toppen die we hebben gezien in de tiles. We doen de discover session. Het is een-day of een halve-day, misschien twee dagen, op de complexiteit van de case. Normaal doen we wat we hebben geleerd in de discover session. We gebruiken dat in een design fase, waar we eigenlijk doorgaan. We maken een hoge leveldesign, mappen de requirements naar productabiliteit. We maken er zeker dat we het in de set timeline kunnen ontdekken. Deze zijn de solutionsprins. En op de discover fase of in de design fase kan dit een lange tijd nemen. Het kan een klein tijd nemen. Maar dit is heel erg based op de business driver en de constraints die we zien. Dit is dan voor de singeliteraties, maar we kunnen dit opgeven voor alle gebruik cases. Ik denk dat we op het einde van de talk zijn. Als er meer vragen zijn, dan zijn we opgemerkt. We hebben er een paar architecten in de ruimte, zoals Julio en ik. Als je in een 1-to-1-conversatie interesseert, ben je wel welkom om ons hier in de front te joinen. We hebben er een conversatie over of we een van de architecten in de ruimte kunnen zien. Je kunt naar de redhead booth gaan. Je kan het niet missen. Het is gewoon de eerste die je ziet in de marktplaats. Dat is true. Dus kijk naar ons om meer te weten over dit. En bedankt.