 I should put my sunglasses on. All right. Hello, everyone. Thanks for coming out. We're going to talk about digital transformation and a blueprint for survival. So we'll offer some insight into how you can leverage DevOps and some of the processes around people, processes, tools, and technology to make that transformation over to digital transformation, a much easier process. We'll go and introduce each other, and then we'll get right into the content. Hi, everybody. Thanks for coming. I'm Scott Bills with EMC Global Services, and I lead up our application transformation practice. Hi, I'm Bart Driscoll. I lead up our DevOps practice within global services. And I'm Jeff Olson. I'm an offer development lead in our global services cloud portfolio group. So when we think of digital transformation, we heard a lot about digital transformation and how it applies really in day one of this OpenStack Summit. And it's really important that we understand fundamentally what is driving digital transformation. What is some of these new paradigm shifts that are causing organizations to really adopt these new methodologies, new agile processes, and these new agile technologies to really help transform them. And when you think of it, it really boils down to four main pillars, which is mobile, cloud, big data, and social. And by the way that we're always being connected today is really that iterative process, that instant feedback, and having that information at our tips that really helps drive a successful transformation. But really what we'll get into further on is that technology isn't just necessarily end-all, be-all to really transform yourself. Things like DevOps and transforming your existing application portfolio are really important to that process. So really when organizations think about, well, what do I need to do to be successful? And how can I go down this path to really digitally transform? Really their main focus is they want to spot new opportunities, and not only spot new opportunities, but be able to help predict them as much as possible. And it's all about delivering that personal experience. So we all sit here on our phones throughout the day, and we're getting instant feedback, whatever we're interacting with. But really, in order to get those results back, a successful organization really has to be able to innovate in that agile way. You think about the long processes, and I think they talked about 44 days or 42 days, and the key one note wouldn't be possible in this new age where we're pulling this data instantaneously, analyzing that data, and giving it back to the customer, which really drives that I want to operate in real time. And at the same time, it's really being able to demonstrate that transparency and be able to trust that your data is secure as you're interacting with it and getting it back in real time. So like I mentioned before, it's broken down really applications where they're at your fingertips. Companies like Tesla, I think they're the first organization or first company where you could pretty much pre-order a car online. It's pretty amazing. I think we all probably in here might have a nest in our homes. And it all starts really with that application. But when you write these applications and when you're interacting with these applications, it's the data that you're collecting. And the data is help driving what you're going to do with that information, how you're going to analyze that information, and how you're exactly going to pass it back to improve on whatever information you're getting back to your end users. And really, by creating this type of cycle or this type of flow of bringing in data from your end users and analyzing and creating new insights, you're really focusing on creating speed. And it's all about that iterative process and speed to help you do that. But of course, there's definitely a challenge with digital transformation. I don't know if Bart, you wanted to go ahead and jump on this one. Yeah, sure, no problem. So one of the things that we find when we're working with customers around digital transformation is really this lack of a holistic vision. There are typically three key parts to digital transformation. One is around the data, a second being around customers, and then a third being around those internal processes that ultimately help enable you to actualize wins in that customer and data side. So without having this vision, it's actually really difficult to start building the right solutions on the back end in order to be able to support digital transformation. That kind of walks into the identifying the use cases. If you don't really understand your customer, whether it's an internal or external customer, it makes it really difficult to provide the correct services and the correct level of interaction with those services to those end users. We find one of the other common problems is a burden of technical debt. Most large enterprises have been around for 20, 30 years. They've got applications that are equally that old. And as a result, there have been a lot of decisions made, great ones at the time, that are slowing down or impeding how quickly you can add change. Part of its inflexible architecture is part of its very complex dependencies. And some of it is just old platforms that just aren't designed for this kind of new digital world. One of the other things that we see with digital transformation is that it's a very pervasive change in the organization. This isn't something that's just IT or just marketing or the business. It really touches all aspects of the enterprise. And as a result, it makes it really difficult to coordinate, particularly when you're looking at 17 or 23 different stakeholders that are all required to help make decisions in this process. And that leads to the last one here around organizational inertia. Change is hard. And for some people, it's downright scary. So introducing these new concepts and these new ideas takes time. You need to create that space and allow people to build trust in these new operating models and these new tools as you're starting to move towards digital transformation. So really getting to the meat and potatoes. Really, the blueprint we've laid out is you can think of it broken down into four main categories, starting from bottom left to right. And it really starts with having an agile infrastructure. Having something like OpenStack as your underlying infrastructure resources that can scale is really going to be that beginning point that you want to make sure that when you're developing these new applications or using a platform like Cloud Foundry or Pivotal Cloud Foundry that you can really start leveraging that developer ecosystem. So we'll start with agile infrastructure and we'll get into that developer ecosystem and then get into, OK, well, once you have these tools and have these technologies up and running, it really comes down to, well, then what? Just because you have these technologies installed and running doesn't necessarily mean you actually know how to use them. And it's really where that people in process comes into play around changing your culture by leveraging things like DevOps. But I think in the reality of it is is that a lot of organizations have these applications or existing applications that they need to leverage. So some of these, I think they call it mode one and mode two applications, that they want to leverage. Not every organization can start net new or start in a green field environment. So we'll get into how we help customers transform existing applications and integrate into existing tool chain and processes and so on and so forth. So agile infrastructure. So like I mentioned before, you can think of it as that baseline or that fundamental environment that you need to have up and running in order to allow everything above the stack or the abstraction layer to take advantage of. And when you think of things like agile infrastructure, you really want to have it programmable, which is you want to treat that infrastructure as code. You want to limit the amount of manual processes that you can bring into it. And you want to templatize as much as you can so that it can scale out automatically. Definitely want to have it as multi-tenant and multi-services. So what I mean by multi-services is that you can think of things like Amazon Web Services, right? When you just log in, you're not getting just compute. You're getting compute networking and storage resources. You're getting things like a developer platform. You're getting things like object storage. You're getting things like content distribution networks and so on and so forth. And these are all the different services that you want to leverage in an elastic-type way in order for you to take advantage of that underlying resource. And of course, it has to be economical, right? So commodity hardware, software-defined services, as well as leveraging open-source technologies is really going to help you understand where you're getting that value from. It doesn't make the most sense if you're spending a lot of money on some of these underlying infrastructures and you're kind of getting caught up in the procurement of resources as it moves through that purchase chain within that organization. And developer ecosystem. Sure. So sitting on top of that agile infrastructure is what we like to refer to as that developer ecosystem. And as you remember, I mentioned a little earlier, it's really all about knowing your customer. So developers really don't want to muck around in the storage and network layers of your data center. They would much prefer to be writing code, building new features, and getting those features out into production. So one of the things to consider as part of your digital transformation and as part of building out this set of services is understanding what it is developers need access to. Using a platform like Pivotal Cloud Foundry, you get a lot of really robust features out of the box around health monitors and container provisioning, as well as access to a bunch of frameworks that will actually enable developers to start writing code quicker. In the end, that's really what that developer ecosystem is all about. How can I provide my development and testing resources with the right tools and the right access to services like a database or a messaging layer without having to have them go and configure it? Basically it allows them to focus their attention on what they're truly interested in providing value. So kind of moving into the next phase, which is really talking about that cultural change through DevOps, I know it's already come up twice in this session, but during the keynote earlier, when they were talking about the company that made the big investment to improve their deployment cycle time and it went from 44 days down to 42 days. Everything that we've talked about so far is about implementing that tools, implementing those tools. If we're not thinking about how those tools are mapped to the process, the sets of processes that we use to develop and deploy code into production, then we're gonna have a lot of trouble with adoption and we're not gonna start to see the acceleration and throughput that we're really hoping to get through this transformation. So when we're talking about the cultural changes through DevOps, one of the key underlying tendencies automate everything. Automate your infrastructure provisioning, automate your deployment chains, automate your testing, automate configuring your monitoring systems. Really anywhere where there's a repeatable task that's happening as part of your software development lifecycle or your release management process, automate it. But it's not just writing scripts, right? We want these scripts to be managed by policy. Most large enterprises have strong enterprise architecture in governance program in place. We wanna make sure that some of the important assets in IP from those systems are embedded into the tool chains that we're building as part of DevOps. It's not about just going fast, it's about going fast but having confidence that what we're deploying is gonna service the needs of our customer. The extensible platform, so I talked a little bit about this on the slide before. This is really all about that ecosystem, understanding that complex portfolios are gonna require multiple tools to do the same thing. I'll probably use Jenkins Maven for a Java build and I would use MSBuild for .NET. Both tools do the same thing, but if I were to use MSBuild on a Java application, not so good, right? So we wanna be able to have that flexibility to support multiple tools, recognizing that we're gonna have these complex portfolios. I think another key cultural change with respect to DevOps is this concept of transparency. For most large enterprises, the software development lifecycle and your release management process is a black box. Requirements kind of go in six months later, something comes out, you hope it works, it gets deployed to production, breaks a few things, everybody spends a long weekend fixing it and then you get it into production and people start using it, right? DevOps wants to kind of take the cover off that and really give you some transparency into how changes move through the process, how long each step takes, what's the success rate of each of these different steps so that you can start collecting data around where to best make investments moving forward with respect to implementing new tools and optimizing your processes. DevOps is really focused on value, so it's based on Lean, it's based on Agile, which have both been around in IT for a while, but the whole goal is, is how can we create value faster? It's not how can I write code faster? It's not how can I create an environment faster? It's how can I bring all of these disparate pieces together and create a working application in production that will create value for the enterprise as whole? And it does this by using highly collaborative and cross-functional teams. The goal isn't to make generalists across your entire enterprise, the goal really is how can I bring that expertise and that experience together to build a solution that's really gonna address the needs of the organization? So we do talk a lot about tooling with respect to DevOps and it is a really important piece because really without it, it's really difficult to accelerate. But one of the things that we wanna make sure that we're careful of is that when we're building and selecting tools is that we're creating tools that are gonna be able to work and integrate with each other. It's all about that API library. So I do wanna create a common workflow or pipeline that will manage change, whether it's an infrastructure change or an application change, and then I wanna be able to integrate tools into that pipeline to be able to accelerate that end-to-end flow. All right, so when we think about digital transformation, there's the pieces around tooling, culture, DevOps that we talked about, but one of the biggest challenges, a lot of our larger enterprise clients in particular face is what to do with the existing portfolio. And how do you leverage DevOps, microservices, continuous delivery release models to unlock value from the existing portfolio? So if you think about your typical enterprise, they'll have a whole set of legacy monolithic applications built on really high-cost, old platforms, which is a problem, but at the same time, there's a lot of IP that's been developed over the years that are in those applications that you want to unlock as well. So a big part of the challenge for digital transformation is taking a look at your portfolio and figuring out what do you wanna put into a transformed DevOps-type model. It seems relatively straightforward, but take a financial services, global financial services institution, for example, they're gonna have consumer apps, they're gonna have commercial apps, they're gonna have trading apps, they're gonna have core financial systems. Not all of those are applicable or appropriate for a DevOps-type model or will have the same value derived from continuous innovation and leveraging those types of tools and processes. So a critical first step is taking a look at the existing portfolio and figuring out where DevOps can really help you unlock value. And when you're talking about application portfolios and the thousands across both COTS and bespoke applications, that's typically a non-trivial task. And one of the first steps that we see organizations that are really aggressive about digital transformation doing is taking a look at that portfolio and figuring out where the value really exists from digital transformation. So if you take a look at new app development, of course you're gonna want to leverage DevOps and PAS and microservices to develop your applications in a new way, that's really a no-brainer, right? But the question on what you do with the existing portfolio tends to be a little bit more complex and involves a whole set of issues around the business importance, the business criticality of the app, how it's implemented, how it's deployed, the cost of the platform, strategic importance of the app going forward, the usage demographics, a whole set of factors that will lead you to take an application and say, you know what, it might make sense to actually modernize and rewrite this using a DevOps kind of transformed process. Others that may make more sense just to migrate, kind of lift and shift as is to cloud platform or infrastructure as a service environment. Others you want to retire, and some you may just want to keep as is, but maybe expose a little bit differently to other applications or leverage a data fabric to transform those applications in a little bit different way. But in any case, the key is to understand really what the sources of value are for transforming, understand where the value might be in your portfolio and then really think about what an appropriate attractive strategy is for transforming the existing portfolio as part of your broader digital transformation effort. So I guess really before kind of closing, we just wanted to share a case study that we've been working with a customer on. This is one of the, actually this is the largest global bank, they currently have got over 30,000 IT professionals working, seven different divisions supporting over 6,000 application development projects. And this customer has a problem. Despite their size and their success, they're realizing that their ability to generate revenue costs more than it does their competitors. So basically they're not as profitable as they'd like to be. So the company has made a very significant investment in developing some new products and new customer channels in order to drive some new revenue, but at the same time, they're really taking a laser focus internally around operational efficiency. How can they start to drive down that net operating cost? So we started working with the bank in early 2015. And what we've been doing with them is first aligning a lot of their key stakeholders around what their development and delivery practices are. And taking a closer look at what some of the tools do with respect to infrastructure automation, continuous integration and continuous delivery. And where we've started is by building out a pilot, a pilot continuous delivery pipeline. And we're starting to build out a framework that's gonna integrate some of the infrastructure automation services that they're building as part of infrastructure provisioning and management work stream. And the whole goal here is to really embed the tools from both of these work streams together in an active development project. And part of the reason that we're trying to embed it in part of an active development project is so as this development project progress, we can start capturing some proof points around where these technologies are working, how we're embedding them with the teams, what some of the new practices, processes and methods are that we're developing. And we can begin to embed them in the global software delivery management program, which is a much larger top-down initiative to simplify operations and reduce risk at the bank. What we've been doing with them to date is providing coaching services, technical experts and some implementation services to really help build out that initial pilot and start training local internal champions that are gonna help radiate this solution as we move forward. Interestingly enough, the bank, like a lot of the customers that we work with, kind of had an early realization when we started doing our advisory service with them and that was that they really weren't good at doing software development. They wanna be more like a modern software development company, even though they're huge. And so what we've been able to do is kind of systematically work through some of those problems and create a framework for addressing them by both introducing infrastructure automation tools and practices and integrating those with some software development tools and practices. So pretty much wraps it up for today before you go. If you wanna learn more about what we're doing around the digital transformation space, definitely come visit us at the booth. Also, these two guys, not including myself, have some great blog posts on our EMC Global Services in Focus webpage. Highly suggest you take a look at it when you have time. They've write some great things around many of the topics that we've covered today, both around DevOps, around agile technologies, as well as transforming application portfolios. So what we'll do is we'll close it out here, we'll open up to questions, and I know we do have a raffle for an Echo, correct? Yeah, Amazon Echo. Amazon Echo. So we're going to- And we just have one. And we just have one. So does anyone have any questions for you? Do you have like some sort of upfront assessment process that you use, like kind of going in, like if the clients don't already know exactly what they wanna do, which is probably most of the cases, where you determine like which aspects of these transformation elements, how and where they apply, like some sort of a regular structure kind of assessment approach. So are you talking about from an infrastructure or from a DevOps perspective or kind of the whole big picture? Cause we do. Like is any of it, yeah, like where you start to determine the opportunities and the applications, how to come in and what to recommend and stuff. Sure, yeah. So really that type of service that those capabilities that you just mentioned is really how we try and help our customers. So the reality is our customers are learning this just as much as some of the vendors are. So we wanna help our customers through that entire journey, not just about selling them technology, it's not just about standing up that technology, but it's really helping advise them, what is the right strategy they need to be looking at to make that informed decision. So really we have a set of advisory services that range from on the infrastructure level, you know, things like OpenStack and PCF or CF all the way to kind of the DevOps side of things. So we'll work with the customer and really kind of gauge where they're at from a maturity perspective. And once we can gauge where they're at from a maturity perspective, whether we need to address it more at the infrastructure layer or certain technology at the infrastructure layer or further up the stack, we're gonna help that out or help the customer kind of see that journey through. And then we can take that all the way through, deploying that specific solution or product to even helping manage it if they don't have the skills or the cycles that do it themselves. Yeah, I think one thing I'd add to that is we do have some really kind of lightweight, early workshops up front that are fairly broad in scope that are really designed to help map out your current maturity as it relates to modern application development and digital transformation. We also have another one around IT, general IT transformation. And so both of those can kind of provide that baseline to make that determination on what's the best next step. Do we wanna focus more on DevOps? Do we wanna focus more on infrastructure automation, et cetera? Any other questions? Shook, floor is all yours. Oh, mine. All right. Who wants to pick? You wanna pick, I'll pick. Last three numbers, five, four, four. Five, four, four. Come on down. Oh, I read that backwards. Cool, there you go. Enjoy. All right, thanks a lot, everyone. Take care and enjoy the rest of your time here in Austin.