 Next up is one of that I'm really excited about. We have the Allianz team here to talk about the mobile app that they've developed, which honestly is nice looking, as well as effective and efficient. So we have coming up on stage Sarah Helt, Simon Neuser, and Dennis Kostich. They're going to talk about Allianz and the applications. Hello. Good morning, everybody. Thank you for having us. Our talk is about the use of Cloud Foundry in an industry that sometimes has the reputation of being a bit boring, insurance. But hopefully, at the end of our talk, all of you will think differently about that. But first things first, let's introduce ourselves. Hi, I'm Dennis, the designer and the team. Hi, my name is Simon, and I'm one of the developers. And I'm Sarah. I work as a product owner. And as you might have guessed, we all work for Allianz. Allianz is one of the world's largest insurance companies. In Germany, we have 29,000 employees and over 20 million customers. Whoa, 20 million customers? That's quite a lot. Have you ever thought about what keeps all the systems powered? What kind of IT systems does an insurance company have? We do have quite a lot. And to serve those 20 million customers, we do have a mobile app. This app's name is Minor Allianz, which translates to My Allianz in English. The app targets our existing customers. Our customers can check out their contracts, can get in touch with their personal agent, and also send messages to their agent via a secure channel. Some of you might think now, so yeah, a lot of big companies do have mobile apps. Small companies do have mobile apps. So why is this product special for Allianz? May I ask you, who works for a company with more than 1,000 employees in this room? A lot of hands go up. So I think some of you have heard about these things or experienced them in their daily life. Whenever a big company wants to launch a new product, they're like a zillion requirements. You have to fill in thousands of documents. They pile up really, really high everywhere. It takes forever to deploy, forever to release. And then sometimes by the time your product goes to market, it's already outdated. Poor you, because all this doesn't apply to us anymore. Because Allianz is on a journey, especially our team is on a journey, from waterfall to lean. This is our team. Our team, we were the first ones to embrace the new way of working at Allianz. We started, when did we start about one and a half years ago, with the help of Pivotal? We changed the setup in our team. We've got five developers working on the app, one designer, and one product owner. From our point of view, that's all you need. And it's not just the team. It's also the structure, how we work. With our Lean setup, we embrace the Lean startup methodology, which means we work based on minimal viable products. It's our goal to achieve technical excellence and true customer centricity. That's why we've dovetailed our development process with our user tests, for example. And also, before we start implementing a user story, we think about what's the business value behind this story. Hope you're all excited now. And I'll hand over to Dennis, who will give you more details. Thank you so much, Sarah. Good morning, everybody. Again, I'm Dennis. I'm the designer in the team. And just like Sarah mentioned, a transformation from waterfall to Lean startup can be quite exhausting. So let me show you where we actually trial and error. As you can see, we like to put post-its on the wall and even on our windows. We also literally have to stand up to present our ideas and learnings, not only in front of our teammates, but also towards stakeholders from time to time. We are also literally sitting in front of the same table working together. But we try to rock the house also in this kind of place. So we really like to compete against each other from time to time, against other teams, for example. And in case you want to compete against me, feel free to apply for a job at Allianz today. So as you can see, we really like to work intensely, but we also know how to enjoy work. But it's not only about where we work. It's also about how we work. And we believe in our approach. We really do. Because we think that every team member should have their own say. We also think that we don't need to spend too much time in meetings. This is why we plug out our telephones in our offices. And we want to have short stories so that everybody goes home happy at the end of the day. We also think that people are allowed, or they should, be allowed to learn and improve themselves continuously in order to deliver excellent quality and user experience. So let me tell you something about user experience. We listen to our customers. We really do. Believe me. Because our product is for our customers, obviously. We want people to enjoy interacting with Allianz. And this is why we're having a user test at least once per month so that we can test our features before we put them on production. So for us, the number one priority is to provide further value in the app. To do so, of course, we need the most advanced state-of-the-art software we can get. Simon is going to tell you a little more about it. Thank you, Dennis. So let's have a look at the tool stack that we are using. And as you already see, although we are a pretty small team, we actually have a large variety of tools and technologies that we're using. But don't worry. I'm not going to talk about all of those in detail now. In fact, the really important thing here is that we are in charge of this tool stack. So we, as a team, get to decide which tools are fitting best for the way we work. So for example, we chose to build our Android app on Kotlin instead of Java, which the rest of Allianz is using. But it was just like a decision. We thought, OK, this is a cool new language. So let's just go for it. We also saw the potential that it makes us faster. So we really have this kind of freedom. And that is actually a great thing for us. So in the end, it all comes down actually to which tool make us as fast as possible. And with that in mind, we also follow the DevOps mindset, which means after we build it, we also have to be able to run it. So naturally, if you follow that mindset, it comes to you to be as efficient as possible and to automate as much of the actually non-value adding processes next to your job, which for us is, for example, the build pipeline. For that, we are using tools like Jenkins or Fastlane. So in the end, whenever one of our developers is finishing a story and is pushing it to GitHub, the build pipeline will automatically run. It will build the project. It will run all the tests, which are also automated. We have more than 1,000 tests. And only if those tests are actually passing, it will then eventually push to Cloud Foundry or if you're talking about our app to the app store directly. So now let's have a closer look on how we actually use Cloud Foundry. So what you see here is a very, very abstract model of our architecture. And as you already know, we have two native apps, iOS and Android. So those apps need to consume a couple of services in order to get information. For example, one service is providing us with customer information about the contracts, while another service is providing us with information about the agent, and so on and so forth. So those services are not on the slide, but what you see on the slide is our API. And this API is running on Cloud Foundry. So this is actually for us working as a service interaction layer. So that means it's talking to all the different services in the Alliance world, and it's collecting the data, and it's preparing the data for our apps to consume and present in the end. Technology-wise, this is a spring boot application, which is always working great together with Cloud Foundry. And we have currently two instances of this running on production. And as you already have seen on that slide, this is a crucial part of our architecture because if this API will fail, both of our apps will fail as well. So this is where for us, actually, the resilience of Cloud Foundry comes in very handy, because whenever this API should ever crash, which, of course, never has happened, then we actually have the luck that Cloud Foundry will spin up a new application instance for us just now. So now, after one year, actually, on production on Cloud Foundry, what are our likes and dislikes about it? What are the experiences? And because I'm somebody who always wants to hear the bad news first, let's start with the things that we think could be better. First of all, we don't get blue-green deployment out of the box. Blue-green deployment is basically a technology that allows you to minimize, really, the downtime which is produced during a deployment by not pushing stuff to the productive application, but by spinning up a new application, making this application completely production ready before then, in the end, just switching the productive route to a new application. So this is a cool thing that we obviously want to use, but unfortunately, we had to implement this ourselves in the end, which, to be honest, was not that big of a deal, but still it's not coming out of the box, which would have been just a size. So secondly, the autoscaler does not really care about running requests, which means whenever this autoscaler is deciding to scale down one of your application instances, all requests which were currently processed on this instance will be lost. That might result in technical errors or stuff like that, and that's obviously something we don't want either. The third point is about the log format, because that has changed in a recent update for a log format of the application logs. And I believe it was the beginning of this year, somewhere, but the problem that this caused us was that it actually crashed our application monitoring because it just wasn't prepared for a new format. So you could argue that this is basically our fault, because changes like that are normally announced. But we still put it up on the slide because we think as a developer, you want the maximum consistency in a platform. And changes like that always have the potential to just crash or do something harmful on an consuming service. Those are the things that we think could be maybe better. But as you immediately see, this is a very short list, and that's because we are actually very happy customers. So let's talk about the things that we think are completely awesome. So first of all, it just works. And I know this is a worn out thing to say, but in a year now that we've been using this on production, we never had any real issues with the platform, and that's just a great thing, because it allows us as developers to just focus on our real job, which at the end of the day is just building an application and not a platform. The second point is that it's actually really easy to use as well, so you don't have to be an infrastructure specialist or anything like that to just use Cloud Foundry and also to get up and running really fast. Also, it has a very steep learning curve, so I think anybody just can learn how to use it in a very short period of time. But in my opinion, the most important thing about Cloud Foundry, what it gives to us, is that it gives us freedom and independence. And I know this sounds stupid, but actually if you work for a big company, you will immediately know what I'm talking about, because big companies, they tend to have a process for everything. And those processes also tend to be slowish and to be honest, at the end of the day, those processes kill a lot of the productivity. But that's what you don't want, right? You don't want to wait weeks or days for your productive deployment. You don't want to wait for the operations team to just schedule a deployment at whatever date. And luckily for our team, we don't have to deal with stuff like that, because we are the operations team as well. And that's actually the great thing about Cloud Foundry for us, that it empowers us as a team to just push new stuff to production whenever we want to. And we don't have to wait for it. We can do it immediately, so it speeds us up by a lot. So with that, I would like to pass back to Sarah, who's going to wrap it up for you. Thank you, Simon. Well, as you've heard now, we are really happy with our Cloud Foundry platform, because it enables us to move a lot more faster. We can deploy faster than we want. Whenever we think a feature is ready, we ship it. So it gives us freedom and flexibility. As I said before, Allianz is on a journey from waterfall to lean. Our team was the first team to walk along that path. A lot of teams are following. So with one and a half years of experience on that path, one year on production with our app, we can say we can really focus on what matters the most for our team to reach our goals. Our goals are true customer centricity, technical excellence. We can focus on that with our app, because the platform gives us the freedom not to worry about the platform. So if you want to learn more about this, or if you are interested in becoming part of Allianz, just join us later on at our booth. Our booth is downstairs and on the right. And we're happy to answer your questions. Thank you very much.