 All right, welcome, everyone. Thanks for coming to this session. This is a talk that's going to be about accelerating developer adoption of Cloud Foundry. And I'm joined today by Luis Amadeo with Ultimate Software. He's a distinguished architect with Ultimate. And he has some great insights to share about their adoption of Cloud Foundry. And my name is Matt Gunter. I'm a platform architect with Pivotal. And I work with a number of customers that are at different stages in adopting Cloud Foundry. And one of the things that captured my attention recently is what are the factors that help some companies kind of press the gas and just take off with their adoption? And then what helps other or what causes other companies to basically tap the brakes, right? And not be able to get past certain issues and so forth. So I did a white paper on value stream mapping that talked about how Cloud Foundry adds value. And this kind of builds on top of that, which is why does it matter? Who cares about it? And how to make that process go faster. So without any more intro, I'll just jump in here. So we're going to talk about two perspectives here. The developer's perspective of Cloud Foundry and what it means to them, as well as the stakeholder's perspective, and how Cloud Foundry helps them accomplish their goals and mission. We're going to talk about things such as top down versus bottom up. We're going to talk about trust and confidence and alignment and consistency. These are all things that end up kind of getting discussed in the context of culture. And we're going to try to demystify that a little bit in this talk. And as I go through here, I've done some research on a number of Cloud Foundry adopters. And we're going to analyze their adoption of Cloud Foundry and try to understand why they're doing so well, why they might be having some challenges, and then what are some things that we could do to make it go better. So it's pretty clear. Most developers want speed and autonomy. That's not very hard to realize. But even though we can offer all of these capabilities to developers with the platform, there's still resistance. And it's interesting to try to understand that resistance. And one thought about this slide that I chose the Millennium Falcon as an example. If you tried to get Han Solo to trade in the Millennium Falcon, you might have a little bit of a trouble doing that, right? He's got a lot of history with it. Him and Chewy have a lot of shared understanding about the Millennium Falcon. So if you're going to get him to switch ships, it might be a little bit of a challenge. Now let's talk about stakeholders. The stakeholders are interested in outcomes. And they usually tend to translate those outcomes into a mission, right? And it's important to separate what the outcomes you're shooting for versus what the mission is. For example, the graphic on the right, a mission to Mars is not a mission to Mars. You can go into orbit. You can do a flyby. You can land a rover. There's a lot of details about the mission that are important to understand, to really understand what's going on there. And with Cloud Foundry, a lot of times the outcome of developer productivity, operational efficiency, et cetera, those become the mission. And we're going to talk a little bit more about that as we go through this to try to find a higher level mission, something more inspirational, something more compelling to align Cloud Foundry with. And this, I believe, is one of the keys to companies adopting Cloud Foundry in a very successful way. Here's a basic model that I think a lot of Cloud Foundry adopters have in their mind when they look at accelerating adoption or accomplishing their outcomes. They see, OK, I'm going to get Cloud Foundry installed. And then I've got to work with the devs to use it. And then I'm going to accomplish my outcomes, almost like a math equation. And at Pivotal, we have quite a bit of support for companies, even with this mindset, to help them be successful. We help their developers with learning XP and installing the platform and managing the platform as a product, helping them be more customer-focused as a platform team to the developers so that they're listening to the developer needs and trying to anticipate those, et cetera. But even so, with all of this, there are still challenges that emerge. So in looking at this and trying to figure out what the best way to look at it, I came up with this Denison model. This is an organizational change model that was developed by Daniel Denison at University of Michigan, like, I don't know, in the 80s or something like that. It's been around quite some time. But it's based on research that shows that all of these different dimensions in this model are related to company performance in a very concrete way, in a very measurable way. So basically what this model says is that if you're a company and you have strong traits of mission, strong traits of adaptability, involvement, and consistency, you're going to have better profit, better growth, et cetera. And these are all the same factors that I believe affect Cloud Foundry adoption. And if we believe Cloud Foundry is going to be a positive impact on your business, then this is just upstream of that, this notion. So here are the things that we're shooting for in this model. A clear mission, technical consistency, and the systems inside your company, involvement at all levels, and adaptability that's meaningful to your customers or your market. And a lot of times we, and I kind of did this with the value stream, you kind of drill down into the process and break out the magnifying glass and say, hey, what's going on at this level or that level? But sometimes taking a broader perspective is more helpful. So I threw this dolly painting in that thought kind of exemplified that. Now if we take that Denison model and we apply it to Cloud Foundry, it kind of looks like this. So we have, instead of mission, let's just say long-term direction, instead of consistency, let's say technical strategy, instead of involvement, let's just say empowered teams, and then we have growth and adaptability. And all of these points that are inside these columns, these are nothing, there's nothing new here. These are the same things that we would be talking about in the basic model, right? We'll be talking about, let's manage Cloud Foundry as a product, so a platform as product. Let's move towards microservices so we can reduce our development batch size and reduce the sizes by releases so we can release more frequently. Let's reduce technical debt. Let's adopt some agile practices, maybe do some cross-functional teams so that the teams don't have to reach outside of themselves to make decisions. They can be more autonomous. And then if you do all of these things, you're able to support experimentation, learning, et cetera, on the business side. So let's look at how that would work in a little bit more detail. So there's a relationship. If things are working the way they're supposed to, and there's a lot of backwards and back and forth in this model, you can start with the growth and adaptability and learn something, right? That's what learning is, and that can feed back all the way to your mission, so that's a possibility. But let's just start on the left side and say you have a mission to accomplish something for your customers or in your market. You design a technical strategy to implement that. Maybe that includes Cloud Foundry. You want to empower your teams to take advantage of that technical capability and help achieve that mission. And hopefully they make applications and technology that's available to your customers and to your salespeople and to other people in the customer-facing side of your business in order to achieve the mission, right? So that's the idea here. And if you're successful, there's a strong feedback loop that happens from the adaptability and growth pillar back to the mission pillar, and it reinforces that mission. And this is important to make sure that executives stay on board, that the organization feels like they're making progress, removes frustration, et cetera, from things. So it just clarifies exactly what the company's trying to do. Now, if we look on the bottom side of the Denison model, this is focused on internal systems and people. So this is really the interplay between the technical strategy and the empowered teams that are your developers to a large extent here, but obviously your platform team and other people in the enterprise should also be empowered. But what this is really focused on is the fact that if your platform team just throws Cloud Foundry out there and they're not looking at how developers are using it, they're not listening for ways to improve the platform, they're not engaging with the developers to solve their problems, then there's not going to be a good feedback loop. And this inner loop is going to not be reinforcing. It's going to cause problems, and it's going to limit your growth of Cloud Foundry. So let's take a look at a very positive example here. This is a retailer that has done amazing things with Cloud Foundry. It's affected all corners of their company, and they basically want to be on par with Amazon. They want to be leading edge. It's a very bold, daring vision for them. They're going so far with their technical strategy that they want to rewrite their core apps. Their teams are wanting to adopt XP, so not just agile, but go all the way to pair programming and TDD and some of these more less common practices. They're even promoting accountability to the point of giving devs access to production, the ability to release code into production. So that's also a very bold thing for them to do. And all of these bold steps add up to a lot of growth and adaptability improvements. So they're revisiting all of the decisions and practices that they've done in the past and making sure they fit with this new model. And the business is really feeling those benefits. And both of these inner loops and the outer loop are very much reinforcing in this scenario. And they're making great progress with the platform. So let's take a look at a manufacturer that's more cautious. They have a process improvement mindset, and they're trying to implement Cloud Foundry as an incremental improvement, build on success, enable the business. Their technical strategy is also influenced by this mission, so they're trying to prove the tech incrementally. And they believe they, from their perspective, they stood up Cloud Foundry very quickly. However, it took them 80 days to do that, which sounds a little bit on the long side to me. And after it was done, they had to certify it, et cetera. So those are all kind of telltale signs that they are being more cautious, and they haven't changed their practices to a large extent. Now on the empowered team side, they are making strong progress in their digital factory model. Basically, you might have heard this concept before. There's this common pattern of creating a center of excellence around Cloud Foundry and agile development. And in a lot of large organizations, you kind of start with that COE and try to expand across your dev population from there. So outside of that, there's still some complacency. They're looking for more change agents inside of their dev teams to foster more adoption of Cloud Foundry. So the feedback loop could be better on the inner cycle there. However, on the growth and adaptability side, they've done enough to have some impact on sales. Executive support is growing, so they are getting a little bit more executive level support. And so if I'm looking at this objectively, it seems like they need to really leverage that executive support to help transform more in the technical strategy and in the empowering teams to make sure that that doesn't stall, so the progress that they've made continues. Let's look at the flip side. So this is a company that manages prescriptions and prescription drug programs. And they have the flip side problem, right? So they are very strong on the inner loop. So they're automating everything with their platform. Their dev teams are doing a lot of training, a lot of app transformation. There's a strong feedback loop there, and it's very reinforcing for them. So that's a very strong part of their transformation. But they're having trouble getting the business to know what to do with this capability that they've built, and they're having trouble with the executives knowing how to help them get that engagement and that involvement with the business. So in this case, I think on the flip side, they need to also get more executive sponsorship and get more help with the business to leverage what they're doing on the tech side. So again, you can see how this model is helpful in understanding what you're doing well and where you might need to improve. And one thing that that Denison model is pretty good at is it points out ways that you can use one strength of the enterprise to help counterbalance weaknesses in other areas. So here's another kind of perspective that I think is helpful too. This is an idealized adoption scenario. And ideally, you'd have the persistent mission from the beginning, right? You'd have executive sponsorship from the beginning. You'd build capabilities based on that. You'd grow confidence in the new practices following on those capabilities, and then you'd get some early wins and you would start to pick up momentum. That doesn't always happen. A lot of times the dev team start using agile practices before the platform shows up or the mission comes later. I have some examples about that as well. And so here's a global bank that is basically having to refocus their interloop because they delegated Cloud Foundry to a shared ops team that was not able to support their developers as well. They were letting the platform not be upgraded as frequently as it needed to be and so forth. So they're bringing that back into the business unit. In this other scenario, a financial services provider had a bottom-up scenario where the developers brought in Cloud Foundry themselves. They handed over to the ops team. Now the ops team, they're treating it just like any other piece of infrastructure. They're not managing it as a platform. But luckily, the devs have been able to rewrite a core application that's made an impact to the business and it's starting to get the executives aware that there's something big going on with the platform and with this capability. So they have an opportunity here to get that outer loop to support some improvements of the interloop and have their adoption accelerate that way. So a key takeaway here, I think, is that the cultural aspects, this reinforcement that happens around success or failure or what have you. A lot of those boil down to beliefs and fears and things that have happened over years inside of your organization. And if nothing else, hopefully this model will allow you to kind of bring some of those factors up and be able to talk about them explicitly and not just have decisions being made about things based on beliefs, fears, policies, habits, et cetera, that don't move you forward in terms of your technical strategy or the way you're working with the technology. Okay, I'm gonna skip ahead so that Louise can tell the story of Ultimate and their journey of adoption with Cloud Foundry. So Louise, come on up and I'll turn it over. Thank you. Thank you, Matt. So Ultimate Software. So what do we do at Ultimate Software? So Ultimate Software builds software, human capital management software. This is basically, we have a product that's called Ultiprope that enables organizations and employees to manage the complex life cycle from recruiting someone into the organization, onboarding people into the organization, and then living in that organization, getting paid, getting performance reviews, setting your goals, all the way to retirement. So Ultimate Software, the mission has been very strong and consistent for the 28 years that we've been in business. And the mission has actually driven, or the culture of the company has actually driven its mission, and it's basically to put people first. Not only to put people first as the employees of the organization, because we strongly believe if the employees are empowered and we treat people first and put them first, they're gonna take care of the business and eventually the customers will be happy. But also that culture and that mission translates into our product mission, which is simplify people's lives. So that is our customers' lives through our product, as well as our employees who are actually servicing our customers, right? So as you can see in that red graph, in the journey to the cloud, that mission has actually stayed pretty consistent, right? Now that mission has led into many, drive many capabilities that we've actually driven, we've actually created in the cloud. Starting in the late 90s, we moved to a software as a service model. This is a big transformational shift. After we moved to the SaaS model, we realized that obviously you need a lot of automation to be able to live in a SaaS model, especially driven by quality. Once you actually start delivering software in a SaaS model and you're actually trying to do it fast, then the first thing that we did, we need a lot of automation and actually test automation ensuring that the product is actually a quality product. After we went through that, then we realized that we actually wanted to deliver more, more value, right? So what happened was that the cloud capabilities allowed us to actually test and ensure quality, but we weren't actually delivering fast enough. So we started introducing more cloud capabilities that allowed us to actually do infrastructure as code. We introduced an infrastructure as a service platform, and that actually started the DevOps movement on alternate software. We got development teams that felt empowered to actually write all this automation and deliver code to production. But what started happening is that we realized that we had reached a speed and an agility, but that speed and agility needed to improve in order to meet the customer's demands. So what we did after that is that we introduced an appliance framework that actually encapsulated a lot of that infrastructure as code for complex deployments such as databases and message brokers, and that improved the experience for the development teams significantly, but again, trying to meet the customer's demands for people for sculpture meant that some of these teams actually needed even more cloud capabilities. So as we struggled to see how we can actually make this faster in scaling this business, we took a dip on the confidence. I mean, as more and more developers actually needed more from this platform, and we struggled to actually give them more, more capabilities, right? Confidence started to dip, and then we looked at ourselves and said, what is it that we need to do here to deliver more with quality to our customers and ensure that the development teams are empowered and have the tools that empower them to actually deliver? So that's where we introduced Cloud Foundry into our ecosystem or a portfolio of cloud services that significantly started helping the confidence. What we got is from early winds of actually internal tools, even some early micro-services actually start generating that adoption. And once you started getting that adoption in there and other teams started to see the capabilities of this, then the confidence started growing and we're continually going into that, increasing that adoption and that confidence as we speak. The next journey for us is going to be what is going to be next after the Cloud Foundry application platform? So where we started to think and look at what are those other technologies that will enable us to deliver more with quality? So if we look at the forces that play here that have played out through this journey, it's very, very clear to us that our mission, because of our mission has been so strong, people first, simply by people's lives, and that has been so strong that we've always tried to meet the market demands. We've always met our customers by market demands. So that's a very strong relationship. Simplify people's lives, deliver what the customer needs, do not deliver just shiny technology objects. That has been very, very strong for us. Now, what has been also healthy but challenging is that internal reinforcement loop. I mean, in this internal reinforcement loop, what it means is that because of our culture of empowerment, these teams, development teams are encouraged and super empowered to actually innovate and deliver more. So they're constantly innovating, so they're constantly asking more from our Cloud Platform team for more Cloud capabilities, right? So there's this internal loop that's actually constantly innovating. The challenge there is, is because we have that strong, very strong relationship between what the market demands, strong to our mission, and what we deliver to our customers. Well, there's sometimes we believe that we don't have time to focus on these Cloud capabilities because we need to focus on the features of the customers, right? So even though we have these two very healthy relationships right there, or feedback loops, it's still a little bit challenging on how do you actually weigh in what you invest in your Cloud capabilities versus the features that the customers are demanding, right? So is it really a challenge, though? Is it really an opposing force, right? We believe that right now, the really kind of the challenge is making sure that everyone organizations are on the same page, but it's not necessarily an opposing force when you look at it. And what's happening right now is that we have these empowered teams innovating, creating more technologies, asking for more Cloud capabilities, and that's actually feeding our technology strategy. That's actually helping us align the business strategy with what the technology can provide, shape the technology strategy, communicate the technology strategy, and start bringing in more Cloud capabilities. And at the end of the day, what these Cloud capabilities are, are improving the delivery value chain, which is essentially just giving more of these people first features to our customers, right? So at the end of the day, both of these loops are seeking the same goal, right? So our challenge today, just to recap, is that we as technologists and as people on empowered teams and people working on the technology strategies, we have to actually start communicating a little bit more of how these solutions actually empower the business to reach their mission critical goals and their actual cultural mission, which for us is to simplify people's lives. Thank you.