 Welcome to this next contribution to the Cloud Foundry Enterprise track here. This time it's not actually a talk but rather a panel discussion. And could I ask the panelists to quickly raise their hand? So we have... Not now, when I introduce you. My little bit. We have Witteslaw Burta from Energy. Then we have Kersindar from Pivotal. Then we have Janerdan Wittal from Wipro. Replaced by our colleague Suresh. Welcome. Then we have Kerstin Schultz from Energy. Jürgen Blooming from Energy. Hi. And Stefan Träger also from Energy. Was not able to make it. Was not able to make it. Okay. All right. The title of the panel is Powering Growth in Emobility Using Cloud Foundry. So take it away. Thank you. Yeah. Okay. So good afternoon, everyone. We are here to introduce to you our personal experience we have made in last year when implementing Pivotal Cloud Foundry platform and how we support this immobility business. Short introduction of what is Enoji. Enoji is the utility company. So we are distributing energy and selling energy, gas or electricity. We operate in 8 to 10 countries in Europe. And we were here a year ago on this Cloud Foundry summit in Basel and we made kind of commitment to ourselves because it was just fresh start of our project that if we make it happen and we build up the platform and put some applications to life that we come here in the one year again and share what we have learned by doing this and what's ahead. So we are here to share and to make or give you some potential benefits which you can reuse in your life. So how we started with Pivotal Cloud Foundry even a bit ahead of that summit. We have done a short project with Pivotal Labs and that was kind of helping us to get convinced the management of the company that this platform makes sense. We are using Pivotal Cloud Foundry, not the open source one. And here with me are guys who has been introduced by names but anyway I would like to ask them if they can say a couple of words about themselves. So starting with a lady here. Hi everyone. My name is Kerstin, Kerstin Daha and I work for Pivotal and I'm the account manager and was so fortunate to be with Enoji on the first steps of their exciting journey. Hello, my name is Jurgen Blüming. I'm project manager for Immobility and we started the project on Cloud Foundry to be able to scale together with the growing business and having more charging points in the future. My name is Christian Schulz. I'm the product manager in the energy group for Cloud Foundry. Some more information. We have two foundations, one running in AWS and for data security reasons and so on. I mean we are from Germany. We have another foundation in our data center running on OpenStack. Good afternoon everyone. This is Suresh Gulli. I joined as a platform engineer last year in November and I'm from LibyPro. So it's a combination of mostly all of us who were involved in the project from different parties because we and Enoji work very closely with partners. When we introduced you, Kerstin, what we are going to do, so how we are going to build up the platform team consisting of multiple companies. What were your first thoughts about that? Thanks for this important question, Vitek. When we started last year after Enoji had decided to go with the platform, we of course started to discuss how we would implement it and our dojo approach to help the customer implement the platform and then we of course discussed the ideal setup of the platform product team and the prevailing pattern of the setup of such a team if we look across our existing customer base and look at those customers who are the most successful. The pattern we see is that those who build this critical team to the digital transformation out of people from their own company, those are the ones who are the most successful. This is for two reasons because when you build such a critical kernel of the digital success and transformation, you want to make sure that you have the knowledge built up with your own employees ideally and then the second one is that you are already embarked on a journey with a lot of challenges and obstacles and then if you add extra complexity, you might want to avoid it if possible, but then reality kicks in and what we see is that in a large number of the German accounts, there are really intense relationships between the accounts and their eyes and we have to be flexible and we have to adjust to the given situations and we will hear about this going forward, but yes, you are right. In the beginning we were skeptical and if this could work. Okay, thanks for that share. It was quite fair open and open. Then the next question is logically to Christian if you can share how it was then in reality after that starting point, starting situation. Yeah, fair question. I mean in the beginning it was of course a cultural thing, working together with one of our service partners, an Indian company, the Vipro one. We followed, as you learned in the dojo, we followed the methods of working together which were provided by Pivotal and it took some weeks, I think, but overall now we act as one team. There is no barrier between us, I think. We are working very, very trusty together and it's fun. Good. If I ask you, Suresh, then when you joined that team you also had some expectations and some history. Can you compare how this is to the previous engagements? Yep, sure. So when I joined as a platform engineer to the team, one shock first I got is there is no ITL process. So I came from the background of a service provider, customer kind of a relationship person and mainly coming from the infrastructure background and that was the first shock to me and then to get adjusted and coming to the agile methodologies and adjusting to the team and understanding how the value is getting delivered to the customer in an incremental way. It took time, but later point of time we got adjusted. Now it is like we are in a relation of partners rather than service provider come customers and it's a very good experience so far from past one year and we really like the agile methodologies and follow the scrums and moving forward we are on the journey of DevOps starting. Probably we'll have a good know what to say, good success stories on the next summit and the DevOps and how we performed on that. Okay, thanks for sharing that. Question to you again, when we started with the platform we obviously needed some project who will use it, who will be the first user. We started with quite significant because we took the most important project running in the retail part of our company which is managed by Jürgen. After we introduced you to the platform and what is going to happen, what was your expectation and how it was in real if you look back like those ten months? To be honest, we started working together I think in October last year and we were struggling with a lot of topics so first of all was about coming from a waterfall situation working agile and skilled agile. How to get people on board working on the platform as a solution situation to start developing there and to develop it and deploy. But also how could we achieve that we can run 24-7 and to end processes for immobility. Those challenges we had and we didn't know exactly at that moment how to do but we were pleased that there was a platform as a solution already being designed and not there yet. So we went a long way. We had a lot of expectations that everything would work and we had to figure out how and also to learn from those situations. And I can say my expectations were about fast development, fast deployment, easy configuring stages and having databases available very soon and that's all promises we see in practice. It really works. So we have currently six development teams running parallel to each other based on domain-driven design. We make a decomposition of our scope so that teams can save 95% work independently from each other. The platform and its features support us there. Very good. Having a database it can be done in five minutes or whatever, a new database. Our experience in the old world of energy was four to five months it could take. So we are moving much, much faster currently in development. Our next goals and challenges are about having a maintenance-proof situation. And I'm so happy to work together with people like Christian that we can work together on that. Not so easy topic from my experience but step by step we come further and it takes time. My expectations was it will go fast and I learned myself as a project manager a plan for that. Take time for that. Perhaps take a year at least to overcome all the trouble that you can have and have a very stable 24-7 supported situation. Thanks for that. To summarize that maybe if I elaborate some lesson learned out of that we were quite over-optimist in the beginning. That things will just go smoothly because if you read any product description then you have a feeling that everything will be there in a month. And of course this is not true because this is a long time that you need to build up the team. People need to learn, they need to practice, they need to fail sometimes and then start again. And doing that in progress with the project it's sometimes just taking a bit longer. So the lesson learned is if you start these projects like that drive these expectations rather lower than higher because then you will get better feedback also from business guys. Question to Suresh. The kerstin first. Because we are in IT quite used to build services. So we define some scope, we define some parameters, price. We put it somewhere to a service catalogue and then we are basically done because the services up and running and then we have also some procedures on how to change it later etc. And troubleshoot. But Pivotal came to us with a different approach and they told us like it should not be a service. It should rather be a product. And can you explain us once again what's the difference between having and running a service and product? Yeah, exactly. Thank you. Yeah, at Pivotal when working with our customers we are trying to establish a notion that the cloud founder is not just an infrastructure you install and then it's done and you go. And we rather try to work with our customers to install a notion that the platform should be treated like a software product. And we help to establish a platform product team, the name tells it, that really treats the platform as an internal product that you market internally. You develop it as a product team and then you reach out on a regular basis to your internal customers, to the application teams, right? And you listen to them and you do market research and you ask what is it, what you need so that you succeed with the business goals that you want to fulfill, right? And that's an ongoing basis. It's never finished. So it's really a software product that will be worked on continuously, the platform. And yeah. That was a lesson to us because by implementing the platform and passing through all the trainings some people in the company might think, okay, now it's done, you have the platform so you can just put as much as possible on it and you do not need to work further. But the learning was, no, it was a starting point. So we just have a platform and now we have to learn how to get the best out of it. And that's one of the outcomes of this year's journey. When I ask you, Suresh, when you look back for your first day with the team and you somehow go through all that year, can you share with the guys and with us here something that you would definitely not repeat again and something maybe what were the bright spots or something that we can take as everyone should do it like this because it's just a good idea? Yeah, sure. There are more and more bright spots than something which I can do it differently. So first one is about the knowledge of the platform as a service and platform as a product. So Platform Tree is a best enabler for applications to deliver their... develop their applications and go to the market very fast compared to the waterfall method if they follow it, that takes time. That is one part. And the technology point of view now I'm into the level of cloud native applications and talking about the 12-factor applications and what are the best practices about Cloud Foundry and the platform and implementing on the AWS and OpenStack. Those are the bright spots for me. And doing differently, I'm just thinking there is nothing much which I can tell about it. So maybe we can try with Christian the same question. If you have a look back, something to share what was not so great and something that was really good. Yeah, I think it's important to know or this was our experience. It's easy to run PCF in the cloud, for example. We have problems with our AWS environment. It runs like hell. But building up your own cloud in a data center which is owned by another company, this is really a hard job. Also the decision to run it on OpenStack, not on VM work, but it runs. But I think it was a big challenge to have an application which is very, very demanding like a mobility application during the implementation phase in the data center on the platform already. So I think we should change that and deliver a complete platform or a more complete platform to you and would have started with smaller teams on the on-premises. We have just learned that maybe the platform will never be done. Yeah, because it's living, but there are some, I think it's not always a technical point. Often you have things around the platform such as said, hey, Eitel, you need processes. This is a must to drive a platform. It is infrastructure related and this should be finalized. And some bright spots then? AWS. No, it was a bright spot. Bright spot is of course working together in the way we work together as a team and beside all the challenges and I said that before there was a lot of fun and this is very important and this makes this success like it is. Okay, so just having fun is quite essential element of those journeys. Same question to you, Jürgen. From the project perspective. Yeah, so what we changed during our journey was first we were considering the platform as just being there and we could use it and benefit from it and if it's not working we push on Christian but we stopped doing that. We tried to stop doing that because it won't help. And we learned from that to go together the way. Together from development perspective business perspective and also from platform perspective to learn from each other. It's not independent from each other. That's the best takeaway I can give to you but on the other hand I've never seen development and deployment going so fast. To be honest we had the platform first team started in the beginning of December last year after some two weeks or whatever they deployed already the first applications first small applications but they were able to do that and they were surprised themselves also how fast it's going. And it's so nice to see you people being happy. Good to learn. Unexpectedly we are very well in time so maybe we can give an opportunity also to you guys if you have some questions to us. Sorry, I'm going to repeat that. So we at Swisscom we just concluded a migration of our managed Cloud Foundry product away from OpenStack to VMware why did you on the other hand why did you go for OpenStack as an infrastructure? I think it was around licenses I mean usually we use VMware in our data center but there was a decision to go with OpenStack. I mean it's when we started it was delivered as a product OpenStack as a product from our partner Vipro so we took it. Alright, thanks. And it runs. No question. I don't see anything from your faces if this story resonates or not but basically this was what we have prepared to share with you. So thank you. Thank you.