 All right, I guess we should be getting started. So welcome, everyone. This is the last session during this conference. But I'll try to make sure that it is not the least. So my name is Romance Foshovski, and I'm head of Cloud R&D at GrapeUp. And today I will give one more testimony about how Cloud Foundry allowed one of our customers to get back on the right track, on the right path, in the wilderness of software delivery. The software is eating the world. We have heard that many, many times. And we know that companies need to change. We know they need to adapt to the pace of a changing world. And eventually, every company needs to become software-driven to be able to not to be excluded from that world. They need to become software-driven to be able to still play a role in their markets, in their industries, to be able to compete with their disruptors. So what they need is the ability to deliver software products at a speed expected by their customers so that the customer can get what they want and when they want before actually they leave and go to the competitor. And I think this sentence is actually the shortest definition of the DevOps philosophy that should drive the digital transformation of our organization. We know that disruptors are everywhere, in multiple industries, in media, telco, finance, banking, automotive, insurance, and so on. So they move fast. And enterprises, on the other hand side, they need this velocity of a startup. They need elasticity of a startup to be able to compete with them. But can an IT company be disrupted? A software company, can it be disrupted? And today, I will tell you a story about an IT company, a software company that had to change, an old IT company with a history, with over half a century of history. For many, many years, they have been a leader in their industry. They've been building multiple products, visionary products. They were leading the industry and other were their followers. And one of their very successful products was a CPQ solution. They have sold multiple companies around the world. But even though they were a leader, somehow on their way to building great products, they have missed the cloud moment. They have missed the moment of when they need to introduce certain changes in order to be able to compete with others. And their competition has already migrated to cloud. Whereas they have not, and they were left behind. So that was their challenge. They lacked the knowledge about how to do that. And this lack of cloud readiness really diminished their leader position. So when they engaged us, they knew they had to do that. They knew they had to go cloud. But the challenge was, well, first of all, how to do that and also how to do that quickly, because all the others has already done that. They had customers requesting certain features. They could not respond to quickly enough. And they had to act quickly. So of course, they tried internally. They did some POCs. They tried Azure Cloud. They do a lot of internal trials. But all that was not enough for them to really get to the next level and then make a big step forward. And in all those internal trials, they also seemed to miss one important thing, that to transform, because they really had to transform, is not just about adopting cloud. It's not just about the technology. To be able to truly benefit from the cloud, you really need to change your mode of operations first. And to transform means a lot more than just the technology. They had to learn. They had to learn a lot. They had to change their mindset. They had to set up a new working environment. They had to modernize the infrastructure. So this is the part where the technology comes in. But they also had to implement and change their methodology and the way they work, the way they delivered software. And eventually, the combination of all those elements allowed them to deliver this competitive product that they were able to compete with against their other vendors, other competitors. And we have helped them to go through all those steps. And let me give you some further insights on how we did that. So we started from the basics. We wanted to make sure that, first of all, we're talking the very same language, that we understand certain concepts in the equal way. Because it's difficult to explain certain things if we do not understand certain terms the same way. It's like trying to explain a virtual machine to someone who doesn't know what an operating system is, what a computer is. It's quite difficult. So we wanted to get a common baseline on understanding objectives, what are the goals, but also what is DevOps, what it brings with it, what is needed to be able to implement this approach, what is cloud native, and many, many things around that. So what we did is actually we prepared an intensive crush course, sort of a workshop, two weeks workshop, with a customer team. And we have explained all those things. We discussed all those things, DevOps, agile methodologies, XP, continuous integration, continuous delivery, just giving them an overview, of course, because it was not just a complete training after two weeks, so that they understand those concepts. And we have just laid down a baseline that we could build further on. But one of the important elements that we have done during this workshop was also defining goals. So what are your goals as an organization? What do you really want to achieve? And they said, well, we want to become Cloud First Company. We want to get back this position of a leader in our industry. We want to have a competitive product, which that will allow us to regain that leader position. We want to be able to use a SAS model. We want to be agile. We want to improve our velocity when it comes to releasing software, to delivering software, delivering change to our customers. And we want to be able to react faster to what's happening on the market, to respond quickly to all those requests we are hearing from the market. Another thing we have defined jointly were, OK, but are you aware of certain risks that are on the way? Because it's very good that you know what you want to do, but there are definitely certain obstacles on the way. So you want to learn? Great. But be aware that this will be difficult. So you cannot lose the will to learn, because it will not be weeks. It won't be months. It will take you a longer period of time to be able to really implement those changes. Old habits, waterfall-ish style of working, this is a great risk. Because, again, you will not be able to change the whole organization at once. You will start at one place, but be aware that there is a risk of the waterfall of old habits just flooding your new spark that you're trying to ignite. Silo's, of course, same thing. And lack of empowerment, because this spark has to have a power to be able to really grow into a bigger flame and then spread around the whole organization. So we have also discussed those risks and made them aware that it won't be that simple. One more thing we have done, we have formed, defined. So what can be the transformation team? What can be how this spark, this initial spark, can look like? We have actually created or defined two teams, created jointly from our engineers, our representatives, from GrapeUp, and representatives from the customer. So platform team, which was designed or thought of to be working on the platform part. And, of course, the product team, focusing on developing this new version of their flagship product. So the second part was actually the technology, building the platform as a baseline of the foundation for the product. And like I said before, and that's what we made aware, the customer aware of, you cannot just base your transformation on the technology, but, of course, it is a very crucial part. It is the essential element, because this is the enabler. It's like in a race, where when you have a great car, but you do not have all the rest around that, like mechanics, the team, garage, correct preparations, communications that the driver can communicate with the team, and so on, you won't be able to win the race. But on the other hand side, if you don't have the car, you cannot even start the race. So technology is the essential element that technology is essential part here. And the customer needed to build the technology, needed to build a new infrastructure for the new SAS model they wanted to follow. Again, we have went through, let's say, introductory session with them, trying to define goals. So what do you want your platform to do? Of course, it needs to be scalable, needs to be reliable, needs to be secure. We want to be, we don't want vendor lock-in, so we want to be infrastructure independent. We want it to be automated as much as possible when it makes sense, use infrastructure as code, use continuous operations, continuous deployment, and so on. Of course, many of those things were new to them, so it was not easy to implement that. Yet, these were the goals they wanted to achieve. And when it comes to technology, this is actually quite complex, especially in the cloud-native landscape. Because how to choose the right tools? There is a dosilience of tools out there. And how to choose, how to pick the right ones? How to make sure that your car is really prepared for the race? This landscape is huge, it's big. You probably know that one, right? And it's actually quite old, because it says version 2.0. I think it's like a few months old. Right now it's even more there. And actually, this compilation shows only the most popular technologies out there, not all of them. So again, they were just scratching their heads and, well, how can you handle that? How we can navigate this landscape? What tool should we pick? Again, this is where we were able to help them and narrow down this set of tools to a collection of tools and technologies that they should use to achieve those goals. We have defined in the very beginning. We have also prepared a concept of their platform, how it should look like. And it's no brainer here, because this is something that probably a lot of companies, a lot of teams have seen a lot. We have version control. We have continuous integration, eventually continuous deployment pipeline. We have a platform where we deploy applications. We have some automation layer that provisions infrastructure, handles the deployments. We have telemetry. We have backing data services that applications can connect to. So it is not really a rocket science, I would say. But for that company, it was difficult, because they had to change from the old world where this was not common to a new world where this is common. So how did we do that? We have went through a platform dojo phase with them. And dojo format means that we have built the thing together with them using XP, using agile XP deliver process, using pair programming where our engineers were working together with their engineers, building the very platform concept using those technologies we have selected. And we have did it in two parts. So first part, four weeks, we were setting up the very basic installation of Cloud Foundry, all the tools around that, basic implementation of concourse pipelines, making sure that we have the skeleton, let's say. And the second part, which lasted eight weeks, that was further productionizing the whole setup, making sure that it's secured, hardened, prepared for larger scale, let's say. But in both phases, the major goal was to teach the customer's team as much as possible to transfer this knowledge. That's why we have chosen to use pair programming. Because this is a very effective way of transferring knowledge from the one that has the knowledge to the one that doesn't have the knowledge. And it's really on the job training. So we are doing things together. And that's just theorizing on certain things but doing that in practice. And as a result of that, we have converted this concept of a platform into the actual implementation of the platform. We had a part called the fortress, which was the operational, centralized operational part that was used to actually deploy environments, multiple environments where each environment reflected one stage in the software delivery lifecycle. At the moment, they have two environments, DEF environment and test environment. In each one, they have Cloud Foundry setup managed by Bosch, together with concourse used to deploy applications to the Cloud Foundry platform. They have a set of backing services deployed also with Bosch next to it. And all that is sitting on top of Azure Cloud. The decision about choosing the infrastructure provider was actually not our recommendation. It was more of a business decision because, well, they were previously a dotnet shop. Well, they still are a dotnet shop in a large part, not entirely but in a large part. And their product is actually quite tightly integrated with a Microsoft CRM solution. So it was quite natural decision for them to use Azure for that because they also wanted to leverage certain Office 365 capabilities and integrations. So that's why we have picked, eventually, Azure to deploy the whole thing. And what were the outcomes of that part? Well, first of all, we have built a platform foundation. We have teach them the new methodology to use, to work with, and we have planted some DevOps seeds. And you have to be aware that those were just 12 weeks. So it was not enough time to really build a fully production ready setup. But that was not the goal. The goal here was for the platform team to understand those new technologies, to learn those new technologies, and to build a baseline they can further improve and work. But of course, this was just preparing the car for the race. And now the race is about the product because that was their goal. We have the old product. We need to bring it to the new world, to bring it to the next level to the cloud version of that product. And again, the same exercise. So what are your goals regarding the product? We want it to be offered in a SaaS model. We want it to be easy to sell, easy to use, easy to maintain. Perfect product. Of course, zero downtime. We want it to be high quality. We want it to be secure because, well, it handles certain sensitive data from our customers. So all those things were very important to them. And again, these are not some very specific requirements, I would say, because we could apply the same goals to almost every other product, software product out there. They should be secure. They should be of high quality, no maintenance windows, and so on. But the difficult part was how to do that in a cloud world because this is the world we do not know. And especially that we are coming from the old world where their previous version of the product was deployed on prem. It was based on few monoliths built with ASP.NET, integrated with MSSQL server. They also had some desktop.NET apps. So altogether, the implementation or deployment of that product with a new customer was always in nightmare because they had to go on site, set up an infrastructure, deploy the thing, deploy IS application server, deploy those applications there, and make sure that it is integrated with the rest of the infrastructure, and so on. So what they were actually ending up with were multiple custom versions of the same product and maintenance of those custom implementations were quite difficult. And where they wanted to get to was, well, something quite different. We want a SAS model. We want to be able to deliver those changes to all customers at once. We want to be able to onboard a new customer. We want to just create a new tenant in our offering. So they had to not only adopt new technologies but also reorganize and refactor the way the products build using microservices, using .NET Core, using some external services like Octa for Authentication, multiple database solutions, depending on what microservice needs what. Service discovery queues. They also wanted to split the front end part from the back end part using Vue.js. And again, we have done that together with them in a few phases, in a few steps. First, the application dojo that our engineers were, again, working in pairs using XP with their engineers, building the foundations of the product where the goal was to learn how to use those cloud-native technologies and build certain skeletons of the application. Once that was finished, we have moved to the second phase where we wanted to build a product demo for the conference. They wanted to attend. And that was a huge success for them because when they show the new version of their product during the conference, well, they have seen a great interest from customers and will demand for, OK, so when can we try that? Where can we really start using that product? Which led them to the last phase, building the MVP for the product. And this is actually the phase that we are still in. It was planned for six months. We are still helping them to finalize the MVP. And they wanted to launch it soon. And what is important then throughout all those phases, again, we were trying to transfer as much knowledge about this new approach, those new technologies as possible to them so that, eventually, they are self-sufficient. Because that was also a goal of the whole engagement. We don't know how to do those things. So you guys from Grape can help us. But eventually, of course, we want to regain our leader position and be self-sufficient again. Right now, like I said, they are finalizing the MVP. Soon they will be launching their very first version of the cloud solution. But there were certain problems on the way. And as you can see here, all those problems or examples of problems are related to people. They are not really related to technology. The technology part can be always figured out. It's complex, of course, picking the right thing, setting it up, making sure it works. But eventually, it can be always done. Whereas the approach of people to change their mindset, change their approach, and accepting those different ways of working, this is really tricky. So for instance, their engineers were not really happy about pairing, especially initially, when they did not see what's the value in that. Why should we do that? But after some time, they really started to notice that, OK, so we are far more effective doing so. And it is far better than just going to a training session, listening for someone, talking for three hours about, I don't know, Cloud Foundry or something else. And it's way better to just do that, together with that person. This water-fellish way of working, like I said, it was just a small spark within the organization. And around that, well, there are still all thinking, all the ways of working. So it was quite dangerous. However, they really managed to overcome that as well. So they did not let those other elements, well, those other departments or teams, to really flood the spark. And eventually, the result for them was, yeah, they were cloud-enabled. They have learned how to use those technologies, how to use those new methodologies. They have built a new infrastructure. They were able to enhance their delivery process. Right now, they have two environments, the deaf environment and the test environment. Each one is running three Diego cells. Both test and deaf environments are running in one AZ. But for the upcoming production launch, they're creating a third environment where there will be three availability zones. In total, there is about 120 VMs. So it's not really a big setup. But this is just the very first step for them. And they also have the infrastructure. They also have the capacity right now to be able to release much more frequently because they do have Conqueror's Pipelines, both for managing the whole platform and also for deploying new versions of their applications. They are working using the new methodology, the XP approach, the Lean Startup approach, where they are iteratively improving their product. And they are prepared to release every week after every iteration. Of course, they're not in production yet. But they do have the infrastructure to do so. Right now, they've been able to break down the initial monolith into microservices. They're running 39 applications in total in both environments. So they have also improved the way this whole product was organized. What are the next steps? Because the journey is not finished. The journey is still continuous. Well, they are very happy about what's happened with this particular software. They have seen a lot of value and a lot of improvement in how they can deliver the software in a SaaS model and also in the cloud world. So they would like to scale it up and broadcast that to other teams in their organization. They're thinking about migrating another product of theirs, to also refactor that, to also migrate it to the Cloud Foundry platform, engage other teams so that they can really also benefit from this new way of working and see the actual benefits and how they can improve their software-deliver process. So I would like to sum it up by saying that it is essential to leverage technology to succeed in a cloud-native journey, just like our customer data. But it is important to understand and remember that technology is just the enabler and not the most important element. And this is actually a very common mistake or approach that a lot of companies are taking. They're focusing on the technology and they think, well, if I set up this Kubernetes cluster in-house and I start using containers, I'm good to go. Yeah, well, maybe to some extent, but it's not everything. If you really want to benefit from those technologies, you need to change a bit more. And this is the tricky part. And another thing is that you should not focus just on that technology because it is the enabler for you to really build the business value and you should focus on what creates this business value for your particular business. In their case, it was the product. They had to build a platform, they had to build infrastructure, cloud infrastructure to be able to build a new version of the product that eventually allowed them to regain their leader position. And the company should always focus on what really creates this business value. So with that, I would like to thank you for your attention. If there are any questions, I'll be happy to answer them. So I would say that this company had over half a century of history. And I think that they just were thinking, OK, we had this great heritage. We were leaders, we were always leaders. And they just missed this moment in time where this heritage was not enough. And of course, they also needed some, let's say, motivation or initiative from downwards that really allowed them to understand, OK, so maybe we should really do something. And actually, in their case, I can say that they really did their homework because they managed to spread the world themselves internally. They just lacked the knowledge how to do that. But they were aware about, OK, we have to change. And they were able to push that message up. And I think that's why they were successful in that. So the part that we're working with were around 20 to 30 people. That was, let's say, the core team that was involved in the whole transformation or starting the transformation part. But of course, the whole organization is way bigger. And so it is not a 20k people organization. But yeah, right now, they still need to make the next step. So from those 20 people, they need to scale it up to, well, probably a few hundred. Yes, they were trying to do the latter. So they also noticed that, well, we have to make changes in many, many places. So they were also, when adopting those new ways of working, they had to make certain moves internally, meaning that, OK, if we see that that person is not really suitable, let's say, for the new approach, for the new way of working. Unfortunately, they had to replace them as well. So these were difficult decisions. They always are. But yeah, they did that as well. So they wanted to pull in new talent, new skills, especially around those new technologies that they were not familiar with or not so comfortable with. Yeah, so in the product team, they had their product owner plus their developers, software engineers. From our side, we have added our software engineers plus an architect that helped them to design a new version of their product. And we started with that team. But eventually, as we moved on, we noticed that their product owner needs some help, especially when it comes to back leg management, to adopting all those techniques related to XP. So we added the PO coach that helped them to really better understand and to use those techniques more efficiently. Yes. Yeah, well, in this case, it was very helpful for them also to learn those new approaches on a PO level. Yeah, but we also seen many cases with other customers that when they want to start leveraging agile, there is somewhere this agile coach or PO coach, different names. So someone that really oversees or supervises, do you use the process how you should be? All right, so if there are no more questions, thank you very much for your attention. Thank you.