 Hello, okay, hey Yeah, hello and welcome to my talk. I hope everyone enjoyed the lunchtime so far and the interesting Talks that we hear today morning My name is Manuel Birke. I come from Daimler and I want to talk a little bit About what we experienced last year with Cloud Foundry I do not want to talk about the awesome technology I think everyone of us is aware of that Cloud Foundry is a very awesome technology but I do want to talk about if you decide to Use Cloud Foundry for your project. So what are the keys to success? To introduce this technology to your enterprise business Especially an enterprise You have some certain environment you have to face and There is a very special to deal with and if you are in an agile project, this is not always Without friction and so here are some of the the keys to success So that you can have a smooth and successful high-performance development process so we started last year Because we wanted to build a connected car product a connected car app for our customers and as we Always are interested of bringing up the newest technology to a luxury product for our customers We decided to go with like the state of the art technology stack and decided to use Cloud Foundry especially a political Cloud Foundry For our connected car product that we wanted to launch in Germany to the IAA So especially was that we have only six months for the development So we had a product in place already This was developed around like two years and was already very mature But now we wanted to bring this to the next level basically having a more delightful app and one key To achieve this is to change your development process to get early customer feedback To really bring the product to the next level is that everyone has a very delightful experience within our luxury products so our mission was to exactly build this app and To start with an MVP and iterate over it using a fast customer feedback and to release this on the IAA With a high quality that is basically Necessary if you want to bring a luxury product to our customers, they have a certain expectation So we cannot drop in quality. This was one of the requirements once we started with this project So if you look to now the symptoms in a complex system landscape So what do you exactly are facing if you want to do an agile project within your company, especially in an enterprise? You have a lot of specification driven development processes around you and they are very mature Right, they are already like 20 years old And we have a lot of legacy and systems that are using it and that's very mature and people get used to it so Usually you do like this writing a specification and someone will implement this after that you do like in the substance And everything is fine. You can release this now with that You have like scheduled driven development cycles This is also necessary because you are not alone inside an enterprise. You have a lot of small projects They are kind of interfacing to each other. You have a very complex system landscape They have different development roadmaps. So you need a kind of like a scheduled driven Deployment enterprise deployment plan so that you can do at the end an integration right and and This comes to this point of complex integration if you have a lot of systems are surrounding you The integration is not really trivial. It is more like complex because of Yeah, the distribution of the systems So you don't have like this one foundry where you can look into lockstash and say like okay Microservice a makes a problem. So I have to do something against this So I have 10 different systems they ideally feed everything into one like logging facility But this is not necessarily the case So the integration gets complex there then also because an Enterprise has a long history and we at Daimler as well. We have different software stacks and this is totally valid Because as we are all engineers, we want to choose the right technology for the right problem, right? So not necessarily cloud foundry will fit to all the problems They want to tackle so you will have different kinds of software stacks and you need to kind of manage so that they all work together and Cloud foundry will help here a little bit. I can I come to this point later on but this is where we are now and Then what's also very true is that that you want to maintain stability So last-minute refactoring is basically a no-go if you're an enterprise environment because at the end You need to deliver something for the customer and always not always but sometimes the mindset is there that Refactoring can cause more damage instead of doing good things to your code and Therefore, I think one key is to maintain stability here So if you see these sometimes and you want to go like agile or dynamic with cloud foundry and make a more disruptive Disruptive approach here. You need to like overcome some of these things. How do you do this? You need from my point of view for Elements to be successful in this kind of environment one element is you need to be dynamic So yourself you need to have a mindset that is very like I Don't really want to use the word agile or disruptive, but it's very dynamic So you need to see where are the pitfalls where are the blockers? How can I achieve to enable my team to work even? Yeah, more faster with the Lena development process. This is one thing the other thing and this comes with cloud foundry I think these days because not every one of the OEMs especially in automotive Has a lot of experience with these kinds of new technologies So you need to select a partner that is also be dynamic This is also from my point of view a very important thing because We in our automotive company we want to build vehicles, right? This is our business So if we can partner with people that basically their core business is to develop software Then we can learn a lot from them And so we can bring this back to our products and make our products even better because we can synthesize The knowledge that we have from the engineering point of view with the knowledge the partner has and and we This is a pivotal last year a partner has from the from a software development point of view and also we can adopt this and learn and try to basically Incubate this new process into our company to really Bring our development to the next level The third thing is your platform needs to be dynamic Of course if you have like a platform where the deployment takes five days You really cannot be dynamic or like a dry So you need something that supports that cloud foundry from my point of view is currently the best solution for exactly that element and Another thing is that your process need to be dynamic it now you can start off thinking about yeah I take the scrum process a or I take a v-model XP or whatever you need to decide whatever fits best to you and Again here the partner can help you because they have Experience and how you bring basically a dynamic process within a dynamic platform to your business So I don't want to talk about us or our partner. I think everyone knows the company is very well I want more talk about likes the platform in the process So if you talk about the platform so By side technology what is now important if you want to leverage cloud foundry One key focus area is the architecture if you go like in an agile project I heard a lot of Yeah, let us not think about architecture. Let us do it try it iterate over it and then we improve it To a certain extent this helps and this works But sometimes there is a downside here It is if you want to have like a sustainable architecture Then it's always not the smartest idea to just try to iterate to that right so with basically no No ideas what you want to do up front with no vision then this can end up in in a like in a dead end So what you want to do is especially if you have a complex system around you you want to basically embed your Architecture into that so you need to have like a short-term approach to iterate and to improve your business But you you should have like a midterm and long-term vision to where you want to go with this company This is this is platform basically The second thing is the integration as we already have seen in the first slide It's like integration can be complex because we have a set we have different systems We want to really interface to these systems. So we need to make sure that if we build something new that is agile can integrate With the landscape that is currently in the company. The next thing is open source I think these days there is a mindset outside That open source comes for free. I think we at Daimler thinking that open source is very necessary to Evolve products in a very quickly way and we are encouraged to use open source where we can we also recognize that it is important to have partners that Basically touch base with open source and create an evolution in these products as I said, we are not like Software engineering company we are we are building vehicles for us. That is important That the partner we are working with is basically incurred and in open source. So this is why I think all the big companies here in the valley that Incubation open source are going in the right direction Although I understand and I think this is very important if you use open source technology You have a responsibility to contribute if you don't do this Then you have basically a vendor lock. That's called open source, right because you cannot influence Where's this open source movements go to and then basically it can happen that Cloud Foundry goes to a way where we at Daimler cannot use it anymore and then our investment will be gone So this is why I think Contribution to open source is always necessary The next thing is like continuous integration Although it is necessary for your process to continuously integrate and Enable the developers to really fast go on the platform do a CF push, right? You need to do this on a really holistic way. So if you have interfacing systems, you need to kind of like Get them on board so that they basically at least Can support your agile integration process and also we what we did is like we shipped Justin an S class from a single thing to Palo Alto our development was Palo Alto And so we just parked it right next to the developers and said like okay If you want to have continuous integration one end is vehicle. The other one is the apps that you are doing So, please go ahead and do continuous integration. So what you need to do is enable the project that is basically adjoin to To make this continuous integration happen even though the system landscape you are in is complex So this is one of the key successor for us Um as we have no the platform in place and we know the key areas where we have to be a little bit more careful We also need the process, right? So We decided last year to go with the pivotal labs Guys and doing like a joint project and an enablement project. So this project was roughly six months and it was like divided in basically two parts one part was more the part of Getting everything started right thinking about what is the project we want to do? What is the MVP want to do and then they have this kind of like discovery and framing phase? We just see okay What is the delightful part? We want to bring and then the developers came back with the reality. This is the framing This is what you really want to do and we can do right because you have certain certain technology restrictions and after that phase we went into kind of like a iterative approach where we basically from iteration to iteration created use cases and got feedback back from from the customers and from from like user studies that we did and this feedback went directly into the into the use case and Also in this project was very special. It was like International over four time zones or four different Project groups are involved in that and so we did this kind of follow the Sun model I don't know. I don't know if everyone is familiar with that that means in Germany and some people are laughing here because they went They worked in this project for some of us. The Sun was never down, right? It started with in Germany and they had they got a new build they integrated this build against the vehicles and the whole fleet of vehicles and then at the end of their business day they basically Reported the errors back to us and then the next morning We started with a team on working on these errors fixing them Do a cf push? Deploying this and then next day people in Germany could continue on integrating that so and there you I think you see Really the value that the platform and the process brings you right? So we have the opportunity to to work with good people that are familiar How to deal in this agile environment and you have the platform that supports that and you need both, right? So What is now the key focus if you want to sustain this right because we did this Now dies we are living this we are not living this in like a five months cycles. We are living this now in two months cycles So we could improve this over the time. So but what does it take? To come to this point. So in this picture you see like you are dynamic But your world is not dynamic around you. So you need to kind of like influence inject them somehow, right? so you do this By ensuring that your organization will adapt to a new process and see the value in it So we have seen that we have heard this in the talks in this morning, especially here in this room Transparency is here a very very important thing So you need to make sure that everyone understands what is your mission? What is the value of the mission and how can they participate in that? So we did this and it was a very very well seen Approach and people liked it and try to adopt this and Try to work with us in this model The next thing because what you cannot do is you cannot say like I did I do an agile project and everyone now needs to Follow me this will not happen, especially not if you have like very complex systems around you So we are talking about like 40 to 50 different systems with different release plans So they will not adopt what you have in mind, right? So you need to align to this enterprise development plan and here's I think the takeaway that is very important You need to have like a hybrid approach You need to be like agile and you need to have your sprints and be like very Continuously, but you also and this is a Especially also true for the architecture, right? You need to have like a mid-term and a long-term vision how you can interface To different other processes in your company to different other development plans and This is basically the last the last key here. It's Make sure that you can kind of decouple your process from the world around you so that you are not depending on on Development cycles that maybe are not Basically synchronizing you so what you want is like Doing your development and doing it in your own way But also contribute in the bigger system and this is why interfacing is a very important Take away here. So we did this with like kind of integration parties. This was not really big bang We heard this already in the morning You are better if you do like feature toggling So you're you're enabling disabling certain features you can Evolution your code you can deploy your code at at the end You can just enable disabling certain features and this is all also a good Strategy if you don't want to have like a big bang integration You want to smoothly integrate with the other systems and give them the time to attach to your software as well So if you have no the process and we have no the platform One would say everything is fine or go ahead. We are successful, but we aren't We are only then successful if you really live this development process and With lifts the developments pros and I really mean Be part of the team So one thing you should not do is like okay Yeah, I grabbed now some guys like pivotal for example with labs I have like 20 developers sitting there aside. They will do the show and everything is fine This will not work especially in a complex environment You need to like really bring the subject matter experts into the team So that the developers can interface with the engineers and with the integration into engineers for example And this is also very Important because you want to take away the knowledge in this project, right? So you want to sustain this somehow The next thing is like pair together So I'm not sure if everyone is doing this practice because per programming Someone would say it is not very sufficient or efficient or it's like expensive from my point of view is absolutely necessary So if you don't pair you will lose a lot of opportunity and you will lose a lot of knowledge transfer that really will reduce your bus count so Pairing together from my point of view and I'm already since a couple of years in the industry developing in from rational unified process to be modeled to XP everything pairing I think it's a key element for success here and Also, you need to Bring a certain mindset into the team. So you need to have some mindset of lose and win together So every time something went wrong The team was responsible for fixing that they fixed it overnight and the next time everything was happy because the software was correct and So you need to motivate This team culture and you do this automatically if you are part of the team, right? the next thing is more like from a from a Refactoring and co-development point of view. You'll need to treat change as a chance as a chance to Make your code quality better as a chance to fixing bugs before they arise, right? also this goes hand-in-hand with That you have to see bug fixes as improvement or it can happen that people may blame you because you have too many bugs in In a software, but you should get to the mindset of I need to fix it because I want to increase the quality I want to increase the user experience. I want to ship a product that basically Fulfills the quality requirements that I want to bring to my customer and We did this so the team worked very hard on fixing bugs and bringing the highest quality that led to Almost no complaints from the customer side. So I'm very happy about that and And the next thing is do not fear transparency and I already Motivated this quite a few times I think if you go with a different project and a different process to a to an enterprise company You need to make it transparent what you are doing and then this brings the value for the company because they will see how How good this approach is and how you can improve basically your product development process with that so we accomplished this mission by launching on the IAA this is like the IAA booth from Mercedes me and So I'm very happy about this and At this point a big thing Thanks to all that worked on the team, especially the labs team also the team in Germany and The team in London and in Canada And that's basically my last slide so you have here an impression of The product itself and the s-class we shipped to Palo Alto We also had like I watch support for example. It was like very fancy upcoming new technology so I'm very happy about this project and Can can say that this was a absolutely success that brought a new agile project and process to to Daimler and that really Brought our product to the next level of quality for our customers So thank you for that Any questions? Please come to the mic. Yeah So we have a similar setup than the guys from That I think it was like digital globe so we have like a staging of voiment We have we have Jenkins Continuous integration and so what we are doing is like we have a very restrictive System landscape so so we have like also a development machine. We have a test machine integration acceptance q released and then we have like several cloud foundry instances where we have to go through until we release it at the end and Continuous integration is really here is success because we have different vehicles driving on different environments They are not necessarily all on one environment and so with the one click deployment We can really flush the code on every environment and just go out It's like a try it on on the different kinds of environment and they have a different way to stability, right? So in an integration environment usually you have a full-blown system going on and on our test environment Maybe you're isolated a little bit more so you can identify bugs Continuous integration from my point of view is absolutely necessary if you want to be in a like a Staged enterprise environment Otherwise, maybe it's not so necessary because you can just do a cf push if you are like in a startup a small system it's fine, but if you're an enterprise you need this and Our our back end that we developed before last year. They did not had to have continuous Deployment so we could reduce our deployment time to 25% So this was really an improvement on the other side please Yeah So basically the question is do you want to have an app for a purpose or do you want only one app, right? It's interesting because I think the big players went to this already quite a few times So you have like one Google app and then you have 10 Google apps and then you have one Google app and so on so my personal point of view is that sometimes it makes sense to have separate apps because Is we have maybe different security restrictions, right? For example our new e-class that is out there has like a Parkman app so you can park autonomously Such an app has different security restrictions for example than an app that makes like Commercial advertisements right so and what you want is like you you want your development process to be like Not interfering each other right so because on a like an app where you can autonomously park your vehicle You have another quality restriction that you might not have on the other app So the process is a very different process and this is why at this point If it comes to this application it makes sense to divide this into two apps And then you need to find a balance to always make this delightful, right? So if a customer so and this is why it's important to have customers, right? So you ask your customer do you want one app? Do you want two apps or three apps and and then at the end you convert to a solution that is suitable And this can be very different for every for every business right for us Maybe it is good to have like a connected car app where you can you like open and close your doors Or maybe like see what is the state of charge and also have like a dedicated app for advertising For example, but there might be a company out there that would say no we only want one app The key point here is how can Cloud Foundry support this right and I think with the microservice architecture You are you have already a foundation where you are free to choose whatever you want right because at the end Is this can change over time because now the trend is you know Let us do a app for purpose and in five years or in three years You can be no let us do one app because I don't want to start ten apps, right? And this is why I think it's more important to talk about the back end part and if you do this, right? You don't even care if it's one app or tenets Right That is also an interesting question so in retrospect if I would say our business improved Because we could bring functionality Faster to market so the awareness of our customers is and this is totally true because we are innovating our products very heavily right and That we can do even more for our customers, right? So and I would say bottom line that our business and the awareness of our business changed dramatically from maybe a Very sustained development process to a very modern and agile Development process and I think this is also good to take away for customers here So question is here What is our impression about the bug fixes right and is it is it only an improvement and what why we're thinking before we went through this process I think this is a very general general Question and I can really ask answer this general for myself Bug fixes are always good The bugs are good because you can identify problems in your code, right? For a customer, maybe this is not good because the customer is complaining Because something is not working. So you better fix the bugs before you go to production. This is one thing The other thing to have to to make this to support this you need to have a very good queue For your application So what we did is we improved our software quality by having a dedicated queue Team at pivotal apps and we also had a dedicated queue team in Germany looking through the software really using it with different vehicles and Sometimes people will not maybe recognize that the bug is good but I think it is our responsibility as an engineer to really facilitate and and And makes a transparency That bug fixes are good and at the end I would say This is also a process for every company to move forward in the modern software agile development You will see more bugs. That is true because you're developing faster But you can also improve a lot more right because you have shorter development cycles And this brings you with continuous integration into a position where you easily can fix bugs right last question So So the question was basically how did we manage the continuous delivery, right? So and so we had like a two-step approach The first approach was that we have a fully automated continuous deployment process up to The environment where we did like the final acceptance and after that we needed to align and this was also Important to all the other processes When we bring this to market So this was a manual process and this is also necessary because think about if you want to go to a market You need to have much more than just rolling out the software You need to have like advertisements. You need to have like Learnings for the for the people that sell maybe the product So it was more like a holistic approach here And so we need to make sure if you want to go to a certain market that everything that surrounds the app Also gets covered and this is why we really couldn't Get in an automatic fashion to the market. We need to like kind of like Plans us out. So we had like continuous integration delivery until cure substance and then we had like the last mile basically manual Okay So if someone has any questions you can free and grab me afterwards. Thank you for your time. I appreciate it