 All right, folks, I think we're going to go ahead and get started. Should we make the fire exit announcement? If you haven't seen this by now, then you haven't been paying attention. Please pay attention to where your fire exits are and exit the room in a calm manner in case there is a fire. We don't anticipate there being a fire during our presentation. We do have some really hot stuff to talk about. So my name is Zach Brown. I work at Pivotal, and Pivotal and Travelers have been partnering for some time. And that's why I'm here today with Naveen from Travelers. Do you want to introduce yourself, Naveen? It's on now. It's on. Okay. Awesome. Hi. My name is Naveen Babu. I'm an architect in Travelers. I also call myself a Cloud Evangelist. I co-chair in Travelers a group called Cloud Native Domain Team, which crosses all Travelers lines and everybody else. So we are actively promoting Cloud Native Development, Cloud Native Evangelists. We are building evangelism, so on and so forth. All right. And so we just also want to say that this presentation, not only just with this presentation, we are available through Twitter, email. If you guys want to chat afterwards, please do so. We'll be more than happy to share our experiences. Absolutely. So this talk is really about unlocking business value. What does that mean is in the .NET framework, right, .NET full framework, which many enterprises have a lot of applications like ours, we want to understand how do we modernize those applications, why do we modernize those applications, and so on and so forth. So in the green field space, like for example, .NET Core or Spring or any other applications that you're building, it is not that big of a challenge for building in new Cloud platforms. But if you look at the .NET existing platforms, like existing .NET applications and assets that we have, that is the elephant in the room. How do we take those .NET full framework applications and modernize it in the new way and also what does it mean, like what is the business value we get out of it. So today's presentation will be focused on those unlocking business values. So Zach will talk about how travelers and people will have worked together as a journey. It is a journey, we call it a marathon, not a sprint. So he will talk about that and then we'll talk about what does unlocking business value means and also focus on what are the opportunity focus. So it is a broad area when we talk about modernization. So we can focus on two very specific areas from our experience. One is deployed to runtime and app in runtime. And we also show some business core cards as to where we actually get the business value out of doing this modernization work. And lastly, we will summarize the approach, like what are the key learnings that we at travelers have had working with Pivotal through this three-year journey of how do we, what are the best things that we have found that will help us to modernize and really unlock the business value for our customers. So as we briefly mentioned, so if you take green field applications, the new parents like microservices, circuit breakers, blue-green deployment are fairly easy to learn. You can Google it, you can go to GitHub, there are open source, you can actually build it fairly easily because it's green field. And products like SteelTow that we have used from a .NET application gives a great level of abstraction so we can grow into and use different features like circuit breakers or service registry so on and so forth. But again, the elephant in the room really is the existing .NET, you know, brown field as we call it, applications. All right, so I'd like to talk just a little bit briefly about our journey together, travelers in Pivotal. It's actually quite a long journey so far. We've been working together for three years and we're, so we're well into it, we're focused on applications of a lot of different types but the great thing is that there's a ton of .NET apps on Windows, on Cloud Foundry running in production today and so there's great fruits of, you know, at the end of this journey. So what does our services enablement journey look like? We started by getting together and trying to implement Pivotal Cloud Foundry and the form that that took was a platform dojo. Some of you folks in the audience may have been through a platform dojo already or are going through it. And then after the dojo, after we had a platform that was set up, the key was to focus on applications so we did another engagement together called an application transformation or AppTX is our short name for it and the focus there is to migrate, modernize and then optimize applications to run on Pivotal Cloud Foundry. And as Naveen mentioned, the focus in this particular scope was on Windows apps, .NET apps that are running on Windows. Travelers is a big company with a lot of different groups that are running different technologies. So certainly there's Java, there's Spring and there are teams that are absolutely building new Greenfield apps that are written in .NET Core and running on Linux and Cloud Foundry. But specifically here we're going to talk about Windows. So first a question, why migrate all your existing apps to Cloud Foundry? And I think this is a good question to ask. So first of all, you can take advantage of the security in the platform. If you were here for Korn's talk a moment ago, he talked about move and improve. So the idea is that lift and shift is just the first step in a longer process, that process of moving, migrating, modernizing and optimizing. But even just by that lift and shift step, there are several things that you can take advantage. So security, stability of the platform, there's cost savings, there's productivity gains. There's quite a few reasons to do that. And then the next step really is how do you choose the right applications to move? Which ones do you start with? So we start AppTX engagements by examining a portfolio of all the applications in the company. We take that list and we apply some simple rules to identify candidates that will drive key ROI. So for example, we look for business critical applications or ones that have revenue impact. Companies that have a high change frequency then offer some big value to developers when you put them on Cloud Foundry and you can iterate on them quickly. There might be opportunities to reduce license cost. Whenever we move a Java application off WebLogic onto Cloud Foundry, there's always a tremendous cost savings there, for example. And then the suitability of the frameworks that the applications use and their dependencies also has an impact on the choice that we do. So Navin, can you tell us maybe about one of the applications that you have migrated that actually has big business impact? Sure. So Travelers, we are an insurance company, right? So I'll pick on Worker's Comp, which is, again, we are leading in the country and we have a self portal for injured employees. So if an employee is injured, they can self service like what's my claim, who is my medical provider, what are my bills, so on and so forth. So it is a very mission critical application for us and after the journey, right? So last fall, we launched our injured employee portal and Cloud Foundry is part of that critical path. And we are expecting close to or more than a million customers using the app by end of the year. We are already seeing tens of thousands using it at scale. And so it's no longer, three years back, it was like an idea, it was a leap of faith to some extent, but now we have many of them and this is just one example. So we are running through the medical protocol. So it's public facing, it's in production, it's on Cloud Foundry. So this is real. All right, so I want to wrap it up by talking about measuring the results. For engineers, it's easy to get caught up in the technical details and the technology, the mechanics of migration or modernization in that process. But our talk today is really about business value. As Humble talks about outcomes over output and the key outcomes he describes are things like reduced cycle times, reduced defects, increased predictability in your development cycles and reduced costs. So that's really what our talk is about today. We're going to review how by working with Pivotal, travelers was able to implement and then migrate apps onto PCF and make progress towards these outcomes and delivering real business value. So Naveen is going to talk to us a little bit about how he conceives about or thinks about business value and how to measure it. Thanks, Zach. So we are customer facing, right? So we want to provide the best customer experience from travelers and also for our employees for internal labs. So unlocking business value. So just to ground ourselves for what it means because each of us have a different meaning of what a business value could be. So for us it is really, we looked at in terms of tactical and strategic. So in tactical we said, okay, what are the operational improvements? How do we bend the cost curve? In strategic we are looking at simplification, modernization and how do we change the basis for competition, right? So how do we unlock in these areas? Which was more kind of, it helped all of us to focus on these things instead of kind of randomly assuming that somebody has a business value and we don't know what the definitions are. One thing that we learned over this period is normally it's not tactical and strategic or not either are, it is both. So we don't want to get bogged down on, okay, are we doing this for tactical or are we doing this for strategic? It's really, let's not worry about it. We know what the guard rails are. Let's move forward, right? So specifically on the dot net full framework, which is the topic today, we looked at the, we again looked at different lengths, where can we see this business value can be unlocked? So the three lengths are deployed to runtime. So think of a developer, developing, deploying the whole pipeline and all that stuff. So think of early value that we can unlock. App in runtime is based on the application architecture in the runtime itself. Where are the opportunities? So think of, not later stages, but think of the second stage of where we can actually unlock values. And the third one, which we're not going to go into any detail in this presentation, but I'll be more than happy to talk to if people are interested is in the developer environment itself. How does a developer, when they are developing apps of a dot net full framework, how can they unlock certain values in this paradigm, in this new paradigm? When we talk about deploying to and running the app in, you might think of them as day one activities of deploying that application and then day two activities of operating that application, handling the operating system and things that that application runs on top of, et cetera. Yeah. Again, this is just a very conceptual illustration and not really very accurate interpretation of what's available on cloud phone, reverses, VM based. But I want to point out certain characteristics here, which are very important to understand how we can unlock business value. On the left side, you'll see the VM based where if I'm a dot net app, right, so I have opportunity to define my IIS setup, right? I can say which app pool does it run. I will tell which user ID does it run, so on and so forth. And there is the centralized nature of GAG, file system, registry, configurations, you name it. So centralized nature basically, right? On the right side in the cloud foundry, the centralized nature exists if you want to use it, but we don't want to encourage and we don't want to use that. And more importantly also, from a dot net app, a lot of things are taken away from making decisions, whether it is which app pool does it run, what is the user ID, so on and so forth. So this is, though sounds very simple, actually you'll see in the next couple of slides as to how we can actually, we have unlocked some of the values there. Can I talk about that last slide for one second real quick? So the key here is that when we're running applications in VMs and app pools, there's a shared environment and we have a lot of isolation when we move to the cloud foundry model and we're running these applications in containers. And that has a lot of implications to how you even deploy applications and stand up environments and get ready to go. So Naveen is going to walk us through the sort of the before process and then the after process and we can see what those differences look like. Exactly. So remember the two lenses, right? So one is the deployed tool. So let's focus on that lens and the VM based. So that is the where we were before. So on the right, on the right side of this, you'll see the VM based as I said, I am able to define my IS pool, I will define my site, it's all awesome. But what happens in, at least in enterprises is now it is going to a centralized environment. And now we put a lot of governance around it. We say, hey, we want this naming convention. We want app pool to have only certain characteristics, so on and so forth. And this is not a day one activity, right? So over a decade of these assets that we have built over, you start adding processes. You start adding people to the process. You start adding, for example, you start adding architectural assurance and governance and whole thing. And what that brings associated is remedy tickets. Who loves creating remedy tickets, right? So it is, so this is what happens in an industry, in the enterprises. The more and more people get involved, the more and more you have centralized nature of any activity, a lot of processes get started built. And this is not, again, a day one activity over a period of this one. So that's what we see in the 10 plus whatever years of all these dotnet framework apps on the VM-based architectures, right? So you will see on the left side all the other things that build over time. And the centralized nature where you separate the application ownership with the setup ownership brings another set of people, another set of packages, another set of process, another set of ticketing, right? So all these kind of build over time, which makes the app deploy to not necessarily not possible, but you build all these, I would call artificial hurdles and some necessary, some maybe not. So that's what happens. So if you compare that to the Cloud Foundry, what we found and what we learned was you have less choices to be made on the platform, right? So less is more. So what that means is we don't need many people to make decisions. We don't need ticketing for those decision makers and also we don't need the setup that we had before and the packages and so on so forth. So you'll see the cascading effort is actually away from the actual, this one. So you'll see the blue unlock keys. That's kind of your indication of where we have actually unlocked the business value and just to, I cannot reiterate this enough that a lot of these things really just disappears because you don't need many of these things that were built over time. So that's where you will see the business value that you can unlock. So that before process we saw, the one word we didn't say but that should have been there in everybody's mind is that process was slow, right? There are so many checks and balances and things you need to go through when you're trying to check the architecture of applications that are coming in from an operation standpoint and then make sure that they're not stepping on each other once they get moved into their runtime environment. So the great thing is, and you wanna show the final slide, this is what the process looks like after we moved to Cloud Foundry. All those extra steps were able to be taken away. And so you mentioned remedy tickets. About how many tickets did it take to actually deploy an application in the before picture? Right. So on an average, we have been tracking the metrics, right? So on an average, we have saved six tickets per application. Six is a small number if you think of a number. But what that means is remember each ticket has associated SLAs. One of them could be three days, one of them could be five days, weeks. You name it, right? So six tickets were completely eliminated for one application for just one deployment, which freed up not only the ticketing process from a developer standpoint, but also the people who are actually processing it. Their time freed up. So you see the cascading effect is not just one ticket going away. There is a many different aspects of where we can start realizing value without really actually actively looking for it. And that was one of the challenges that we had early on for business value is, where is it? So this is one of the things that we noticed, which has really simplified our environment and the processes itself. I'll take fewer remedy tickets any day of the week. So just to wrap up for that lens, the business value of business value scorecard. If you look at operational improvements, again, SLAs going from days to minutes. And in some cases, there was no need for an SLA because the process was completely eliminated processes. And bending cost curve, again, going back to a significant reduction in our operational cost for each application. And if you think of one application, six tickets, think of 100, 150 applications that we go through, let's say every month or every two months to product production. So there is a significant amount of value that we have untapped or tapped rather. Simplification as you saw, and then obviously it has increased the speed of our change. So from a typical six remedy tickets down to zero, and we get to skip the architecture review because there's so much implicit in deploying your application to Cloud Foundry that there are a narrower group of decisions that a developer has to make. So some big gains on the first part. This is then deploying the app to the platform. So let's look at once we're running it and operating the application. Yeah, so the second lens is app in the runtime, right? So similar things, but a different lens. So you'll see on the right side in a VM-based, applications runs perfectly because we have optimized a lot over years. Like how we have squeezed in 100 apps at the beginning in one VM, then we went to 150, we feel proud. It's constant optimization that in the runtime itself, it works awesome, right? So you put in something in GAC, everybody who uses gets it. So I don't need to worry about it. All good things in the VM side. So but what that has evolved, again, away from the actual runtime is the events as we call it, like for example, a change in an application. For example, OS currency upgrade. So I go from Windows 2008 to 2016 or 12 and then go keep going, right? So you have this, it's almost like a jumbo jet. You have to wait for all passengers to hop into the jumbo jet and then it will start going, taking off, right? Versus you have single engine, each plane keeps going, right? You can keep moving the pipeline, right, of applications. So what we have seen is the big bang approach, right? So you have a lot of big bang efforts that goes on. So the complexity which is helping to run this machine on the right side is very highly coupled systems and a lot of management. So you spend months and months planning for upgrades, execution, so on and so forth. So I mean, how hard is it to do something like an upgrade from Windows 2012 to Windows 2016 if you've got a bunch of applications running in production? Is that easy to do? Is that hard to do? Anyone, anyone? Well, so that's really what we're looking at here. That's the process that we're looking at here. Even something like a small patch update, you've got to go through those testing processes with all your existing applications and make sure that you're not breaking anything. Right, so here, I mean, in the Cloud Foundry, what changes is, all those things exist. If you think of all the things that we just talked about exist. But what changes is because of the decoupled nature on the Cloud Foundry where it co-exists, right, so you have a 2016 container next to, from an application lens, it's all together. So what this boils down to is the whole problem that we talked about is boiled down to the application level. What that also means is, as a development team or application team or a product team, they have more empowerment related to when they want to go, how they want to go, and how fast they want to go. So it changes the dynamics. So the entire event management, as we call it, boils, goes to the application level. Which is a significant, in itself, and you'll see the business value. And again, going back to light government assurance, all those things. And so things like moving, installing a patch update to Windows, or even redeploying your application from 2012 to 2016, those are much faster now? Yeah, it is actually at a different pace. So if I want to go, I can go. I don't need to wait for 20 other applications to come on to the VM because there is centralized setup and all the stuff that needs. So it's basically I'm freed up, I can control my destiny to some extent from an application standpoint. So wrapping up here on the business value scorecard, similar themes, like weeks, two hours. And we have not gone through the next big cycle of our upgrade yet, but we are already anticipating that it could come from months to even weeks or even less, and more importantly, that control actually goes back to the application teams. So that's what we are excited about. And again, going back to simplification, decoupling architecture is really underrated as a statement. It really opens up a lot of value if you look at holistically from a bird's-eye view. It changes the way that your teams operate. It changes the way that you empower teams, so on and so forth. And so what does it say there? We move from weeks to hours? Yeah, weeks to hours. In doing things like OS upgrades or app updates. And again, additionally, what we have not called out here is empowerment actually goes back to the teams, not the organization as a whole. So finally, few things that we have learned, and we are still learning. It's a journey, as we said. The way that we came to conclusion is think platform is the architecture. So don't swim upstream, swim downstream. It's easier. Don't even worry about it. So less is more. This is very important. The less you have with the guardrails, the right guardrails, the more advantage you have overall outside of the platform and everything else. And this is something that we actually saw over and over again is human nature is to compare, right? So we just did it, VM versus Foundry. But when you're actually starting to modernize, we could not compare apples to apples. It was not apples to apples because it was hard to grapple. Like for example, a simple example is we have 200 apps running in 10 app holes. How can a platform run 200 app holes? We are going to have arm and a leg taken away from us, right? It is not that. So we have to trust that the platform is going to do what it's supposed to in an efficient way. And we have to, as from an application, decouple ourselves from that. So that is very important. So apples to apples is good because that's what we do. But we have to be careful not to kind of go into the, go in and saying we are not going to do this because it doesn't feel like it's going to work this way. Did you just say you can't compare app pools to apples? Because I think that's what I heard. And the third thing is very important. You have, it's a word analysis paralysis, right? We keep, we can go into this loop of should we or shouldn't we get more data, get more metrics. What we have learned is do not deliberate. Even if it's a POC, even if it's a small step, just do it, learn from it, fast fail. If it works, great, move on. If not, that's fine. For that particular use case, maybe that's not the good candidate. So doing versus deliberating is what we feel that the best way to actually move forward. Last couple of things, as Zach mentioned earlier, look for use cases which maximizes benefits, right? So like we have looked for catastrophic event with travel insurance, we want the scale up and scale down, right? Look for the capabilities that requires that. And last but not least, as you saw, things on the right side, you saw where application in and whatnot. A lot of things are cascading positively when you want to unlock away from that. We were not able to see that before, but when we started doing it, you could see that. So there is a lot of cascading effect that happens. So there's plenty of way you can actually look at business value, and we feel that we still have a lot of things to do, but we have already seen a lot of business value being unlocked, and it has changed the paradigm in which the teams work, think, and also we are very excited to move forward. Great, and I think that pretty much wraps us up on time. Thank you very much for letting us talk about this journey with you all.