How Sprint Employs Orchestration and Automation to Bring IT into DevOps Readiness

Transcript of a BriefingsDirect discussion on how Sprint leverages IT infrastructure orchestration and automation to accelerate DevOps as a strategic IT force-multiplier.

Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Dana Gardner: Hello, and welcome to the next edition of the HP Discover Podcast Series. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator for this ongoing discussion on IT innovation and how it’s making an impact on people’s lives.

Gardner

Our next DevOps innovation case study explores how telecommunications giant Sprint places an emphasis on orchestration and automation to bring IT culture and infrastructure into readiness for cloud, software-defined data center (SDDC) and DevOps.

We'll learn how Sprint has made IT infrastructure orchestration and automation a pillar of its strategic IT architecture future. Let's find out how by welcoming Chris Saunderson, Program Manager and Lead Architect for Data Center Automation at Sprint in Kansas City, Missouri. Welcome, Chris.

Chris Saunderson:  Thank you, Dana. Very glad to be here.

Gardner: I'm intrigued by your emphasis on working toward IT infrastructure, of getting to more automation at a strategic level. Tell us why you think automation and orchestrations are of strategic benefit to IT.

IT automation is an urgent priority
Automation and orchestration can pay huge dividends
Read the report

Saunderson: We've been doing automation releases since 2011, but it came out of an appreciation that the velocity of change inside that data center is just going to increase over time.

We look it at as journey. We have to go to dark old days pre-2009 -- really pre-2006 for us -- where the conversation was all around standardizing. I'm going to have standard systems, and we're going to employ in this way, and they'll be racked this way. We looked at that and said, "It’s not really got a lot of legs to it."

Saunderson

You have the virtualization revolution of 2003. We had been VMware since 2003 getting into more virtualization technologies on the other platforms that we have. But in 2009, my boss and I sat down and said, "Look, this is going nowhere. We're not going to make a significant enough impact on the way that the IT division works ... if we just keep doing the same thing."

That’s when we sat down and looked at what the landscape looks like. We could see the orchestrated data center coming. I encapsulated it as the "data center of things." When you look at the journey that most enterprises go through, right around 2009 is when the data center of things emerged. You then began to lose track of where things are, what they are, who uses them, how long they’ve been there, and what their state is.

When we looked at automation and orchestration in 2009, it was very solidly focused on IT operational efficiency, but it had the longer-term view that it that it was going to be foundational for the way we do things going forward, if for nothing else than to handle the data center of things. We could also see changes coming in the way that our IT organization was going to have to respond to the change in our business, let alone just the technology change.

Gardner: So that orchestration has allowed you to not only solve the problems of the day, but put a foundation in place for the new problems, rapid change, cloud, mobile, all of these things that are happening. Before we go back to the foundational aspects, tell us a little bit about Sprint itself, and why your business is changing.

Provider of choice

Saunderson: The Sprint of today ... We're number three, with aspirations to be bigger, better, and faster, and the provider of choice in wireless, voice and data. We're a tier 1 network service provider of global IP network along with private network, MPLS backbone, all that kind of stuff. We're a leader in TRS -- Telecommunication Relay Services for the deaf.

The Sprint of old is turning into the Sprint of new, where we look at mobile and we say mobile is it, mobile is everything -- that Internet of Things (IoT). That's what we want to foster growth. I see an exciting company that’s coming in terms of connecting people not only to each other, but to their partners, the people who supply services to them, to their entertainment, to their business. That’s what we do.

Gardner: So in order for your IT organization to be responsive to this fast-changing corporation you had to take some steps. Let’s go back to that notion of IT orchestration. When you started that journey for automation -- getting out of those manual processes and managing complexity, but repeatedly getting the manual labor out of the way -- what have you learned that you might relate to other people? What are some of the first things people should keep in mind as they embark on this journey?

Saunderson: It’s really a two-part answer. Orchestration comes after automation, because orchestration is there to consume the new automation services. So let’s take that one first. The big things to remember is that change is hard for people. Not technology change. People are very good about doing technology change, but unwiring people’s brains is a problem, and you have to acknowledge that up-front. You’re going to have a significant amount of resistance from people to change the way that they're used to doing things.

Orchestration comes after automation, because orchestration is there to consume the new automation services.

Now addressing that is also a human problem, but in a certain sense, the technology helps because you're able to say things like, "Let's just look at the result and let's compare what it takes to get to the result. Was it the humans doing it, and what does it take to get to the result with the machines doing it?" Let’s just call it what it is. It’s machines doing things. If the result is the same, then it doesn't require the humans. That’s challenge number one, unwiring people’s minds.

The second is making sure that you are articulating the relevance of what you’re doing. We had an inbuilt advantage, at least in the automation space, of having some external forces that were driving us to do this.

It’s really regulatory compliance, right? Sarbanes-Oxley (SOX) is what it is. PCI is what it is --  SAS70, FISMA, those things. We had to recognize the excessive amount of labor that we were expending to try and keep up with regulatory change.

PCI changes every year or 18 months. So it's just going through every rule set and saying, "Yes, this doesn’t apply to me; I'm more restricted." That takes six people. We were able to turn that. We were able to address the requirement to continue to do compliance more effectively and more efficiently. Don’t lose that upward communication, the relevancy thing -- which is not only are we doing this more efficiently, but we are better at it?

When you get to orchestration, now you’re really talking about some interesting stuff because this is where you begin to talk about being able to do continuous compliance, for example. That says, "Okay, we used to treat this activity as once a quarter or maybe once a month. Let's just do it all the time, but don’t even have a human involved in it." Anybody who has talked to me about this will hear this over and over again. I want smart people working on smart things. I do not want smart people working on dumb things. Truth be told, 99 percent of the things that IT people do are dumb things.

Orchestration benefits

The problem with them is that they're dumb because they force a human to look at the thing and make a decision. Orchestration allows you take that one level out, look at the thing, and figure out how to make that decision without a human having to make it. Then, tie that to your policy, then report on policy compliance, and you're done.

The moment you do that, you’re freeing people up to go have the harder discussions. This is where we start to talk about DevOps and this is where we start to talk about some of the bigger blocks that grind against each other in the IT world.

Gardner: Continuous is very interesting. You use the PCI compliance issue, but it's also very important when it comes to applications, software development, test, and deploy. Is there anything that you can explain for us about the orchestration and automation that lends itself to that continuous delivery of applications? People might not put the two together, but I'm pretty sure there's a connection here.

IT automation is an urgent priority
Automation and orchestration can pay huge dividends
Read the report

Saunderson: There is. DevOps is a philosophy. There was a fantastic discussion from Adobe where it was very clear that DevOps is a philosophy, an organizational discussion. It’s not necessarily a technology discussion. The thing that I would say, though, is that you can apply continuous everywhere.

The successes that we're having in that orchestration layer is that it's a much easier discussion to go in and say, "You know how we do this over here? Well, what if it was a release candidate code?" The real trick there, when you go back to the things that I want people to think about, is that DevOps is a philosophy, because it requires development and operations to work together, not one hand off to the other, and not one superior to the other; it’s together.

If they’re not willing to walk down the same path together, then you have an organizational problem, but you may also have a toolset problem as well. We're an Application Lifecycle Manager (ALM) shop. We have it there. Does it cover all of our applications? No. Are we getting all of the value out of it that we could? No.

But that’s because we're spending time in getting ready to do things like connect ALM into the running environment. The bigger problem, Dana, is that the organization has to be ready for it, because your philosophical changes are way more difficult than technical changes. Continuous means everything else has to be continuous along with it.

If you're in the ITIL model, you’re still going to need configuration items (CIs). How do CIs translate to Docker containers? Do they need to be described in the same way? If the operations team isn't necessarily as involved in the management of continuously deployed applications, who do I route a ticket to and how do they fix it?

This is where I look at it and say that this is the opportunity for orchestration to sit underneath that and say it not only has the capability to enable people to deploy continuously -- whether it’s into test or production, disaster recovery, or any other environment.

To equip them to be able to operate the continuous operation (that’s coming after the continuous integration and development and deployment), that has to be welded on because you’re going to enforce dis-synergy if you don’t address it all at the same time as you do with integration and deployment.

Gardner: Let’s look at some other values that you can derive from better orchestration and automation. I'm thinking about managing complexity, managing scale, but also more of the software-defined variety. We are seeing a lot of software-defined storage (SDS), software-defined networking (SDN), ultimately software-defined data center (SDDC), all of which is abstracted and managed. How do you find the path to SDDC, vis-à-vis better orchestration and automation?

At the core

Saunderson: Orchestration is going to have to be at the core of that. If you look at the product offerings just across the space, you’re starting to see orchestration pop up in every last one of them -- simply because there's no other way to do it.

RESTFul APIs are nice, but it’s not enough because, at that point, you’re asking customers to start bolting things together themselves, as opposed to saying, "I'm going to give you a nice orchestrated interface, where I have a predefined set of actions that are going be executed when you poll that orchestration to make it work and then apply that across the gamut."

SDS is coming after SDN. Don’t misunderstand me. We're not even at the point of deploying software defined networks, but we look at it and we say, "I have to have that, if for no other reason than I need to remove the human hands out of the delivery chain for things that touch the network."

We should never lose sight of the fact that the whole reason to do this is to say, "Deploy the thing."

I go back to the data center of things. The moment you go to 10Gbit, where you are using virtual context, just anything that’s in the current lexicon of new networking as opposed to VLANs, versus all that stuff, switchboards, etc., you’re absolutely losing visibility.

Without orchestration, and, behind that, without the analytics to look at what's happening in the orchestration that’s touching the elements in your data center, you’re going to be blind. Now, we’re starting to talk about going back to the dark ages. I think we're smarter than that.

By looking at orchestration as the enabler for all of that, you start to get better capability to deliver that visibility that you’re after, as well as the efficiency. We should never lose sight of the fact that the whole reason to do this is to say, "Deploy the thing."

That’s fine, but how do I run it, how do I assure it, how do I find it? This keeps coming up over and over. Eventually, you’re going to have to do something to that thing, whether it’s deployed again, whether you have some kind of security event that is attached to it, or the business just decides not to do it any more. Then, I have to find it and do something to it.

Gardner: Given your deep knowledge and understanding of orchestration and automation, what would you like to see done better for the tools that are provided to you to do this?

Is there a top-three list of things you’d like to see that would help you extend the value of your orchestration and automation, do things like software-defined, do things like DevOps as a philosophy, ultimately to be have more of a data-driven IT of strategic operation?

Development shop

Saunderson: I'm not sure I have a top three. I can certainly talk about generic principal stuff, which is, I want open. That’s what I really want. Just to take the sideline for a second, it’s fascinating. It’s just absolutely fascinating. IT operations is starting to become a software development shop now.

I'm not resistant to that in the least because, just in this conversation, we've been talking about RESTFul APIs and we were talking about orchestration. None of this is IT operations stuff. This isn’t electrons flowing through copper anymore. It’s business process translated into a set of actions, open, and interoperable.

Then, just give me rich data about those things, very rich data. We’re getting to that point, just by the shear evolution of big data, that it doesn’t matter anymore. Just give it all to me, and I will filter it out to what I'm looking for.

Gardner: The thing that is interesting with Hewlett Packard Enterprise (HPE) is that they do have a big-data capability, as well as a leading operations capability and they're starting to put it all together.

Saunderson: In the same way the orchestration is starting to pop up everywhere. If you look at the HPE product portfolio and you look at network coordination, it’s going to have an operations orchestration interface into it. Server automation is welded into operations orchestration and it’s going to appear everywhere else. Big data is coming with it.

Server automation is welded into operations orchestration and it’s going to appear everywhere else.

I'm not hesitant on it. It's just that it introduces complexity for me. The fact that the reporting engine is starting to turn big data is good. I'm happy for that. It just has to get more. It’s not enough to just be giving me job results that are easy to find and easy to search. Now, I want to get some really rich metadata out of things.

Software-defined network is a good example. The whole open flow activity just by itself looks like network management until it goes into a big-data thing and then suddenly, now I have a data source that I can start correlating events to that turn into actions inside the control that turns into change on the network. 

Let’s extend that concept. Let’s put that into orchestration, into service management, or into automation. Give me that and it doesn’t have to be the single platform. Give me a way to anticipate HPE’s product roadmap. The challenge for HPE is delivery.

Gardner: Before we sign off, one of the important things about IT investment is getting the buy-in and support from your superiors or the other aspects of your enterprise. Are there some tangible metrics of success, returns on investment (ROIs), improvements and productivity that you can point to from your orchestration, not just helping smart people do smart things, but benefiting the business at large? 

Business case

Saunderson: So organizations often only do the things that the boss checks. The obvious priorities for us are straight around our business case.

If you want to look at real tangibles, our virtual server provisioning, even though it’s the  heavyweight process that it is today, is turning from days into hours. That’s serious change, that’s serious organizational cultural change, but it’s not enough. It has to be minutes not hours, right? 

Then there's compliance. I keep coming back to it as this is a foundational thing. We're able to continue to pass SOX and PCI every time, but we do it efficiently. That’s a cultural change as well, but that’s something that CIOs and above do care about, because it’s kind of important.

One gets your CFO in trouble, and the other ones stops you taking payments. That gets people's attention really quickly. The moment you can delve into those and demonstrate that not only are you meeting those regulatory requirements, and you're able to report all of them and have auditors look at it and say yes we agree, you are doing all those things that you should be doing.

IT automation is an urgent priority
Automation and orchestration can pay huge dividends
Read the report

Then, you can flip that into the next area which is that we do have to go look at our applications for compliance. We have rich metadata over here that was able to articulate things. So let’s apply it there.

Gardner: I'm afraid we will have to leave it there. We've been learning about how Sprint has made IT infrastructure orchestration and automation a pillar of a strategic IT architecture in the future. And we have heard how Sprint has gained through its emphasis on orchestration and automation by bringing an IT culture that is about readiness and compliance and speed.

So please join me in thanking our guest, Chris Saunderson, Program Manager and Lead Architect for Data Center Automation at Sprint in Kansas City, Missouri. Thank you, sir.

Saunderson: Thank you, Dana.

Gardner: And a big thank you to our audience as well for joining us for this DevOps and orchestration and automation case study discussion.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this ongoing series of HPE-sponsored discussions. Thanks again for listening, and come back next time.

Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Transcript of a BriefingsDirect discussion on how Sprint leverages IT infrastructure orchestration and automation to accelerate DevOps as a strategic IT force-multiplier. Copyright Interarbor Solutions, LLC, 2005-2015. All rights reserved.

You may also be interested in:

• How fast analytics changes the game and expands the market for big data value
• How HTC centralizes storage management to gain visibility and IT disaster avoidance
• Big data, risk, and predictive analysis drive use of cloud-based ITSM, says panel
• Rolta AdvizeX experts on hastening big data analytics in healthcare and retail
• The future of business intelligence as a service with GoodData and HP Vertica 
• Enterprises opting for converged infrastructure as stepping stone to hybrid cloud 
• Redcentric orchestrates networks-intensive merger using advanced configuration management database
• HP pursues big data opportunity with updated products, services, developer program
• How eCommerce sites harvest big data across multiple clouds 
• How Localytics uses big data to improve mobile app development and marketing 

Discover Case Study: Sprint Gains Better Control and Efficiency in IT Operations with Business Service Management Approach

Transcript of a Briefings Direct podcast from HP Discover 2011 on how Sprint reduced application sprawl and resources redundancy using Business Service Management from HP.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: HP.

Dana Gardner: Hello, and welcome to a special BriefingsDirect podcast series coming to you from the HP Discover 2011 conference in Las Vegas. We're here on the Discover show floor the week of June 6 to explore some major enterprise IT solutions, trends and innovations making news across HP’s ecosystem of customers, partners, and developers.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions, and I'll be your host throughout this series of HP-sponsored Discover live discussions. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

Our latest case study focuses on Sprint. We'll learn how Sprint is doing applications and IT in a better way. It's going on a journey to simply and automate, reduce redundancy, and develop more agility as a business solutions provider for their customers, and also their own employees.

So we have two executives from the IT organization at Sprint, Joyce Rainey, Program Manager of Enterprise Services at Sprint. Welcome.

Joyce Rainey: Hello.

Gardner: We're also here with John Felton, Director of Applications Development and Operations at Sprint.

John Felton: How are you?

Gardner: I'm great. Tell me little bit about the beginning of your journey. It seems that you've come a long way, and we'll get into that, but what was the state of affairs that led you to recognize that things needed to change?

Felton: The problem that we had originally had, as any large organization has, were many applications, many of them custom built, many of them purchased applications that now are so customized that the vendor doesn’t even know what to do with it anymore.

We grew those over a long period of time. We were trying, as a way to stabilize, to get it into a centralized, single point of truth and quit the duplication or the redundancy that we built into all these applications.

The goal, as we set forth about a year-and-a-half ago, was to implement the ecosystem that HP provided, the five toolsets that followed our ITIL processes that we wanted to do. The key was that they were integrated to share information, and we'd be able to take down these customized applications and then have one ecosystem to manage our environment with. That's what we've done over the last 14 months.

Gardner: Joyce, what was the goal you had in mind when you started this process?

Making it easier

Rainey: Simplification. We had too many of the same. We had to make it easier for our internal support teams. We had to made it easier for our customers. We had to lessen the impacts on maintenance and cost. Simplification was the key of the entire journey.

Gardner: When you looked at the issue of redundancy, was this about data, applications, network nodes, all the above, or were there certain aspects that you went to first, the low-lying fruit, to reduce that redundancy?

Felton: I'd say it would be all. We had to concentrate on not only making sure that the applications base wasn't duplicated, but also the data. The data is where we ended up having issues. One person's copy may not be as accurate as another person's copy, and then what we ended up spending an enormous amount of time saying whose was right.

What we did was provide one single point of truth, one copy of the truth. Instead of everybody being hidden from the data, we allowed everybody to see it all. They may not be able to manipulate it and they may not be able to change it, but everybody could have visibility to the same amount of information. We were hoping they would stop trying to have their own version of it.

Our biggest culture problem was that everybody wanted to put their arms around their little piece, their little view. At the end of the day, having one view that is customized, where you can see what you want to see, but still keeping the content within a single system, really helped us.

Having one view that is customized, where you can see what you want to see, but still keeping the content within a single system, really helped us.

Gardner: Just to be clear for our listeners, when you say, data, are you talking about the data about the IT systems themselves or the data that is within and it's being supportive of the applications, or perhaps both?

Felton: It's all that. It's the data that supports the application. It's the servers that host the applications. It's the third-party applications that deliver the web experience, the database experience, the back-end experience. It's the ability for us to associate fixed agents to that particular information, so that when I am calling out the fixed agent for an alarm, I'm getting the right person online first, versus having a variety of individuals coming on over time.

Gardner: So, you have some goals about eliminating redundancy in your tools and in your data. You needed to create the single source of truth and you needed to integrate other IT support capabilities in order to get to this automated ability.

What were some of the cultural or organizational issues that you hit? We can talk about technology, but you also have to look at people. They are part of this process. Joyce, how did you look at that and how did you solve that?

Rainey: We continued to work on it. Adoption is a big key in any transformation project. One of the things that we had to definitely look at was making sure that facts can prove to people that their business requirements were either valid or invalid. That way we stop the argument of what do I want, versus what do I need?

A lot of education

We really had a lot of communication, a lot of education along the way. We continue to educate people about why we do this and why we're doing it this way. We engage them in the process by making them part of the decision-making, versus just allowing the tools to dictate whether you can do it.

With the tools, you can do whatever you want. However, you want to customize the product, but should we and for what purpose? So, we had to introduce a lot of education along the way to make sure folks understood why we were going down this path.

Gardner: You've done this fairly quickly, a year and a half. It could be long for some people's horizon, but to me that's a very fast transition of this nature. What is it that was the tipping point that got people to say, "Okay, I'll give up a little bit of my turf, because I'm going to get something else in return?" What was it that they got in return that made this work?

Felton: First of all, we implemented in 12 months. It was 14 months to get the future enhancements of the data quality and all the things we're working on right now. But as to the tipping point, I think the economy had a lot to do with it, the environment that was going on at the time.

You had a reduction in staff. You had downsizing of companies. It made it harder for individuals, to Joyce's point, to protect an application that really had no business value. It might have a lot of value to them, and in their little piece of the world it probably was very valuable, but how did it drive the overall organization?

The economy in any kind of transformational program is a key factor for investing in these kind of products. You're going to make sure that if you're introducing something it's because you're going to add value.

Dan Hesse did a great job in coming in and putting us on a path of making sure that we're fiscally responsible. How are we improving our customer expectations and how are we moving in this direction continuously, so that our customers come to us because we're best provider there could be? And our systems on the back end needed to go that way.

So, to Joyce's point, when you brought them in, you asked "Does this help that goal?" A lot of times, no. And, they were willing to give a little bit up. We said, "You're going to have to give a little bit up because this is not a copy/paste exercise. This is an out-of-the-box solution. We want to keep it that way as much as possible, and we'll make modifications, when we need to to support the business." And, we've done that.

Gardner: So this wasn't nice to have. This really had to happen.

Rainey: Absolutely. The economy in any kind of transformational program is a key factor for investing in these kind of products. You're going to make sure that if you're introducing something it's because you're going to add value. You're going to grow. You're going to mature. For us at Sprint, we want to make sure that we can stop some of the maintenance, the redundant maintenance, when we need to concentrate our resources in the right area.

Having new integrated solutions, bringing our development teams together, we can work under one umbrella. We can deliver more collateral investments across the organization. We can train everyone on many different things, so they are not just siloed like we had before. We were able to retire many products with the introduction of these systems.

Gardner: People are quite familiar with Sprint, but I saw some of the numbers are very impressive. Help us understand the size and scope of applications, customers, and retail outlets.

12,000 servers

Felton: There are thousands of outlets, retail stores. We have our third-party customers as well, like Best Buy and RadioShack. We have about 12,000 servers, about five petabytes of storage. We serve about 39,000 customers internally at Sprint.

We host all that information to make sure that we process about a million change records a month. That information that we're capturing are configuration items (CIs). The actual content that goes in the system was, at one point, in the 24 million range. We dialed that back a little bit, because we were collecting a little too much information.

We have about 1,300 applications that were internally built. Many of those are hosted on other external vendor products that we've customized and put into Sprint. And, we have about 64,000 desktops. So, there is a lot going on in this environment. It's moving constantly and that goes back to a lot of the reasons why, if we didn’t put this in quickly, they'd pass us by.

Gardner: So, for that single version of truth for what's going on in your IT organization with this very significant massive scale, how did you start that journey? What came in handy to start that and where have you taken it?

Rainey: It's important to recognize that data is data, but you really derive information to drive decision making. For us, the ability for executives to know how many assets they really have out there, for them to concentrate their initiatives for the future based on that information, became the reason we needed our data quality to really be good.

It's important to recognize that data is data, but you really derive information to drive decision making.

So, every time that somebody asked John why he went after this product suite, it was because of the integration. We wanted to make sure that the products can share the same information across them all. That way, we can hold truth through that single source of information.

Gardner: What were the products you used and how did that "whole greater than the sum of the parts" come about?

Felton: We started with [IT] asset management. Asset management was really the key for us to understand assets and software, and how much cost was involved. Then we associated that to Universal Configuration Management Database (UCMDB). How do we discover things in our environment? How many servers are there, how many desktops are there, where they at, how do I associate them?

Then we looked at Business Service Management (BSM), which was the monitoring side. How do I monitor these critical apps and alarm them correctly? How do I look up the information and get the right fix agents out there and target it, versus calling out the soccer team, as I always say? Then, we followed that up with Release Control, which is a way for our change team to manage and see that information, as it goes through.

The final component, which was the most important, the last one we rolled out, was Service Manager (SM), which is the front door for everybody. We focus everybody on that front door, and then they can spin off of that front door by going into the other individual or underlying processes to actually do the work that they focus on.

Early adopter

Gardner: And the latest version of BSM from HP came out right about the time you were starting this. So, you were, in a sense, an early adopter, aggressive. You weren't tentative in using this suite of products from HP?

Felton: We'll even go so far as to say that we were the only one. For just BSM in itself, I'm very proud of our team. We had [another product] in 2009. We went to Business Availability Center (BAC) January 2010. HP said they had this new thing called BSM 9. Would we take it? We said sure, and we implemented it in March of that year. We took three upgrades in less than five months.

I give a lot of credit to that team. They did it on their own. There were three of them. No professional services help and no support whatsoever. They did it on their own, and I think that’s pretty interesting how they did that. We also did the same thing with UCMDB. We are on the 8x platform, about halfway deployed, and HP said they'd like us to go to 9x, and so we turned the corner and we said sure.

We did those things because of the web experience. Very few people on my team would tell you that they were satisfied with the old web experience. I know some people were, and that’s great. But, in our environment, as big as it is and as many access points as we had, we had to make sure that was rock-solid.

And, 9x for all those versions, seemed to be the best web experience we could have, and it was very similar, if I'm looking at BSM. Drop-downs and the menus, of course, are all different, but the flow and the layout is exactly the same as SM, and SM is exactly the same as CMS.

We got a nice transition between the applications that made everything smooth for the customer, and the ability for them to consume it better.

We got a nice transition between the applications that made everything smooth for the customer, and the ability for them to consume it better. I'll go so far as to say that a lot of my executive team actually log into BSM now. That would have never happened in the past. They actually go look up events that happen to our applications and see what's going on, and that’s all because we felt like that platform had the best GUI experience.

Gardner: So, it's a system of record for other systems of record that presents a singular view that a business executive can get to, and enjoy and not be faced with too much technology, but get the right information at the right time.

Rainey: Absolutely. And, if you get your CEOs and your VPs and your directors consuming and leveraging the products, you get the doers, you get the application managers, you get the fix agents, you get the helpdesk team, because they start believing that the data is good enough for decision making at that level of executive support.

Gardner: When you have good data, when you know what it is that your IT organization is comprised of, consists of, and when you can start to eliminate redundancy, be more agile, what do you get? What are some of the metrics of success that you’ve seen?

Felton: We wanted reduction in our [problem resolution time] by 20 percent. Does that really mean you get a reduction? No, it means you get out there, you fix it faster, and the end-user doesn’t see it. By me focusing on that and getting individuals to go out there, and maybe more proactively understanding what's going on, we can get changes and fixes in before there was a real issue. We’re driving towards that. Do we have that exact number? Maybe not, but that’s the goal and that’s what we continue to drive for.

Removing cost

Additionally the costs are huge, having 35 redundant systems. We removed a lot of maintenance dollars from Sprint, a lot of overhead. A lot of project costs sometimes are not necessarily tangible, because everybody is working on multiple projects all at one time.

But, if I've got to update five systems, it's a lot different if I update one, and make it simpler on my team. My team comprised about 11 folks, and they were managing all those apps before. Now, they're managing five. It’s a lot simpler for them. It's a lot easier for them. We’re making better decisions, and we make better changes.

We’re hoping that by having it that way, all of the infrastructure stability goes up, because we’re focused. To Joyce’s point, the executive team pays attention, managers pay attention, everybody sees the value that if I just watch what this thing is doing, it might tell me before there is a customer call. That is always our goal. I don’t want a customer calling my CIO. I want the customer to call my CIO and for him to reply, "Yes, we know, and we’re going to fix that as fast as we can."

Gardner: Maybe it's a bit too soon, but do you have any figures as to what your operational budget has done? What the impact has been?

Rainey: We implemented six months ago, so we’re still going through some of our maturity process. We do know for a fact that the operational cost of those 35 applications removed from the environment was able to be diverted to some other areas of investments, so we can go ahead and repurpose that money into other spaces that we need to start investing in.

We’re hoping that by having it that way, all of the infrastructure stability goes up, because we’re focused.

Gardner: How about the whole help desk function? How has that been impacted?

Felton: Six years ago that help desk had 400 people. As of today it has 44. The reason it does is that we bypass making calls. I don’t want you to call a fix agent to type a ticket to get you engaged. We came up with a process called "Click It." Click It is a way for you to do online self-service.

If I'm having an Exchange problem, an Outlook problem, or an issue with some application, I can go in and open a ticket, instead of it being transferred to the help desk, who then transfers it to the fix agent. We go directly to the fix agent.

We’re getting you closely engaged, hoping that we can get your fix time faster. We can actually get them talking to you quicker. By having this new GUI interface it streamlined it through a lot of wizards that we can implement. Instead of me having seven forms that are all about access, maybe now I have one. Now, there is a drop-down menu that tells me what application I want it for. That continuous improvement is what we’re after, and I think we’ve now got the tools in place to go make that easy for us.

Gardner: And here at Discover, there have been some awards HP has delivered, and you got one. Tell me a little bit about that, Joyce?

Rainey: I am very proud, very proud of Sprint. I'm very proud of the team. I'm very proud of the executive support that we received throughout this journey. The HP Excellence Award was a very big milestone for everyone to remind us that it was well worth it, the time that was spent, the energy that was spent. I'm very glad that HP and our customers have been able to recognize that.

Felton: I'm also very proud of the team, as well, and we also won the CIO 100 Award. So, we’ve been able to take the same platform and the same kind of journey and show a much larger audience that it really was worth it. I think that’s pretty cool.

Gardner: So, you have a little bit of 20/20 hindsight. If I were another organization, a CIO, and I was listening to this podcast, what would you tell me in terms of learning or doing something differently? What's the view from where you are upfront?

Importance of speed

Felton: I think speed. I wouldn’t do it slower. I think 12 months, even though it was very ambitious, helped us, because you didn’t take the focus off of it. You got it in and nobody tried to replace it.

What I might do differently is spread it out a little more, do smaller increments of implementation, versus all at one time. Don’t do the Big Bang Theory. Put in BSM, but always know that it's going to integrate with SM, and SM is going to integrate with CMS, and CMS is going to integrate with AM.

Then, build that plan, so that you integrate them. You get your customers involved in that particular application, and then when you go at the very end and put SM in, this the front door. They’re already familiar with what you’ve already done. That is something we probably didn’t do as well as we could have. It was more of a Big Bang approach. You put it in and you go.

But, at the end of the day, don’t be afraid to re-look at the processes. Don’t necessarily assume that you’re going to copy what you did today. Don’t assume that that is the best way to do it. Always ask the question, what business value does it address for your corporation? If you do that over, and over, and over, individuals will quit asking, because if you ask, these platforms are very flexible.

You can do anything. But when you get them so customized that the vendor can't even help you, then every upgrade is painful, every movement that you make is painful. What we’ve done has given us the flexibility to clean up a lot of stuff that was left over from years ago, an approach that may have not been the best solution, and given us an avenue to now extend and subtract without putting a huge investment in place.

What we’ve done has given us the flexibility to clean up a lot of stuff that was left over from years ago.

Gardner: I have to imagine, too, that this has given you a little bit better perception in terms of IT’s role and value. Have you gone from zero to hero, or is that overstating it?

Rainey: I think it's a little overstating. We need to realize that it's all about incremental improvements. I know that on day one, not everybody was as excited as we were by implementing the product, but along the way we’ve proven that the data quality is better, decision making is better supported. Hopefully we’re starting to create a bigger and more attractive user community that trust that this system is going to do the right things for us.

Felton: One other thing is that we had a really good idea of, "This is our business. Run it that way. You are a part of Sprint." We try to say, "We’re going to make investments that also benefit us, but don’t do them just to do them, because in this space as you look out on that floor and see all the techno wizards that are out there, shiny objects are pretty cool, but there are a lot of shiny objects."

We wanted to make sure that the shiny object we produced is something that was long lasting and gave value back to the company for a long period of time, not just a quick introduction.

Gardner: Well, great. We’ve been hearing about how Sprint has undergone a significant journey in improving their IT operations, their efficiency, getting a grip on their assets, even shifting the culture to improve not only the business’ bottom line, but really the value of IT generally throughout the organization.

I’d like to thank our guests. We’ve been joined by Joyce Rainey, Program Manager of Enterprise Services at Sprint. Thank you.

Rainey: Thank you very much for having us.

Gardner: And also John Felton, Director of Applications Development and Operations at Sprint.

Felton: Thank you again. I really appreciate the time.

Gardner: And thanks to our audience for joining this special BriefingsDirect podcast coming to you from the HP Discover 2011 Conference in Las Vegas. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this series of User Experience Discussions. Thanks again for listening and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: HP.

Transcript of a Briefings Direct podcast from HP Discover 2011 on how Sprint reduced application sprawl and resources redundancy using Business Service Management from HP. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• HP's Robin Purohit unpacks Business Service Management 9 as way to address complexity in hybrid data centers
  
• HP delivers applications appliance solutions that leverage converged infrastructure for virtualization, data management
• HP takes plunge on dual cloud bursting: public and-or private apps support comes of age
  
• HP rolls out EcoPOD modular data center, provides high-density converged infrastructure with extreme energy efficiency
• HP at Discover releases converged infrastructure products and services aimed at helping IT migrate rapidly to the future
  
• HP's IT Performance Suite empowers IT leaders with unified view into total operations, costs
• Deep-Dive Discussion on HP's New Converged Infrastrcture, EcoPOD and AppSystem Releases at Discover