 Okay, everyone, we will go ahead and get started. So if you make your way in, and if you'd like to throw things or ask questions, I move to the front. We'll have a little of time for Q&A at the end. My name is Mark Carlson. I'm the CTO for a systems integrator called ECS Team, headquartered in Denver, Colorado with offices in Atlanta and presences in Minneapolis and Dallas. And on the last year, we have been partnering with Pivotal and other providers of Cloud Foundry to do a variety of things to implement Cloud Foundry from initial installation and integration with on-premises, CI CD and monitoring and other infrastructures that most customers have. As well as to help customers build applications, both new applications and migrated applications. And so today I want to spend a little bit of time to tell a tale of some of the things that we've learned in interacting with some extremely large enterprise organizations around the country and some of their requests and ideas about how to move from that initial implementation of Cloud Foundry to doing kind of agile transformation at scale. And so this is a 30 minute talk, so relatively quick. Not going to be particularly technical, but hopefully can give you a little bit of insight into what some of the observations are that we're seeing, what customers are asking for, maybe some things not to do. So Enterprise IT is a little bit under the weather. And no, this is not a kissing book, just in case. Enterprise IT is under the weather and there's a number of kind of symptoms of some of those things. We've seen in this conference over and over again that we're moving from months to minutes, right? Weeks to minutes. And a lot of times our processes that we introduce into our enterprise, we've been building these processes to keep us safe, we've been building these processes to reduce risk, we've been building these processes so we don't necessarily have to stay up all weekend long to do the employment. But the end result is that the accumulation of all that process has driven our elapsed times from minutes to months. We've gone the opposite direction there. We see that and we kind of get the illusion of safety from all of these layers of process. And I've built a lot of those layers, by the way, over time. And when we did those things, we had good intentions, right? No one said, hey, my goal is to slow down the business by adding another layer of process, right? So the intention was good, but the accumulation of all those intentions over time creates delays and actually getting, and we've heard this, going from ideation into code, running at scale in production, we've slowed that process down, right? So one of the other things we see is that these aging applications that you and I have built over the last decade or so have become brittle. And the combination of those processes with maybe some of the frameworks that we used back in the day, we had good intentions, looking at UGE, but didn't necessarily pay off in terms of what we really wanted to do and it causes fragility. And every time we reach in to make a change, we break several other things. Now some of that has to do with process and best practice, but a lot of it is a combination of that plus architectural styles and frameworks. So Cloud Foundry is part of the solution, right? It's part of the prescription for what ails IT today, but it's certainly not a panacea. Like all of the other emerging technologies that have gone before us in the last 30 years or so, we don't just need a better, more cloud native app server, right? If all you do is take an application running on prem in your data center, deployed to one of the many very large application servers, have big names and big licensing costs. And all you do is move that application as it is to run in Cloud Foundry on some build pack. You will have gained some benefit, but we don't need to fix those things at ALIT. We don't need a better, more cloud native app server, right? Without processing culture change, which you've heard over and over again at this conference, Cloud Foundry is just another tool in a very long parade of tools. Now to be fair, it's a very compelling tool. It's an amazing tool. It does a lot of things for you, especially from the developer perspective, but also from ops. But if all we do is move apps onto that better cloud native app server, we haven't really impacted the business, at least to the extent that most businesses need impact in order to get over that, what ails them. So what are the common stages that we see in Cloud Foundry adoption within enterprises? We see that you start with an investigation with proof of concept, and a lot of times that will be coupled with production pilot. And we say production here because if you do a pilot app and you do something significant with the app, but it doesn't go all the way to production, a lot of times we find the business just doesn't care. You've done a nice little science project, and maybe you were successful in your science project. But where it really gets interesting is when you take that initially successful, usually a smaller app, and take it all the way to production, you begin to find the cultural changes that need to take place in order to push code to production, and to get that running at least at a little bit of scale. We don't advise a big bang approach where you take something huge and mission critical. We'll talk about anti-patterns here in just a minute. So we see the move from that to perhaps taking some Greenfield applications. So hey, there's a new innovative area of our business, and we think it'd be perfect. It needs the elasticity. It needs the scalability. It needs some of the new capabilities of Cloud Foundry. We see a lot of times Greenfield apps are a great place to start. They're often not burdened by years of legacy things that they have to talk to, or at least you can talk to those legacy things with backing services and not embedded SDKs and things. And then lastly, and this is where we're going to focus, lastly we kind of get to, all right, I've gone through these initial stages. I've gone through the POC and investigation. I've been successful with that. I've gotten a little momentum going. I've maybe done a Greenfield app, but I have, and here's where we begin to see a challenge here. I have a thousand applications. What do I do with those? And that's where we're going to talk for the next few slides here for the next few minutes, right? So it's been said that the average IT organization has around 300 applications. And if you think about that, kind of a rule of thumb is about 30% of those or about a third of those, rather, are good candidates over some period of time to be refactored or rebuilt, right? The other two thirds are probably applications that you either need to kind of tolerate. You might choose to virtualize those applications. Maybe you just isolate them and wall them off so you minimize your risk, but those are applications you're probably not going to refactor or not going to move. And so what do we do, though, about the ones that we actually do want to migrate? Ones that the business cares about, we'll get into some criteria in a minute, apps that the business cares about, apps that have an opportunity to impact innovation delivery out in your product system out there. And how do I go about choosing applications? We're going to talk a little bit about technical criteria, but the purpose of the talk is really to cause us to think about what are our opportunities to impact innovation in my application portfolio as part of a larger effort to migrate some significant portion of the portfolio to run on Cloud Foundry. So to start with that, continue the tale here. I want to talk about the three terrors of the application migration swamp, right? So if you remember in Princess Bride, we had the fire swamp and there's three terrors here. So terror number one, the lightning sands of indecision. I don't know if you've been in an agile transformation or a cloud-native revolution, or maybe you're trying to get applications to the cloud or to a cloud platform. But months and months and months and sometimes years go by and you're spinning on making a decision. Well, maybe we should do cloud platform A, maybe a B. Oh, no, look, Docker's out. Maybe I should build my own in Docker and a bunch of other things, right? And we've seen some anti-patterns where very large, very successful organizations get themselves wrapped around the axle, as the phrase we'd use here, where they're not able to accomplish anything because they're falling into indecision and analysis paralysis. So what's the cure for that, right? The cure is to just get started, right? Don't let the perfect become the enemy of the good. Get started, you might make a wrong decision, but it's better, of course, to move forward and learn and shorten that feedback cycle than to take literally years, in some cases, to try to study things to death. Second one is flaming out. Flaming out by forgetting the main goal. Why are we moving applications? Is it to get some small percentage of incremental improvement by moving them into Spring Boot or some other application framework running on the platform? Certainly the platform's going to provide some benefits, right? From day one that you land an application on the platform, we probably all can say now the list of benefits from aggregated logging and application monitoring and elasticity through quick scale out and a number of other things and we keep adding capabilities to the platforms to make that kind of application dial tone, as Cornelia Davis would say, even better and a more rich experience. But if we forget that the main goal is to drive innovation in the business by more rapidly delivering software to production at scale and we get kind of distracted by the technology, then in that case we will have kind of fallen into and become victims of one of the terrors of the app migration swamp, that we won't be getting the most. So flaming out by forgetting the main goal and lastly, this really scary one, application migrations of unusual size, right? We couldn't come up with an R for an application, but application migrations of unusual size. So we have been in some accounts, otherwise extremely successful people and organizations that say, hey, we know what to do. We're going to take the largest, the most complex, the most mission critical application. It's a flagship application and we're going to migrate that. You know what, if we get that thing onto Cloud Foundry, we can do anything, right? And unfortunately, two years later, they're still working on that one application and they've, you know, they've lost all momentum and the business has moved on and IT's moved on. Enterprise architecture has evaluated six new things since the Cloud Foundry thing and so starting with something too large is almost always guaranteed to not get you to adoption and to real impact in your organization compared to another approach, right? So how do I choose then, you know, how do I, clearly I'm not able to choose the app that's in front of me, how do I, how do I choose the right application to start with, right? And that's kind of a trick question because I don't believe there's an answer that says this is the right application, but how do I find applications that are likely to be the right starting point or likely to provide that mix of a quick success with business value that'll allow me to, you know, build momentum and include, include the right people from the organization so that they look and they say, hey, my, I know that guy. He's really good. That lady, she is sharp. I want to do what they're doing, right? A lot of times we've called that a pioneer team looking at some of the folks here in the room. We've called that a pioneer team. You want to find people that like to blaze trails that are comfortable with, you know, doing new things, but also have some respect in the organization. One of my customers has said, how we like to optimize for enthusiasm. I think that's good. You want to optimize for enthusiasm and flexibility, but also some kind of reputation. Optimize on a reputation for, hey, this person's really sharp. They're very solid. And if they can do it and they liked it, I think I want me some of that too, right? So the first thing on choosing apps to migrate is choosing what not to migrate. This is an incomplete list, but surprisingly enough, we have had customers and prospects that have said, hey, can I put my SharePoint on Cloud Foundry? And no knock against SharePoint today, anyway. But that's not the right place to start. Don't start with your packaged apps. One day, perhaps, when the Percy team gives us persistence in containers and, you know, the platform itself is mature, maybe that'll be a path that we want to do, or when Microsoft or others repackage their applications to run natively on Cloud Foundry, perhaps that'll be a path. But don't start with that. You're not gonna put your SaaS application on Cloud Foundry. So you can kind of exclude those from the beginning. A few others that perhaps are obvious to those of you who've been in this space a while. So applications that have a tight coupling to the hardware underneath. And yes, we still have some of those, and there's still some legitimate reasons for hardware coupling, even in this day and age. So don't try to move those applications if they're connected to a legacy operating system. Okay, you're probably gonna need to take those to a virtualization strategy and get them to a more modern operating system. And then after that's been done successfully, do that. Apps that have no business reason to change. So those are the applications in that two-thirds of the portfolio that aren't good candidates in the next foreseeable future for being refactored or rebuilt. Okay, don't start with those applications. When you get done, the business will not care that you did that, right? Don't move things that the business doesn't care about. Don't move applications that don't need a higher velocity of software delivery. And I don't mean never, and none of these things are always true, but if there's not a compelling reason, certainly don't start with these applications, right? Perhaps one day, when you've done that first third of applications and you're ready to expand that a little bit further, well then come back and pick some of these up. But don't start with apps that don't need to change. Why would you do that? The real goal is to drive agile transformation, to drive the ability to deliver software quickly. If you pick an app that no one cares to change, you haven't done much. Apps that only have a tenuous connection to their consumers or a tenuous connection to clear business value. If you say, well, I think this app is really important. It meets some technical criteria that might make it a great candidate to move to the platform, but you can't in a sentence or two describe the business value of that application to somebody who doesn't work in IT that might not be a candidate for you to move. Now, sometimes we have utility services and things that make other things go, and so there's some indirect business value. And if you could say that, I think that's a possible candidate. But if you can't describe why this thing exists, pretty much guaranteed the business probably can't either, and that's not a good place to start. Apps that are so trivial that no one will care, or apps that are so massive that no one should dare, those are both candidates to pull off of the list, right? So go through an initial filtering to say, hey, here's some things that we're not gonna do, and you're staring at me like, aren't these really obvious? You'd be surprised at how not obvious some of these things are. Well, what about a giant application migration factory approach, right? So if you don't know, this is the booing witch from Princess Bride, and she's, this is in Buttercup's nightmare, and she's saying boo, boo. We have kind of evolved on this. We've certainly seen some value in, hey, I'd like to get the largest number of applications possible, move to this great new Cloud Foundry platform, and there's a temptation, and frankly, there's some very large global systems integrators, that would like to sell you an application migration factory. And look, not all application migration factories are created equal. Some involve some adding value along the way, but the reason we don't think this is a great approach is they don't start necessarily with that, looking for that business value, right? Be very cautious, beware of Greeks bearing gifts, and beware of global SIs bearing application migration factories, right? Don't go down that pattern, that path too quickly, and understand kind of what you're getting into there. All right, so let me shift for a little bit, and somebody asked me, oh great, I was an operations research major, I can't wait for the theory of constraint, and like, this is not that kind of talk. So but what is the theory of constraints, and how in the world does that apply to application migration? Dr. Eliyahu Goldrat, back in 1984, sorry, I missed my date there, created really a management philosophy book that's turned out to have all kind of other implications called The Goal. You probably know of his work indirectly through the Phoenix Project, which was kind of based on The Goal, or in the style of The Goal, Phoenix Project is one of those required tomes for reading and learning about DevOps, and how theory of constraints applies to IT in general, but how does that apply? How can that apply to picking an application, or a set of applications to move? So in the theory of constraints, basically it's an overall management philosophy, and it's really the principle there is that in any linked set of processes, there is a step or a task that becomes a bottleneck. It limits throughput, right? Limits throughput, so in this case, and you probably can't see these numbers, there's, in this case, one of these steps takes longer than all the other steps, you can get two of them through in an hour, and so that one actually represents the bottleneck, because it has a throughput measure that's slow, and so what's the throughput of that entire line? It's two units per hour, right? And you can say, well, if I stockpile inventory right here, those of you who've done any manufacturing software, well, then I can go faster, but the goal is all about, hey, doing that, that's really bad, that drives your profitability down, and you don't make money, and the goal of business is to, hopefully sell products very successfully at a profitable rate in order to maximize their value, maximize their return, right? So that's what the theory of constraints is, in general, the goal is a great read, it's not too technical manufacturing, and I really understood Phoenix Project way better after I read the goal, so I would recommend doing that. So an innovation bottleneck, then, is if in manufacturing we have constraints that limit the throughput of a process, a bottleneck is one of those constraints in a production flow process, and it limits the overall capacity, the overall throughput of that manufacturing line. So an innovation bottleneck, then, is the inability to rapidly and continuously deliver business-impacting changes to an app, not just any app, but to an app that is an innovation generator. What are those words mean? That's an innovation bottleneck. We all have apps in our portfolio that are directly coupled to the ability of our business to innovate, right? So an innovation bottleneck is when you have an application with release cycle so long that you can't innovate at the pace that the business needs, right? So I would propose that those of the applications, once you do some other filtering, filtering some things out, we're gonna talk about filtering some things in in just a minute, the applications that we really wanna work on as candidates for once I've passed that initial adoption, and once I'm ready to scale out my implementation, my app migration, I wanna find those apps that are connected to business value and are connected directly, as directly as possible, to the organization's ability to innovate. And so you can think about applications, I'll pick one example. You've probably seen the commercials here in the US anyway for rocket mortgage from Quicken Loans, right? So we have other customers in the mortgage business, other customers in the banking business, and all of a sudden, there's a compelling mobile app and an even more compelling ad campaign that says, hey, you can innovate, you should use our product here at Quicken Loans because of this great new mobile app and of course all the back end services, right? So what if you're in a competitor? Or what do you need to do at that point? You need to innovate through an application. Maybe you didn't think you needed to before that ad campaign started running, but now all of a sudden you need to. Well, what if your release cycles, as in some giant consumer finance organizations are nine months to make a single change to a single webpage show up in production? That's a real story. What if you have, maybe it's only a couple of times a quarter, right? In the meantime, your competitor is eating your lunch because of innovation that they launched. So those are innovation bottlenecks because I can't iterate on my application, because I can't learn from my market, because I can't go fast in technology. I'm losing market share, I'm missing opportunities, I'm whatever the negative outcome is. So an innovation bottleneck then sucks the life out of IT, right? Drains IT's life away. Here, Count Ruegun is saying, I've just drained a year of your life away. I've been in meetings like that, you probably have too, right? Where the meeting just, I think I lost a year of life because of that meeting. So innovation bottlenecks suck IT's life away in a broader sense and maybe with less humor. Innovation bottlenecks over time make IT less relevant to the enterprise, right? And what happens then? Oh, horrible thing, shadow IT happens, right? They go out and they hire firms to go build it on the public cloud or they swipe a credit card and go get some infrastructure and do it themselves. And oftentimes they can innovate very rapidly and then an idea takes off. They learn from the market, it scales out and they want to do it safely. And that's when kind of the shadow IT approaches often fall down is when I build it and now I'm ready to take this idea to scale. So we want to go fast but we also wanna go safe and that's one obviously a huge advantage of building from the beginning on a platform like Cloud Foundry is that we can do both. We can go fast and we can go safe. So what are some initial filters? This is not an exhaustive list. Of course, technical fit and there's a number of facets or aspects of technical fit. I made up a word, 12 factorness. You've heard of 12 factor ad infinitum here at the conference. How close to 12 factor is my application and we're not looking for perfection, right? If we, and 12 factor by the way is also not perfect but we're not looking for perfection. We're looking for applications that are closer to 12 factor than they are to a monolith, right? And they've avoided some of the things that we did earlier we had one of my former customers saying, hey, this guy wrote some code for me eight years ago and that's true. When we did it, we did it state of the market. It was stateless. It was whistle first. It was all those great SOA things that we were doing eight or nine years ago, right? And that application should move very quickly to a platform like Cloud Foundry. Nick can tell me if that was true or not but it should move very quickly to a platform like Cloud Foundry because it didn't do a lot of the bad things that you see a 12 factor approach helping you to avoid, right? Size and complexity, right? Some of those criteria I mentioned earlier you wanna find applications that are the right size. You're gonna be able to slice off a piece of that application that has a connection to business value and migrate that slice in a relatively short period of time. In a recent project we did for Fortune 50 retailer we were able to take, really we had five slices ready to go production in the first four weeks of the project. And these were significant slices. This is gonna just like read only things. These were business significant functions but they weren't so complex and they weren't so large that you could never get done, right? So find the right size and complexity and make those things be directly connected to easily measured business value, right? There ought to be a metric in business terms. Well, if I do this, how many more dollars of freight invoices can I process than I could before, right? I have to use one example. What's that business metric and ideally you'd find when it's connected? Maybe you gotta do a little translation work but it's connected. Also look at some things for the team. Earlier today, earlier in the conference we talked about the frozen middle, right? That part of your IT organization that resists change and they resist it so much that other in other places are called permafrost, right? Permafrost is that layer that never thaws out, right? Don't start with a team that you would say, you know what, I think this team is probably in the frozen middle category or in the permafrost category. That's not the place to optimize. You don't want to start there, right? Find a team that's eager to embrace, to learn new things and they're hungry for new techniques. They want to hone their craft, right? They consider themselves professionals. They consider themselves, you know, real hands on architects, real hands on developers and they want to get better and those team members should be respected, right? Those are folks that you want to build momentum when you're doing that. So how do you find innovation bottlenecks? You know, I'm gonna skip through a lot of this but if it's inhibiting change overall, it might be an innovation bottleneck. If the business is going around that part of your organization, you have any of that? Okay, I've asked these guys to change. I've been trying to get into a change. I've been trying to get in and go faster and I've been doing that for five years and you know what, I'm gonna go around and some outside consultant like me is coming in to help with that, right? And then introducing even the smallest feature is something that provides great risks and it's like reaching into a ball of barbed wire and drawing back your hand, right? I don't know where I heard that in illusion, Mike. So how do we do that? We strangle the bottlenecks. This is a strangler vine. This is where the Martin Fowler kind of got the name of this pattern and rather than kind of walk you through all of this, I'll just summarize to say rather than a big bang migration approach, we're gonna identify a slice to carve off of an existing monolithic app. We're gonna wrap that slice and test so that we can do it safely. We're gonna intercept calls that used to go maybe into the monolith somewhere else. We're gonna intercept those calls and redirect them. Nowadays, since we have things like histricks in Eureka, we wrap that with a circuit breaker so that we can see the rate of throughput and we can also safely fall back to a fallback behavior which might be the legacy application code. If, you know, when you're doing the first couple of these, right, you're trying to gain trust. You wanna make sure that that first slice that you take to production, you've really thought about, hey, what if this doesn't work, right? What if some of those seven fallacies of distributed computing come true in my application and think about the failure and wrap it in tests and wrap it in circuit breakers and go safe, especially that? And then the slices are connected to business value. Over time, as you carve off chunks and as you build up the ability of more and more agile teams to work in parallel on carving off chunks, right? Then eventually what's left, and this is where the strangler pattern comes from, is a core. You've carved off all the great juicy functionality. You've got this core, and either it's a core that you can tolerate and live with or it's a core that you can finally retire and eventually you've replaced that application with a strangler pattern. So that's one great way. There are others, that's one that we see getting a lot of traction, right? But then, you know, don't let a little success go to your head, right? So you've got some success. You've got some momentum going, but you want to think about, okay, now I want to scale these agile teams and I want to scale this approach. So how do I do that? And it's not by making the factory bigger, right? You've got to equip more and more agile teams to be able to do it the right way. So rather than a big kind of plain vanilla application migration factory, you really focus on the teams. How do I scale agile teams? How do I teach them how to do it right? How can I build some applications scaffolding so that they can go fast and be safe? You know, those are all the things, right? And then so a few reading resources here. Princess Bride would be the first one I would recommend. Picked it up and it goes all the way back to VHS in my house, I don't know. But obviously, take a look at that. But working effectively with Legacy Code is a great reference. The goal that I mentioned earlier, application migration selection criteria is actually a white paper from Josh Cruck and Abby Kearns that's come out. It's very helpful. Michael Cote has written a whole series of blog posts on the cloud native journey and don't forget the Princess Bride, right? And so with that, I'll wrap up. I'm Mark Carlson, ECS team. Thank you very much. Thank you.