DevOps, cloud, and that pesky IT/business gap

Profile picture for user jreed By Jon Reed July 24, 2013
Summary:
Chris Kernaghan has a passion (some would say an obsession) for re-inventing IT and closing that persistent IT-business gap. Check out his strongly-worded views on DevOps, cloud, and turning IT from cost center/sinkhole to indispensable.

Chris Kernaghan has a passion (some would say an obsession) for re-inventing IT and closing that persistent IT-business gap. A fellow SAP Mentor and Capgemini Lead Technical Architect for their UK practice, Chris is also a DevOps afficianado - a term I challenged Chris to define and justify.

This Q/A boils down a 35 minute video interview embedded at the end of this post, where I tried to scare Chris about the future of the system admin skill set in the cloud era. I wasn't successful - Chris has turned embracing change into a mantra and is doing his darndest to foster that culture around him.

Jon: What are the predicaments and opportunities for today's system administrator?

Chris: Time is a ridiculously precious commodity. We're coming out of the back of a recession. People are being asked to do more with less, and technology has moved on. We all talk about consumerization of IT - the time to value of tools and apps as you get closer to the consumer needs to be shorter.

Jon: Are you and your system admin brothers and sisters deeply threatened by the cloud - or is cloud an opportunity to reinvent and do your job better?

Chris: I think cloud is a way to actually reinvent and do your job better. There are obviously going to be people in the on‑premise world who are saying, ‘Oh my god. They're going to take the CRM system off me and stick it up in Salesforce.’ But then you realize it still needs an integration platform; we still need to report off of it. Cloud just becomes a different way of provisioning and getting things done.

Jon:  When the HANA Enterprise Cloud was announced, I heard some system admins say, ‘This is going to take my job away.’ I thought Ethan Jewett made a really important point:  you should welcome a challenge to these commodity skills because it's a chance to redefine in a way that's more business relevant.

Chris: In the DevOps world, we have this concept: ‘There is a gap between the application and the infrastructure and the person who succeeds the best is the one that actually bridges all of those gaps.’ You can talk code to a developer or actually do the initial debugging on an application. You can speak to a network person or the SAN infrastructure person. Having this broad range of skills as a facilitator makes your life more interesting, because literally it can now be something different every day.

Within the cloud world, that doesn't actually change. If you stick your applications into the HANA Enterprise Cloud, your administrators and your developers are going to have to become a lot closer together and speak the same language.

Jon: Define DevOps in a way that someone like me can understand it, and then tell me why it's important.

Chris: DevOps is a portmanteau of ‘developer’ and ‘operations’. It is a philosophy that is built on the agile principles. Agile was traditionally was about project management. We want to apply it to operations, so that the business can derive the benefits of not only faster projects, but cleaner and better administration. It's about breaking down the silos that exist within IT.

Take testing and change management tools. By having administrators, developers, and business users all using the same tools, it means we create a common language. And by creating a common language, it means we can work more effectively together.

Jon: Have you seen customers adopt this successfully?

Chris: It's a difficult one. DevOps is a journey, not a destination. It's not an org. It's not a deliverable. In the wider world, there are lots of companies doing this. Amazon, Facebook, Google - they all do DevOps. I've had two major oil companies come to me and say, ‘We'd really like to have DevOps processes, when you come and show us how to do it.? People are definitely waking up to it within the enterprise market.

Jon: When I hear you talk about DevOps, I envision a dialogue between admins and developers, a healthy blurring of the lines where developers aren't going away for six months and coming back with something that may not be relevant. But I didn't hear much talk about the business. Does the business fit into DevOps?

Chris: It comes down to your common language. Yes, a lot of that language will be within IT, but ultimately we are servicing users and user requests. The interaction with the business is absolutely critical. Because DevOps is built on the foundations of agile, the concept of strong feedback loops, of critique by the business of every option, is central to what DevOps actually is.

What you do is you organize your work into sprints on the basis of strategy or tactical need, and you always have a customer for the output of those tasks. You have to engage with that customer on what a definition of ‘done’ is. You have to engage on what the progress of that is, and then you have to stand up and present it to your customer at the end of it.

That feedback loop into business is absolutely critical. If you've got a continuous delivery pipeline into production, you could deviate very quickly from what the strategic aims of the business are unless you speak to them on a regular basis. How you keep the alignment is constant communication.

Jon:  That also implies new approaches to testing. Instead of having large testing cycles controlled by IT, you may need to pull business in for quick bursts of testing when new bits of functionality go live, right?

Chris: I would even challenge the statement of ‘bringing business in for quick rounds of testing.’ Ideally, what you should have is an automated test path that would follow something like the 80/20 rule. You can actually do releases more frequently because you've automated it. Then you bring the business in for the 20 percent, or for as little as the 2 percent that you're actually going to change, where you have a business change or process change or workflow path. You’re saving an awful lot of testing cycles that way.

Jon:  We're seeing the impact of cloud software in the large enterprise, especially in areas like HCM or CRM or supplier management. Are you seeing that with your customers, and does that throw down a serious challenge from a sys admin perspective?

chriskaphoto1
Chris: Take the example of an Ariba customer that wants to put in SuccessFactors for their HCM. I know how to integrate these environments with SAP PI (Process Integration) at a theoretical level. But how do you monitor the performance? That’s something I will be researching.

Of course, there are days when you wake up and you go, ‘Yeah, everything's going to change,’ but I'm kind of used to it by now. There are people who have some really difficult choices to make. Whether they decide to move higher into the application, or whether they decide to go niche and build a boutique consultancy.

There are hard choices, but the bottom line is we live in technology. We work in technology. The concept that life is going to remain static is wrong, and will never bring peace. If you don't adapt, you die. That's the bottom line.

Jon: I'm hearing about cool stuff in the DevOps area that can be done with open source tools and lightweight testing solutions. Are you a part of that change, or are you resisting that change?

Chris: Am I seeing a lot more open source tools entering the enterprise market? I am. I'll give you an example. There's a product called logstash, which is written by Jordan Sissel. It takes about 300 different feeds of information in various formats, and puts it all in a coherent log.

Let’s say I suffered a network failure at 9:05 on a Monday morning. I could go to logstash and basically say, ‘Show me all the logs from 9:00 to 9:10,' and I would be able to see the cascade of failure throughout my entire infrastructure, and what the consequences of that are, as each of the log files come in and register that something's happening on the network.

It will enable me to then track back and see what the source of that failure actually. That's massively powerful because it means that I'm not sitting around. Meanwhile, the general IT guy can only say, ‘Well, SAP is down.’

I am involved with a group of people on the SAP admin and DevOps front, to educate and bring these tools to the fore. Sometimes it's literally as easy as a tweet to say, ‘Looking at logstash,’ Then all of a sudden you get about 10 people coming back saying, ‘That was a really cool tool. I'm really quite interested by that.' It's all done by word of mouth at the moment.

Jon: I talk to an lot of ERP customers that say, 'Oh, I'm using...' and they'll rattle off some pretty standard names of old‑school testing environments. They don't seem particularly thrilled with some of these tools and environments, but they're kind of locked in to doing it a certain way. Do you think there's a lack of awareness?

Chris: It comes back to the very first question you asked me - what are the challenges? Time is one of them. If people aren't necessarily aware of tools then yes, that's a challenge for the company that makes the tool to spread awareness, but it can come down to the fact there just isn't time for people to sit and play with stuff.

Having said that, with virtualization and cloud and Infrastructure-as-a-Service and Platform-as-a-Service, I don't think we've ever been as technologically rich. We’re also community and documentation rich - we just are time poor.

Jon: I've talked with a lot of SAP and Oracle customers about upgrades. Unfortunately, upgrades are a fact of life in on‑premise environments. What really concerns me is the amount of effort that goes into these patches and upgrades, versus the amount of time IT folks have for mission‑critical business projects. It strikes me that they should be worried about that right now.

Chris: Absolutely. This is one of the reasons why we love DevOps. The purpose of DevOps is to automate the hell out of as much as possible, which then frees us up to do the interesting things. Don't have people do daily checks on systems. Have exception‑based reporting, which then means the person who used to do the checks can now be freed up to do a business project that is going to be a lot more interesting than his or her system checks.

Let's face it, the business want to do interesting stuff and move themselves forward. What they don't want to hear from IT is, ‘Actually we have to do an upgrade to the SAP or Oracle system first, because only the latest release supports that functionality'.

Jon: I don't think any IT person relishes being in that position right now. Unfortunately, keeping things safe and secure and the engine running is somewhat of a thankless aspect, right? That's just the bottom line. That's expected. Now it's about, ‘How are we using IT to compete? Because otherwise, why do we have an IT department at all?’ That's the question that's coming.

Chris: It's an interesting one. Is IT a cost center or is it a profit center? I actually think it's neither. It probably should be seen as a value center. How does an IT drive business value? Because at the end of the day if it's a cost center, then it just sucks money from people. If it's a profit center, then it's selling itself to the business and probably just about doing what the business wants and no more.

If it's a value center, then it actually has to strategically align with the business and do the stuff in parallel with the business. I think that may be a better way of looking at it.

View the full 35 minute video conversation:

Image credit: Overcome the problems © alphaspirit - Fotolia.com

Disclosure: SAP is a diginomica premier partner as of this writing. Jon and Chris both serve as SAP Mentors on a volunteer basis.