Jaynene Hapanowicz – Turn Up The Volume Of Your Deployment Keynote
How Dell Technologies transformed its Developer Experience to deploy more efficiently and frequently.
Transcript
Now for our next speaker, this next speaker will share insights and lessons learned from her experience leading a very large and successful DevOps transformation. I am very happy to introduce Jaynene Hapanowicz. She's the senior vice president of technology sorry, Technology Transformation for Dell Digital.
T. organization that supports Dell. Jaynene is leading a massive transformation effort at Dell to create an industry leading developer experience within a multi cloud framework.
Jaynene. Hello, everybody, thank you for having me at the GitLab Commit Virtual conference, I am Jaynene Hapanowicz with Dell Technologies. I lead the Technology Transformation Organization for Dell Digital.
We are going to spend a few minutes today talking about Dell digital transformation, our digital transformation and how we actually crack the code and going from it being a conversation about digital transformation to actually doing it. As you look at Dell Digital and you look at our scale and our size, we're a pretty big company. We have about one hundred and forty five thousand users, roughly just about 3000 applications.
We processed twenty four million orders a year. We have 22 data centers. We are almost entirely virtualize, as you would expect.
One hundred and sixty petabytes of storage, two hundred nineteen thousand Dell digital managed devices. So as you really look at our setup, we're pretty we're a pretty large organization. And really the thought process around how do you pivot in organization of this size is something that I want to share with you today.
And I hope that that is helpful. And I will explain a little bit about how we got there and the role that CI/CD pipeline actually has played for us as part of that transformation. So I am I am lucky enough to be in a position at Dell Digital where I am called into a number of customer engagements, almost two to three engagements a week, and they're mostly with large and corporate, you know, large customers.
And the reason I'm bringing this up is because I think what's so interesting to me is we have these conversations is that these conversations tend to be the same across all companies. Um, some of the questions that we get and hopefully this is helpful, as you guys are thinking through how you're going to do your digital transformation is how does your leadership behave in this type of transformation? What's the role that culture has in that?
Talk to me a little bit about projects to product and why does that even matter? What's the role the KPIs play in a transformation? I get asked a lot about like, how did you pivot an organization, how do you lay out the vision and the mission to get people on board with that?
What are the foundational elements to it in terms of your infrastructure and in terms of your development tools? How does architecture change? What's the Dell Digital way?
Have your application developers bought into the process and how do they work with the infrastructure teams and what your org structure looks like? What is your org structure look like? These are all things that I would say we are very consistently asked, and I'm going to attempt to answer most of these questions as we go through the presentation so that I can help you frame up your own transformation.
This is not something that I think you haven't heard before, but I think it has to ground the conversation. This change is about three really core tenets, and that's people process and technology. I'm going to start over to the right first, because I think the greatest news of this time in terms of a digital transformation is that the technology is awesome.
I've been around IT and in IT for almost 30 years. I think over the past three years is the first time I've ever seen that the technology works and it does what it says it's going to do. So the technology piece to this from a technology point of view is the best part of it.
The process piece to it is a heavy lift. It is a change in your business process and your IT process. But I think the most difficult part of this entire conversation is around the people transformation.
And we're going to spend a little bit more time on that, probably unexpectedly. But that is the part that you have to crack the code on and your cultural shift is super important in probably 2016. We really recasted it the way that we knew the culture needed to to shift.
And we called the Dell Digital Way, which is the combination of people process and technology. And and this is how we kind of restarted the thinking in the organization and what we want it to be through this transformation. The product model, like do not underestimate the value that the product model has in this transformation, because what that gets you is a customer centered approach.
And any company that is great at delivering services to their customers looks at it from a customer point of view out, not from a company point of view out. It has to be outside in, not inside out. That is really a foundational element to the change.
So I think the culture that you you think about in your company, the tone you set from a technology perspective is critically important. So, like, how did we get there? How did we get there?
That is a great question. And I will tell you, Number one, this is a journey. This is not a sprint.
We've been at this probably very steady since 2016. And I think we've learned a lot along the way. We've made a lot of mistakes along the way and we've gotten great outcomes along the way.
So I would say as we look at our maturity relative to many other companies, you know, I'm proud to tell you that a couple years ago we were probably with the pack. Today, I think we have actually evolved to a point where we are we are approaching that we're going to be leading. And, you know, I think the the maturity that I hear from customers is very much bucketed into a couple of categories.
There are a lot of companies that are still trying to figure out how to do this. There is a middle of the pack that is in the beginning stages of it. The later part of the pack, which is a handful of companies, has really cracked the code on it.
I think the big concern from every customer especially is part of this global pandemic. And what has kind of all happened to us very quickly is there's a big concern that when you come out on the other side, there's going to be a few companies that have cracked the code on how technology drives the business. And those companies are going to come out of this stronger.
And I think that is why many, many companies right now are very, very concerned about where they are in their journey and what you have to do to get there. So for us, I'm going to start on the right hand side of the slide and I'm going to talk a little bit about what were the drivers and what were the core core principles and the standards we call them. We call them our standards, best practices and guidelines, our guiding principles.
On the top right is this is not lip service like we truly believe this. We automate everything. Automation is the cornerstone to what we're doing.
Everything is code. The industry's been talking about this for a long time. But this is really this is the fundamental shift and this is a fundamental shift when we talk a little bit about infrastructure as code and how that integrates with the pipeline, that's a game changer.
API first you have to start there like you have to start with APIs being the way that your products are talking to each other to get to independent deployments and then self-service, self-service, self-service. I think the public cloud providers have done a remarkable job in creating great experiences for developers. But that also has to happen because their workloads that are never going to the public cloud, there's workloads that belong on Prem, there's data that belongs on Prem, and you've got to create great, great experiences for your developers.
Now, as you think about the standards that you're going to map through here, like what does that look like? Where do you start? Well, you know, we've got standards around how we're going to modernize our applications, how we're going to do development processes, what our development language standards look like.
In a cloud native world, we've defined how we're going to map to 12 factor, and we not only have defined it, but we also are measuring that within our pipeline, which is something we'll talk about in a couple of minutes. Domain driven design and event driven architecture are key components, automated databases that are virtualize, managing your APIs through marketplace. A single marketplace was big for US security, security, security, security.
This is about security because the standards that we build through the pipeline in the integration's to the pipeline get us to a great position in terms of security and then following and defining and following your reference architecture. Those are all big things that in our minds are non-negotiable points. And then the key to this whole process is really how we're managing integrations, which we're doing that with our pipeline.
And so whether that is managing our backlogs or requirements, automating change and release is huge for our company. That is a big administrative time waste. The process is good.
The way we went about it is what was difficult for our folks. Code repository, knowing where your code is and integrating that in is big automation through the pipeline, having your artifacts in a single place, code quality scanning and security scanning like that get you a consistent experience. And then having observability where you're logging and monitoring in a consistent way is very important.
So these are things that you have to think about. You have to map, you have to have strategies for and have to build. If you look on the left hand side of this folder, why are we doing this?
Well, we went into this with the stated objective that that we needed to really get a much greater level of productivity from our developers because they're good developers. But we were wasting a lot of time with them on things that were administrative tasks. And so in order to solve the problem, which was to grab 30 to 50 percent more productivity and giving our developers more time to write functional code, which gets you the speed, which increases your transformation, you know, we had to understand what they do and how what they do maps to the platforms that we manage on their behalf and the integrations that we've built into the platform.
So, you know, you start with kind of the top right hand side and you think about the aspects of planning which planning up front get you great results on the back. Not doing the planning on front is why a lot of the frantic behavior starts on the back end. So it is really writing your test cases, building to a cloud, native architecture, those things that you would expect to see using infrastructure as code, putting the right tools out there.
And as you kind of go along the right hand side of the circle, it's how you're doing provisioning and doing provisioning in a consistent way. It's how you do your builds and ensuring that your builds are done, you know, with assets, with GitLab and into our into our pipeline continuous integration. That's where I talked about before, where we've gotten from a maturity perspective, whether that's building 12 factor validation into our pipeline security reviews.
We do that through a couple of different tools, one of them of which is check marks. But we use checkmarks and we use four to five for certain things. We use blackbox.
So we've got a certain group of tools that we use which that will vary depending on what you're running in your environment. We've got code review and unit testing and then we do the build within our pipeline. And then you look at what's happening from a deployment perspective.
And, you know, we've written our test cases, we're writing our code, we're pushing our code, we're testing it in the pipeline. We're pushing it through staging and we're pushing it into acceptance that all is happening in an automated way and then operating, which is, you know, the way that we get our observability and we are doing our monitoring and logging, it's all happening in a very consistent way, which is how you get to KPIs, which tell you what your maturity looks like. So all of these things all need to work together and they need to be a well thought through plan.
But there are some foundational elements that I don't want to miss because I think that at the very bottom of this, you've got to have some pieces in place in order to even get to the next thing. And for us in this journey really started probably back in 2016, you know, having a cloud platform, having your infrastructure, a service, having your past platforms. For us, it's it's pivotal container services and and pivotal cloud foundry, being able to bounce out to the public cloud for the appropriate workloads, having the capabilities within your cloud that can move your workloads around.
Those are all things that don't happen. You know, by a miracle, that's hard work, right. That is just downright driving a new platform that applications can run on that give you the capabilities you need.
And then as you kind of move up the stack, there's there's standard ways that you're doing your operations which make things far more efficient. But I think if you go to the very top of the stack and you look at the self-service capabilities, we've really doubled down. We really doubled down a couple of years ago on creating self-service everything like we didn't talk about it.
We just we did it right. We've created platforms that our developers interact with where they basically have all all capabilities are built as a service. So what does that include?
That's where the right hand side of the slide really helps you walk. Walk down what we're talking about. We've got an API marketplace, which we launched early last year.
First time in our company's history. We've ever had all of our APIs in a single place. We score them, we throttle them, we rate them.
So it's really it's it's when I said API first, we mean API first. And you've got to have the tools in place to do that. We've built caching services as a service.
We've built messaging databases, registering repository security as a service and then application and monitoring as a service. So that is actually key as we get to the next slide, which is where we will start to talk about how all these pieces fit together to give you a great outcome for your development community. So now this is where I think the companies really, you know, GitLab has been a real cornerstone to to the success that we've had.
And that is, you know, is the pipeline for the company. It's the pipeline we've consolidated our services to. So, you know, if you go back a couple of years ago, we probably had eight to ten different ways that we were deploying into pipeline.
And we made the decision within Dell that we were going to, in fact, consolidate onto a single pipeline. And so if you look to the left, that's the developer in and, you know, the the pipeline in the gray boxes obviously GitLab. But like, we provide services to our developers that really are around cloud native templates and traditional and packaged app templates.
And the reason we provide that service in my team, in the DevOps team is because this really has facilitated the move to pipeline. It has created it in a standard standardized way. And we've really made this experience as easy as possible for our developer so that each developer didn't have to figure this out on their own.
And then you look at some of the other capabilities that we deliver through our DevOps team, and that's really environment management and licensing support and tool support. We provide test automation capabilities. We provide data management, which is a big deal for us and everybody else, and then broker services.
And then if you go between the blue box and the green box, that's really where our infrastructure is. Code practice is ramping up through the pipeline. And so think about it this way.
When a developer's interacting with us, they're basically releasing their code and they're moving all the way through to the green boxes. And what does that get you? That gets you experience for your development team that is basically releasing code and building infrastructure is the exact same thing.
So that's really one of the the major efficiencies that we've gained through the process. And then on the bottom half of the screen, the reason we put the dotted line there is because this actually represents if a developer is not 100 percent in pipeline, we have still provided self-service capabilities through a portal that a developer can go in. And even if they, you know, do some code deployment through pipeline, they still need to build infrastructure.
They can do that directly engaging with the as a service offering. So it's like all of this, it's not wasted effort. It all needs to be put in place.
So. Ok, now this is probably the most exciting slide in the presentation, because what this really shows you is how we're using the pipeline and, you know, the top but the top slide, it's a lot in the here is really about the maturity of the development teams. And so this is where I think the standards we have built.
Standards we're measure claims against the standards. We're exposing information that our leadership team has never had before. We're measuring the success of teams that are doing development through our pipeline.
Are they running security, scanning our artifacts all in a central place? Are they doing testing before deployment? Are they SOX compliant?
Is there change management approach automated? This is information that we've never seen before, at least in a standardized way, in a consistent way for all of our applications. And then if you look on the bottom part of the screen, those are just examples of where we've run the pipeline and we score on the activities that we deemed are important.
And teams get a pass, pass, fail, pass, pass, fail. And then we've built capabilities into our pipeline, which basically say this is what you need to do in order to pass. And so we've really put out a developer's fingertips, all the information that they need to really get to a better outcome.
We also worked with GitLab as part of this entire approach, and they've been great partners with us to really build out a platform that supports, you know, twenty five thousand, you know, users. And we've moved that onto our private cloud and we've gotten great results with that. And the type of things just to kind of reiterate, like the things that we've built in the integrations that we've built into the tool are really around.
You know, it's change and release. It's security scanning. It's deploying into our infrastructure, using some of our infrastructure as code pipelines.
It's vault management, security and vault management so that our secrets can be handled in a consistent, automated way. Artifact management. We support blue green deployments.
So like if you think about all of the work that comes into our pipeline, this is a game changer for our developer. So why does it matter? Well, for us it matters because we are grabbing a huge chunk of their time and we're refocusing that time on development work.
And what does that mean? While that means that we're able to move at a much faster pace than what we used to do. If you think about some of the measurements early on in our journey, you know, if you go back seven years ago, took a 72 days to get infrastructure, took you six months to deploy an application, now it takes you 30 minutes to get infrastructure and it takes you a week to deploy an application, I mean, even for complex builds.
And that's where it's really a game changer. Finally, I think a couple more points is just our volume on this is increasing exponentially. We're on track to run five to six million pipeline runs a year.
I think we're at less than a million last year. So you look at the adoption that tells you that this really is working for our developers. We manage six hundred applications within our pipeline, which is a subset of what we talked about before.
But it's a journey. As I said earlier, the integrations have been a huge game changer in terms of our standardization or security posture, our understanding of what our teams are doing. And I think you cannot underestimate really what you get from a security and compliance perspective.
It's right in front of us and it's information at the fingertips of all of our leaders lastly. So I think we're smarter for our experience. We have certainly taken an iterative approach and I would recommend the same to you.
There is no Big Bang theory here. This is really about progress, progress, progress, make mistakes, learn from your mistakes, keep going forward, focus on the future. This is where I think it's really important that you take your teams along the journey with you.
Teams have to see how they fit into the future or they resist. This is where the people part of this conversation, which also leads into the next bullet, give them a vision for the future. Tell your people how they're going to get there and define that, define their path or work with them on defining the paths they know they're part of it.
That is how people start to jump on the bus and help you on the journey. If you don't do that, what happens is you talk about change and then you've got your pockets of resistance. And that really don't participate, and that is where I think a lot of companies get tripped up.
So I do think this does boil down ultimately to people helping to drive the change. One of the things that we always say within Dell is that if you're in technology, you really need to be curious about technology. We're changing so fast.
Everything is changing so fast. If you don't have a natural curiosity about technology, it's really hard to fake it. And I think that that's something that we try to find people that are just genuinely interested about jumping to the next phase and driving to a better and more efficient outcome.
And then last but not least, finish the journey. Finish the journey. We call it that at other companies I've worked at.
It's, you know, corporate attention deficit disorder is a real thing. You've got to have people that are grounded on where you start and how you're going to finish and finish the journey strong. So that's what we have for you today.
I hope that that's helpful in terms of how Dell has gone on this journey and the progress we've made. Thank you.