 For the opportunity to come talk to you about OpenShift and container adoption in enterprises as we've seen it from the Red Hat Consulting Organization. So again, my name is Trevor Quinn. I am the Container and Paz Practice Lead for Red Hat Consulting North America. My group is a specialist group inside of Red Hat Consulting that just focuses on containers, Kubernetes, and OpenShift adoption at some of our larger, more strategic customers. And what I'd like to talk to you about today is some of the lessons that we've learned over the past three years or so since OpenShift 3.0 went to GA status back in 2015. And we've tried to kind of take in all of the experiences that we've had with large organizations beginning to use Kubernetes, beginning to use containers at scale, and distill them down into, first of all, a framework for container adoption that represents a progression through milestones of operational maturity, CICD automation, and application onboarding, as well as process transformation across all three of those areas, and lay out kind of a sequence or a framework of improvement across those areas to demonstrate greater and greater levels of software delivery efficiency. Inside of that framework, I think we're starting to see a couple of key practices that we find beneficial to organizations pursuing this kind of activity. And I'd like to talk through some of those with you today. So what we're really talking about here is how do we go from kind of isolated container experimentation to mass adoption of containers? And in the process, how do we transform the organization to be able to take advantage of this technology? And I think if I could sum up all of the lessons that we've learned over the past few years, it's that technology is easy, but changing an organization is difficult. And so let's see how we can tackle that challenge, how we can address that challenge. I'm first going to talk to you a little bit about strategy and some high-level principles for how we modernize application delivery. And then I'm going to talk to you a little bit about the lessons and tactics involved with achieving that digital transformation that so many organizations are attempting to achieve now. I think I've been asked to trim the presentation a little bit to save us some time. So I will probably not get to too many customer stories. But the good news is there are many, many other customers who are here today presenting to you directly whose practices embody a lot of this thinking. And so there are plenty of opportunities today to hear from real customer experiences here in Latin America that can talk you through some of those examples. So starting with strategy. I think the question for a lot of customers is how to modernize the IT organization and specifically how to modernize application delivery. And certainly containers are part of that journey. We kind of spread it across five different activities that represent greater and greater levels of delivery optimization. Starting with building a cloud capability inside the organization. And by cloud capability we really mean the classic definition of cloud in terms of developer self-service and ephemeral instances of compute that can be easily created and destroyed as needed. And utility driven pricing or at least internal charge back of resources based on hours of usage or based on units of consumption that can be measured and tracked at a large scale across the whole organization. But that cloud capability regardless of whether it is on-prem or through public cloud consumption is really just the beginning. The important next step is to start to move workloads into the cloud environment and start to set up the automation of the delivery pipeline to be able to show applications in motion from development all the way through to production. And it's really not until you start seeing that movement of workload that you're validating that your organization is taking advantage of this cloud technology to the fullest extent. And once you do that we'd like to see organizational impact to those activities. So giving your delivery teams end-to-end responsibility over their code so that you're starting to break down DevOps silos or break down DevOps barriers. And instead of a development team seeing its job as creating a software release that they then hand off to an operations group and kind of step away and let it be managed and run by a different team, give those teams responsibility for that workload up to and including production post go live, post release. And in so doing give them an opportunity to see valuable real world feedback from the systems that are running the workload from the operators who are responsible for managing them and most importantly from the customers who are using that software to understand better how they need to change that software to capture greater and greater business value. So that's what we mean by this end-to-end responsibility and then finally and perhaps at a most challenging level starting to think about the restructuring of teams to be able to promote better organizational agility. So the classic example is Amazon trying to keep teams no larger than you can feed with two pizzas I think. And so you know as you start to think about this eight, nine, ten person team how can you give a particular service or component of application functionality over to the smaller team and let them work in a much more agile iterative fashion on just that particular unit and then of course organize all of these disparate teams in distributed application architectures running on their own deployment cycles and coordinate that activity without any degradation in the customer experience in the level of service in software quality. That's really the challenge. So those are some of the kind of strategies that we see at work with container adoption and then we have kind of a set of philosophies about how to organize and conduct that work. Namely we want to avoid long-term roadmaps. We want to plan just enough to get started with the effort. Try to break big projects up into smaller chunks and work incrementally through those project stages. We want to see rapid feedback cycles between different participants in the in the system and critically we want to make sure we're automating as much as possible. So a lot of times that customers we tend to see a relatively narrow focus on automation just around build process or continuous integration. What we'd like to see is extension of test automation across a much larger duration of the development life cycle and emphasis on CICD and true continuous delivery capability and a focus on not just automation around deployments but also provisioning and automation around the creation of entire clusters or operating environments for developers and their workflow as well as servers operating systems monitoring software. All of the different elements in the in the operating environment for open shift or development trying to automate the creation and destruction of those as much as possible so that there's very limited hands-on direct manual intervention in that work. We want to see new skills get built through pairing and mentoring so trying to team up developers and system administrators maybe who come from an earlier more kind of traditional era in computing teaming them up with people who have more recent exposure to cloud technology, cloud native development, container infrastructure and start to kind of transfer skills through shared work. And then finally and perhaps most importantly begin to see cultural changes that result from allowing experimentation to inform your strategy. So giving your teams the autonomy and giving them the trust that they can take risks, experiment, potentially fail in a small way and use those failures as learning opportunities to drive the improvement of the system and the organization as a whole. So on to the lessons and tactics. First off I think what we want to see and the most effective organizations working in open shifts that we work with in consulting are those that have a very direct focus on their mission or business goal. Oftentimes we see particularly mental managers struggling to figure out how to translate new technology adoption into business value for their executive team. And oftentimes there's insufficient attention devoted to metrics that really matter. So these are things like deployments per day, mean time to release, things that reflect a growth in operational maturity. In replacement of those kinds of measures I think people at times fall back on short term time and cost metrics that don't always reward system level improvement and long term return on investment. And as a result this can compound problems with cultural alignment if there's more of a kind of blame type culture where mistakes are punished, creates a reductionist view on timelines and cost and I think inhibits organizational improvement as a whole. So what can we do to get past these problems? One tactic I think can help with this is something called impact mapping. And this is a tactic that the Red Hat Open Innovation Labs which is a time box residency program for process improvement that we offer to our customers. This is one of the tactics that the labs team has been really trying to promote among our customer audience. What it allows you to do is kind of visualize scope and underlying assumptions in a collaborative way with the rest of the stakeholders and technical contributors on the team. And the way it works is you start with your goal on the far left of this diagram. And that goal should be expressed as a specific metrics driven outcome that you're looking to achieve that expresses the answer to the question of why we're trying to do this. Big picture, highest level, you know, what are we trying to achieve with this project, with this new feature, with this program for container adoption. And only once you've expressed that clear goal do you start to proceed into actors. So these are individuals or roles that can contribute to achieving that goal. So you list all of your important actors who can produce the desired effect, who can potentially obstruct or inhibit or delay the fulfillment of that goal, who are your consumers and users. And then once you've defined your actors, start to think about impacts. How should our actors' behavior change? How can they help us achieve that goal or how can they delay us? List those and then finally, and only after you've started to fill out more of the rest of this diagram, do you turn to scope or deliverables or actual work products that you would like to see as part of the project. And what this does, it reverses the typical way that particularly technical stakeholders tend to address problem solving. When you get a bunch of engineers in a room together and you present them with a project or a proposal, they're going to tend to jump immediately to potential technical activities, deliverables, automation scripts, software code that can address that problem. And it's very easy to lose sight of the original high-level goal. And sometimes in fact, the business driver or financial determinant behind that project is never articulated. It's never adequately expressed. And without that, you can go off and chase all sorts of different technical options that potentially don't contribute meaningfully to the overall objective. So that's one tactic that I think can address the question of focusing on the business drivers or mission goals. Second, of course, and we see this in most large enterprises over time due to the need for functional specialization silos develop in those organizations that restrict our ability to communicate with people who are in some cases very directly involved in our day-to-day work. And we see this as a particular challenge in the container adoption program and enterprise-wide adoption of OpenShift where in the early stages of program execution, the focus is very much on operational maturity for the platform. So getting the platform installed, getting an understanding of what high availability means, disaster recovery, backups, storage integration, network integration. But the actual consumers of that platform are left as an afterthought or their involvement is delayed to a later stage of the overall program's delivery. And what we would like to do is to encourage our customers to resist the temptation to think of platform operations as separate from platform users. In fact, most of the time, platform operations can only be meaningfully defined with real users and real workloads. There are choices that you are going to make in the operational definition of the support and maintenance of the platform that you can only come to the correct decision on once you better understand the needs of your developer audience. So we really like to encourage customers to involve development teams early and start to push out, if possible, production releases of applications even before the platform itself is completely finalized and kind of complete. Those production releases may not have external customers hitting them or consumers. They may be internal only and may be fairly private. But begin to think in terms of supporting production workloads and begin to think of an iterative delivery life cycle even for infrastructure. And then going beyond kind of initial consumers of the platform, start to think about how to evangelize the platform to a wider development audience and build in program evangelism into the program itself. We also find at some point you'll have to start to think about how to incentivize adoption. We work with several customers who have made the mistake early on to think that the platform itself will just sort of naturally bring a developer audience to it because of some of the kind of natural advantages with container-based deployment automation and auto-scaling and orchestration, et cetera. But what we found is that nothing is quite so compelling as the status quo, right? If you can allow a development audience or a developer team to continue what they're doing with minimal impact, most times they will continue doing that. And so it's often a question of promoting those benefits and making those cost savings or technical benefits of the platform obvious to that developer audience to encourage them to move over. And that, of course, involves that same kind of cross-functional collaboration and silo breaking that we're talking about with this objective. So you saw a mention of the Container Adoption Program in the title for this presentation. And I want to make reference to that program, especially to note the importance of having parallelized work streams that address all of these areas, that can start to line up operational maturity, in synchronization with things like deployment automation, scaled app onboarding, process transformation, and work through those in agile increments so that all of these work streams are delivering real business value almost from day one in the project execution. I think in general what we want to try to avoid is what we call the big bang approach to IT development, where you're working internally behind closed doors in private for months and months and months, and finally you have a release date, six months, 12 months into the project, and then and only then do you start to get real users and real feedback on the system. And oftentimes what you find is the feedback tells you that you were working on the wrong thing all along, and you kind of have to go back to the drawing board to start over. The more you can get that feedback early in the project, the more you can involve developers early in the project, the better off you'll be. The other thing we recommend in terms of organizational alignment to support that objective is to start to reorganize in the following manner. So on the left hand side we have the before snapshot, many organizations have a constellation of application development teams who may interact with an application server team that's responsible for server operations. These might be web sphere administrators, Jboss administrators, and those individuals have a direct line of communication to an infrastructure operations group. And then that infrastructure operations group makes callouts to storage specialists and network specialists and other operational specialists in each of the domains. But what we'd like to start to encourage customers to think of is looser organizations of teams that involve cross functional collaboration and perhaps even communities of practice where you've got a platform as a service group composed of some individuals who come from server operations or application operations background, some individuals who come from a pure infrastructure background, and certainly at least one or two aligned resources from each of the application teams so that you can start to achieve greater feedback loops between your end consumers and the PAS working group as a whole. We do still divide up platform as a service from architecture, but that platform as a service role is very different from the traditional application server team. It's really infrastructure as expressed at an application platform level and thinking about the capabilities that you can create in the platform to make developers' lives easier and better. Third, we want to make sure that organizations are prioritizing the right applications and the right teams as part of this effort. So I think it's important to note that not all potential users are equal inside of an enterprise organization. It's really worthwhile to find the workloads and teams that have the most engagement and will derive the most benefit from transformed IT and a container-based cloud. So how can we go about doing that? What we've come up with is kind of a three-step portfolio assessment, a way of evaluating an application portfolio in order to narrow down your addressable market into a smaller audience that can have an immediate impact and help create return on investment for the investments that you've made in container technology. So step one, take a look at the portfolio and start to kind of understand a little bit more about the workloads that may not be good candidates initially for onboarding to the platform. By this, we're talking about things like mainframe applications, COBOL and Fortran that may be running on dedicated hardware, desktop applications that were maybe written against Windows desktop APIs with a Windows desktop user audience in mind. Those are probably not good candidates, at least for the container platform without significant redevelopment and rewriting. And then you've got a category of applications in the form of commercial off-the-shelf or COTS software that you may be purchasing from a vendor that doesn't have a development team associated with it in your organization. You don't own the source code or control the source code associated with those workloads. It's more like you get a package from the vendor. You deploy it to a server. It runs. If you have problems, you call the vendor. Those are probably hold candidates for OpenShift. So there may be opportunities to containerize those. But most likely you're going to have to collaborate and coordinate with a software vendor themselves to make sure that they're staying aligned and can support the containerized Kubernetes deployed version of that workload. And then databases, same kind of story. The database vendor or project owners may need to kind of reevaluate what deployment of that workload looks like in a containerized context. And there may be opportunities to do that. But if you're thinking about phase one showing success with the platform, what you really want to focus on is teams and projects whose source code you own, deploy, and maintain, so java.net, PHP, Python, Node, et cetera. Those are the ones that you want to kind of jump to. Every portfolio within that audience has a mix of application types. So you've got applications broken up by functional variation, UI, batch, API services. You've got applications with different system dependencies. You've got different technology choices. Within each of those applications, each workload is going to have varying business values. Some applications are, frankly, going to be contributing more to your bottom line. They're going to be contributing more in terms of opportunities for innovation, more to capture a larger customer audience and drive revenue to the organization. So you really want to focus on common types or patterns that also provide the most business value to the organization. And the larger the addressable portfolio you can cover with a particular archetype or pattern, the better. In addition, you want to make sure you're identifying application teams that have the enthusiasm and commitment to be early adopters of a new enterprise cloud platform. Because that's essentially what we're asking of them. Like any new technology cycle, you kind of have your early adopters, your late adopters, your kind of laggard type teams. And you really want to identify those teams that are willing to learn and those teams that are willing to work with your operational organization to work through the bugs and the feature enhancements to be able to get that level of service that you expect from a cloud type internal service provider. And then only once you've gone through that initial filtering do you start to look at analysis and prioritization of individual applications to establish level of effort, level of difficulty, level of prioritization around the kind of technical ideals for a cloud compatible workload. An automated code build process, for example. The ability to externalize configuration, not a lot of reliance on kind of fixed hard-coded IP addresses, rel compatibility, log management that is already set up to function effectively in an open shift setting. The reason for this is not because applications that don't have these characteristics can't eventually be onboarded to the platform. It's more like in early phase adoption you want quick wins, immediate success, and you want to generate momentum that those teams can then, such that those teams can promote the platform and the methodology to other application users in the organization and start to see your number of projects and number of pods and number of user counts start to increase the way we saw with the Protobon customer example earlier this morning. Fourth, start to challenge existing processes. In a lot of cases, cloud technology is new technology in the organization, and existing policies don't necessarily apply to dynamic infrastructure. So start to think about why your organization does the things the way they do them. Are those methods aligned to cloud computing, or do they date from an earlier era? How much of what you do is improving consistency, repeatability, and self-service, and how much is just keeping the lights on? The answers to these questions may lead you to things like infrastructure as code. So instead of overly focusing on getting infrastructure up and running and keeping it running, start to focus on what are the techniques and activities we can do to express everything we do as automatable code that can then be fed into an automation framework to reproduce that same activity at lower cost with greater efficiency. What we found is that the ROI on automation is very large, but not all organizations see it. And those that have a short-term project focus tend not to capture those opportunities. So tactically, what can we do to adjust our mindset? One thing to look at is maybe starting to do a five-wise retrospective. So a lot of organizations are continuing to employ things like end-of-sprint retrospectives to assess what worked, what didn't work, and begin to start planning for the next sprint. That can have an overlap with this notion of a blameless postmortem, especially when you're talking through things like outages and process failures. In that retrospective, start to look at opportunities for systemic improvement by graphically diagramming not just the immediate project shortcoming or failure, but examine the why behind what happened and the why behind that and the why behind that and the why behind that so that you can start to identify larger systemic improvements rather than just short-term fixes that may not do anything to enable the organization over the long term. And then finally, and this is, I think, problematic for a lot of organizations, but is worth noting, we tend to see, especially on the platform infrastructure side, that uniqueness and creativity is not always well-rewarded. So it tends to work better at the application layer, but when you're seeking to build utility-type public cloud capability in the organization, conformance to a standard architecture is probably the best choice. In general, the more unique your environment, the more unique are your errors. And the more complexity you introduce, the harder is to automate the provisioning process, deployment lifecycle, et cetera. So our guidance in a lot of cases is to try to resist platform customization unless you have a good reason to do it. In a lot of cases, older policy standards may not translate into a cloud context anyway. So the tactic to be able to address that is to practice destroying and recreating environments as needed on demand through the use of templatized installs and begin to sort of create an environment that mostly kind of matches standard reference architectures that you've seen from other customers at events like this, minimize integration with third-party components that kind of deviate from that standard unless there are very good reasons to do so, and then automate that process so that you can begin to stamp out additional instances of that same environment, say, in multiple data centers or maybe into the public cloud if you're using a non-premise type environment or vice versa. So again, I think in the interest of time, I will jump through some of the customer examples. We've got a great group of customers here today. Just to recap, digital transformation is cultural transformation. I think we all understand that the problem is culture is something that is difficult to just change directly. Culture is more like a byproduct of the practices that your organization is pursuing, and these are some practices that can help you, focusing on your business or mission goal, breaking the silos, prioritizing the right applications, challenging your existing processes, and avoiding unnecessary uniqueness, especially in the application platform or infrastructure layer. Thank you all very much for having me. Thanks for your time, and enjoy the rest of your day. Thank you very much. Thank you so much.