The next BriefingsDirect DevOps innovator case study discussion explores how Hewlett Packard Enterprise’s (HPE's) internal engineering and IT organizations are exploiting the values and benefits of DevOps methods and practices.

To help us better understand how DevOps significantly aids in the task of product and technology development, please welcome James Chen, Vice President of Product Development and Engineering at HPE. The discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: First tell us a little bit about the scale of the organization. Clearly HPE is a technology company, has a very large internal IT organization, perhaps one of the largest among the global 2000.

Chen: We have a pretty sizeable IT organization, as you can imagine. We support all the HPE products and solutions serving our customers. We have about 8,000 to 9,000 employees, and we have a pretty large landscape of applications, something like 2,500 enterprise-scale large applications.

We also have a six data centers that host all the applications. So it's a pretty complicated infrastructure. DevOps means a lot to us because of the speed and agility that our customers are looking for, and that’s where we embarked on our journey to DevOps.

Gardner: Tell us about that journey. How long has it been? How did you get started? Maybe you can offer how you define DevOps, because it is a little bit of loose topic in how people understand it and define it.

Chen: We've been on the DevOps journey for the last couple of years. A certain part of the organization, the developer team, already practiced somehow, somewhere, in different aspects of DevOps. Someone was driving the complete automation of testing. Someone was doing a kind of Continuous Integration and Continuous Delivery (CICD), but it never came down to the scale that we believed would start impacting the overall enterprise application landscape.

Some months ago IT embarked on what we called a pilot program for DevOps. We wanted to be the ones doing DevOps in HPE, and the only way you can benefit from DevOps and understand DevOps -- the implications of DevOps on the IT organization -- is just go out and do it. So we picked some of the very complicated applications, believing that if we could do the pilot well, we would learn a lot as an organization, and it would be helpful to the future of the IT organization and deliver value to the business.

We also believed that our learning ad experiences could help HPE’s customers to be successful. We believe that every single IT shop is thinking about how they can go to DevOps and how they can increase speed and agility. But they all have to start somewhere. So our journey would be a good story to share with our peers.

Inception point

Gardner: Given that HPE has so many different products, hardware and software, what is that you did to find that right inception point. You have a very large inventory of potential places and ways that you could start your DevOps journey. What turned out to be a good place to start that then allowed you expand successfully?

Chen: We believed the easiest way was to start with some of the home-grown applications. We chose home-grown applications because it’s a little bit easier, simply because you don’t have the scale of vendor/ISP dependence to work with.

We decided to pick a handful of applications. Most of them are very complicated and some of them are very important. A good example is the OneNote application. This is the support automation application, which touches every device, every part that we ship to our customers. That application is essentially the collection point for performance data for all the devices in the customer data center, how we monitor them, and how we deal with them.

It’s what I consider a very important enterprise scale application and it’s mission critical. That was one of the criteria, pick an application that is really complicated and most likely home-grown. The other criteria was to pick an application that the application team itself already practiced, were ready to do something, and really wanted to embrace that new methodology and new idea.

The reason behind that is that we didn't want to set up a separate team to do DevOps to pair with the existing the developer team. Ideally, we wanted the existing developer team to go into that transformation. They became the transformation driver to take the old way to do DevOps into the new DevOps. So that was second criteria, the team, the people themselves had to be motivated and get ready for a change.

The third one was the application scale and impact. We understood the risk and we understood the implications. The better understanding you have, it's easy to get buy-in from your business partners and your executive team. That’s what we chose as the criteria as far as going into DevOps.

Gardner: I'm really curious. Given this super important application for HPE, how is performance measured and managed across all of these deployments, applying DevOps methodology, and getting that team buy-in? What did it earn you? What’s the payoff? What did you see that made DevOps worthwhile?

Chen: With DevOps we captured three dimensions. One is collaboration. What I mean by collaboration is taking operations into development and taking development into operations, so the operations and development teams are working side-by-side. That’s the new relationship of the collaboration.

The traditional way you did this was by the developer finishing the product and then throwing it over the wall to the operations guy. Then, when something goes wrong, we start freaking out, asking who owned the issue.

The new way is a very close collaboration between the development team and operations. From the get-go, when we start to design a product or software application, we already have people who are running the operation. They run the support in the team by understanding the risk and the implications for the operation. So that’s one dimension, the collaboration.

The second piece is about automation. You want to figure out a way that you can automate end-to-end. That’s very important. You asked a very good question about how to get buy-in from your business partners who ask, "I'm going to do CICD. What is the implication if something goes wrong?"

Powerful weapon

Automation has become a very powerful weapon, because when you can automate development, the deployment process becomes much easier to roll back when something goes wrong. Because that’s a small incremental change that you're making every time, the impact is much easier to understand. We believe the down time is much less than the normal way of doing the process. That’s the second dimension, automation.

The third one is codification. Codification is that everything is code. The old way was to define your infrastructure and have someone manually put all the infrastructure together to run an application. Those times are over.

Full DevOps is that you are able to drive a code that’s easy to configure, have your infrastructure provisioned based on that code, and get ready to run an application.

So DevOps consists of those three things. It’s truly important, the way we talk about it and the way we understand DevOps: collaboration, the codification, and automation.

Having said that, there are other implications about the organization and contingency. Those have a very profound impact on our IT organization. That’s where we understand DevOps and we're using that kind of methodology. Our thinking is to take it to the stakeholder and the customer, and show them the benefit that we're able to deliver for them. That’s the reason we get the buy-in support from the get-go.

Gardner: Is speed the number one reason to do this, or is it quality or security? What is the biggest reward when you do this well?

Chen: Speed is probably the number one reason to go to DevOps. Of course the quality, high availability, and agility have significantly improved. But I would really focus on speed, because if you ask any business owner, business partner, or your customer today, the number one challenge for them is speed.

Early in our conversation, I mentioned about automation. Traditionally we do a release every six months, because it's so complicated, as you can imagine. We have products from storage, network, server – hardware and software. If we make platform changes, in order to cover all those customers, devices, and products, it required pretty much six months to do.

Since you have the six month cycle, products issued to your customer before the next release will not have the best support on the host automation capability.

The performance of our service quality has a significant impact on customer satisfaction. Now we're talking about a release every two weeks. That’s a significant improvement, and you can see customers are happy because now with every product release, they have the automation capability within two weeks. You immediately have the best monitor and proactive care capability that we provide to our customers.

Bottom line

Gardner: I should think that that also has an impact on the bottom line, because you're able to bring new features and functions to the market, add more value to the products, and then charge more money for it. So, it allows you to get the value of your organization in to your bottom line although faster as well.

Chen: Yes. For example, we want to deliver any product or service that has a call-home capability, do the support automation, and proactively take care of them, within two weeks.  It's a huge advantage for us, because the competition typically take a few days to a couple of weeks just to install everything.

That two weeks is probably the best timing optimized for this kind of service scheme. Can we push this to one week or a few days? It's possible, but the return on investment may not be on day one.

For every application, when you make the call about DevOps, it’s not about wanting to do it as fast as possible. You want to examine your business case and determine, “what’s the sweet spot for us with DevOps?” In this particular case, we believe that looking at the customer feedback and business partners' feedback, two weeks is the right spot for us. That's significantly better than what we use to have, every six months.

You may also be interested in: