Dana Gardner's BriefingsDirect: Unum Group architect charts a DevOps course to a hybrid cloud future

Tuesday, September 10, 2013

Unum Group architect charts a DevOps course to a hybrid cloud future

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: HP.

The next edition of the HP Discover Performance Podcast Series highlights how employee benefits provider Unum Group has been building a DevOps continuum, and is further exploring the benefits of a better process around cloud-assisted applications development and deployment.

To learn more about how they've been using certain tools and approaches to improve their applications delivery, we sat down with Tim Durgan, an Enterprise Application Architect at Unum Group, and Petri Maanonen, Senior Product Marketing Manager for Application Performance Management at HP Software.

The discussion, which took place at the recent HP Discover 2013 Conference in Las Vegas, is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

Here are some excerpts:

Gardner: Let's talk a little bit about what's important for your company. You're a large insurer. You're in the Fortune 500. You're one of the largest employee benefits providers in the U.S. and you have a big presence in the UK as well. What are some of the imperatives that have driven you to try to improve upon your applications delivery?

Durgan: Even though, as you said, we're one of the largest employee benefits providers in the United States, we began to realize that there were smaller companies starting to chip away in segments of the market.

Durgan

It became imperative to deliver products more rapidly to the market, because delivery was a multi-year effort, which was unacceptable. If it took that long from concept to delivery, there would be a completely new market dynamic at play.

We started to look at application architectures like service-oriented architecture (SOA) to deliver agility, process automation, and rules automation -- all very mainstream approaches. We discovered pretty quickly that to use those approaches effectively you needed to have a level of governance.

Governance initiative

We had an SOA governance initiative that I led and we brought in technology from HP to aid us with that. It was the Business Service Management (BSM) suite of tools, the Systinet Repository, and some partner products from HP.

What we discovered very quickly is that in enterprise architecture, where I am from in the company, bringing in an operational tool like monitoring was not hailed as, "Thanks for helping us." There was this organizational push back. It became very clear to me early on that we were operating in silos. Delivery was doing their efforts, and we would throw it over the wall to QA. QA would do their job, and then we would ultimately move it out to a production environment and operational aspects would take over.

It really dawned on me early on that we had to try to challenge the status quo around the organization. That's what started to get me focused on this DevOps idea, and HP has a number of products that are really allowing that philosophy to become a reality.

I have a couple of principles that I use when I talk about DevOps, and I try to use titles for these principles that are a little disruptive, so people pay attention.
For instance, I'll say "eliminate the monkeys," which essentially means you need to try to automate as much as possible. In many companies, their development process is filled with committees of people making decisions on criteria that are objective. Machines are very good at objective criteria. Let's save the humans for subjective things.

We want to put a product out quickly, but if it's going to fail, we would love to know it's going to fail very quickly, not make millions of dollars in investments.

That's what I talk about when we say eliminate the monkeys, get people out of the middle. It's really interesting, because as an architect, I recognize the automation of business process. But somehow I missed the fact that we need to automate the IT process, which in a lot of ways, is what DevOps is about.

Another principle is "fail fast." If you're going to deliver software fast, you need to be able to fail fast. As an example that I presented here at the conference last year -- which I knew most of the HP people loved -- was Palm. I'm sure they wished they had failed faster, because that was a pretty painful lesson, and a lot of companies struggle with that.

Unum does. We want to put a product out quickly, but if it's going to fail, we would love to know it's going to fail very quickly, not make millions of dollars in investments.

Another one is visibility throughout. I will say monitoring is a team sport. In a lot of companies, there are 50 or 60 monitoring tools. Each team has a monitoring tool. You have to have a secret decoder ring to use each monitoring tool.

While diversity is normally a great thing, it isn't when it comes to monitoring. You can't have the ops guy looking at data that's different from what the developer is looking at. That means you're completely hopeless when it comes to resolving issues.

Working collaboratively

My last one is "Kumbaya." A lot of IT organizations act competitively. Somehow infrastructure believes they can be successful without development and without QA and vice versa. Business sees only IT. We are a complete team and we have to work collaboratively to achieve things.

So those are really the ways I think about DevOps at the company.

Gardner: Petri, when you hear words like "process automation for IT" and a common view of the data across IT groups, it must be music to your ears?

Maanonen: Oh, sure. And the team has been very accurately capturing the essence of how DevOps needs to be supported as a function and of course shared among different kinds of teams in silos.

Maanonen

If you look at HP, we've been supporting these various teams for 15 years, whether it has been testing a performance of an application or monitoring from the end-user perspective and so forth. So we've been observing from our customers -- and Unum is a brilliant example of that -- them growing and developing their kind of internal collaboration to support these DevOps processes. Obviously the technology is a good supporting factor in that.

Tim was mentioning the continuous delivery type of demands from the business. We have been trying to step up, not only by developing the technology, but actually bringing very quickly supportive software-as-a-service (SaaS) types of offerings, Agile Manager and Performance Anywhere for example. Then, customers can quickly adopt the supporting technology and get this collaboration and a DevOps cycle, the continuous improvement cycle, going.

Gardner: When you said Kumbaya, obviously this is about getting people to see the vision, buy into the vision, and then act on the vision. So tell me a little bit more, Tim, about the politics of DevOps.

We are a complete team and we have to work collaboratively to achieve things.

Durgan: I think the problem that a lot of companies have, and Unum as well, is that unfortunately we all have individual expectations and performance. We all have a performance review at the end of the year and we have things that we need to do. So it is, as you mentioned, getting everybody to buy into that holistic vision, and having these groups all sign up for the DevOps vision.

We've had good success in the conversation so far at Unum. I know we've talked to our Chief Technology Officer, and he's very supportive of this. But because we're still on the journey, we want data, metrics, and some evidence to support the philosophy. I think we're making some progress in the political space, but it's still a challenge.

I'm part of the HP BSM CAB (Customer Advisory Board), and in that group is, they talk about these other different small monitoring products trying to chip away at HP's market. The product managers, will ask, "Why is that? And I say that part of the problem is BSM is pitching enterprise monitoring.

The assumption is that a lot of organizations sign on to the enterprise monitoring vision. A lot of them don't, because the infrastructure team cares about the server, the application team cares about the app, and the networking team cares about the network. In a lot of ways, that's the same challenge you have in DevOps.

Requests for visibility

But I hear a lot of requests from the infrastructure and application teams for that visibility into each other's jobs, into their spaces, and that's what DevOps is pitching. DevOps is saying, "We want to give you visibility, engineer, so that you can understand what this application needs, and we want to give you visibility, developer, into what's happening in the server environment so you can partner better there."

There is a good grassroots movement on this in a lot of ways, more than a top-down. If you talk about politics, I think in a lot of cases it has to be this “Occupy IT” movement.

Gardner: What are some of the paybacks that are tangible and identifiable when DevOps is done properly, when that data is shared and there is a common view, and the automation processes gets underway?

Maanonen: What we hear from our customers, and obviously Unum is no exception to that, is that they're able to measure the return on investment (ROI) from the number of downtime hours or increased productivity or revenue, just avoiding the old application hiccups that might have been happening without this collaborative approach.

Also, there's the reduction of the mean time to resolve the issues, which they see in production and, with more supportive data than before, provide the fix through their development and testing cycles. That's happening much faster than in the past.

There is a good grassroots movement on this in a lot of ways, more than a top-down.

Where it might have been taking days or weeks to get some bugs in the application fixed, this might be happening in hours now because of this collaborative process.

Gardner: Does DevOps put you in a better position vis-à-vis what we all seem to see coming down the pike, with the whole mobile-first mentality, and then more cloud options?

Durgan: It is, if you think about movement to the cloud, which Unum is very much looking at now. We're evaluating a cloud-first strategy. My accountability is writing this strategy.

And you start to think about, "I'm going to take this application and run it on a data center I don’t own anymore. So the need for visibility, transparency, and collaboration is even greater."

It’s a philosophy that enables all of the new emerging needs, whether it’s mobile, cloud, APIs, edge of the enterprise, all those types of phenomena. One of the other major things we didn’t touch on it earlier that I would contend is a hurdle for organizations is, if you think about DevOps and that visibility, data is great, but if you don’t have any idea of expectations, it’s just data.

What about service-level management (SLM) and ITIL process, processes that predated ITIL, just this idea of what are the expectations, performance, availability, what have you for any aspect of the IT infrastructure or applications? If you don’t have a mature process there, it’s really hard for you to make any tangible progress in a DevOps space, an ALM space, or any of those things. That’s an organizational obstacle as well.

Make it real

One of the things we're doing at Unum is we're trying to establish SLAs beginning in dev, and that’s where we take fail fast to make it real. When I come to the conference and presented it, I had a lot of people look surprised. So I think it's radical.

If I can’t meet that SLA in dev, there's no way I am going to magically meet it in production without some kind of change. And so that’s a great enhancement. At first people say, that’s an awful lot of burden, but I try to say, "Look, I'm giving you, developer, an opportunity to fail and resolve your problem Monday through Friday, versus it goes to production, you fail, and you're here on the weekends, working around the clock."

That, to me is just one of those very simple things that is at the heart of a DevOps philosophy, a fail fast philosophy, and a big part of that development cycle. A lot of the DevOps tooling space right now is focused on some ALM on the front end, HP Agile Manager, and deployment.

Well, those are great, but as an application architect, I care about design and development. I think HP is well-positioned to do some great things with BSM, which has all that SLA data, and integrate that with things like the Repository, which has great lifecycle management. You start having these enforcement points and you say, "This code isn't moving unless it meets an SLA." That decision is made by the tool, objective criteria, decided by the system. There's no need to have a human involved. It's a great opportunity for HP to really do some cutting-edge and market-leading stuff.

Cloud and mobile are coming into play and are increasing the velocity of the applications and services being provisioned out to the end users.

Maanonen: We see that the cloud and mobile, as you mentioned, Dana, are coming into play and are increasing the velocity of the applications and services being provisioned out to the end users. We see that this bigger and larger focus, looking from the end user perspective of receiving the service, whether it’s a mobile or a cloud service, is something that we've been doing through our technology as a unifying factor.

It's very important when you want to break the silos. If the teams are adopting this end-user perspective, focusing on the end user experience improvement in each step of the development, testing, and monitoring, this is actually giving a common language for the teams and enhancing the chances of improved collaboration in the organization.

Gardner: HP may be unique in that it has a very strong presence in the applications test, dev, deployment, fostering Agile, and fostering DevOps. But only an architect might see that. How essential to the future of HP is it to make architects like Tim happy?

Maanonen: Tim has been pointing out that they're coming from a traditional IT environment and they're moving to the cloud now very fast. So you can see the breadth of the HP portfolio. Whatever technology area you're looking at, we should be pretty well-equipped to support companies and customers like Unum and others in different phases of their journey and the maturity curve when they move into cloud, mobile, and so forth. We're very keen to leverage and share those experiences we have here over the years with different customers.

But the portfolio breadth is one of the strengths for HP, and we're trying to stay competitive in each area. So I am happy that you have been observing that in the conference.

The portfolio breadth is one of the strengths for HP, and we're trying to stay competitive in each area.

Gardner: Tim, what would you like to see differently -- not necessarily just from a product perspective, but in terms of helping you cross the chasm from a siloed development organization and a siloed data center and production organization? What do you need to be able to improve on this DevOps challenge?

Durgan: The biggest thing HP can do for us is to continue to invest in those integrations of that portfolio, because you're right, they absolutely have great breadth of the offerings.

But I think the challenge for HP, with a company the size they are, is that they can have their own silos. You can talk to the Systinet team and talk to the BSM team and say, "Am I talking to the same company still?" So I think making that integration turnkey, like the integrations we're trying to achieve, is using their SOA Repository, their Systinet product as the heart of an SOA governance project.

We're integrating with Quality Center to have defects visible in the repository, so we can make an automated decision that this code moves because it has a reasonable number of defects. Zero is what we'd like to say, but let's be honest here, sometimes you have to let one go, if it’s minor. Very minor for any Unum people reading this.

Then, we are integrating with BSM, because we want that SLA data and that SLM data, and we are integrating with some of their partner products.

There’s great opportunity there. If that integration can be a smoother thing, an easier thing, a turnkey type operation, that makes the portfolio, that breadth something that you can actually use to get significant traction in the DevOps space.