Voices in Cloud – Episode 6: A Conversation with Gordon Davey of Willis Towers Watson

Guest

Gordon has held a broad variety of IT roles, from vendor side, to corporate IT dept, from delivery to sales and strategy. Before joining WTW Gordon was part of the Dell UK Senior Leadership team, operating as the Cloud Strategy Director for the UK business. Now as Head of Cloud Architecture for Willis Towers Watson he is focusing on putting into practise all of the nonsense he used to talk about, and helping the company evolve to become a ‘cloud first’ organisation.

Transcript

Dave Linthicum: Hey guys, welcome to the GigaOm, Voices in the Cloud podcast. This is the one place where you hear from industry thought leaders providing ‘no nonsense’ advice on how to succeed with cloud computing, IoT edge computing and cognitive computing. I'm Dave Linthicum, bestselling author, speaker, executive and B-list geek. And joining me today is our special guest Gordon Davey, and Gordon I'm going to have you introduce yourself because I thought your bio on LinkedIn was very humbling, but it didn't tell me a lot about what you're doing currently.

Gordon Davey: Sure yeah. Happy to, David. Well thanks for having me on, first of all. My name is Gordon Davey, right now I am the Head of Cloud Architecture at a large insurance brokerage and consultancy organization. My 20 year career in IT has spanned a number of different things. I've worked vendor side, service providers probably for most of it. Two years ago I made the switch to the other side of the desk and I jumped into an interesting corporate IT role, and thought I should roll my sleeves up and start actually doing what I had been talking about and telling other people to do it for so many years. So that's really my role: is to evangelize cloud within the corporate space and to help enterprises drive in that direction.

So what have you been working on lately? What are the top three things that you deal with as a cloud architecting organization?

Yeah. So we have a really interesting organization due to its diversity. We were formed from a large merger of two almost equal size organizations and across that, there's 30 or 35 different lines of business. And what makes it really interesting is: a lot of those lines of business came from acquisitions and they're all very different.

So we've got this massive diversity of maturity level, of capability level in some cases, of interest in going to the cloud and willingness to look at new forms of development, approaching devOps as an approach, so lots of diversity. At one end of the spectrum we've got a couple of lines of business who have been using cloud actively for five or six years and have got lots of experience, and have been working ‘hands on’ particularly in Microsoft Azure for a long time.

We've got others at the completely opposite end of the spectrum [that] have been on an on premise data center for years, having relied entirely on a corporate IT department to do everything for them, and are very nervous about cloud, and then everything in between. So we've been balancing that real diversity across the organization, trying to help the organization move to the cloud with all that variety in there and really begin to take more ownership of what we do as they transition and modernize it at the same time.

So we didn't want to just ‘lift and shift’ lots of bad practices or lots of technical debt with us into the cloud. So how can we bring all of those factors together? So that's been a really interesting journey and really wrapping governance around that and making it enterprise ready and enterprise class, has been a really interesting journey over the last couple of years.

So speaking in governance, it's funny I do a lot of LinkedIn videos [for] LinkedIn Learning, which is LinkedIn.com and the video I did on cloud governance is probably hit more than most of them out there. Also a lot of reports that I write on cloud governance are just hit on GigaOm a ton as well as for InfoWorld and things like that. So kind of a poor man's focus group that seems to be an area of focus that I don't think the mainstream tech press has picked up on. And everybody: my clients and my friends and people who are thought leaders in the space seem to be focusing on this as really a core enabler, and I think it's probably one of the most important cloud computing technologies that we have to face going forward.

So give us your experience of cloud governance and tell us what you're working on currently.

Yeah. So as I mentioned just earlier, we are focusing on Microsoft Azure as our primary cloud platform. We have that diversity that I talked about and that diversity not only [with respect to] maturity levels, but some parts of our organization have got compliance requirements that are fairly strict, others don't. So there's a lot of different compliance requirements and the governance needs to play into that.

So what we need is a flexible model that would allow different parts of the organization to ensure that they were adhering to the standards that they needed to be meeting those compliance requirements, and others that just wanted a lot more agility, a lot more flexibility, but at the same time we wanted to have some level of assurance that what they were doing was still secure, still met best practice, still was going to not cause problems, and your worst case scenario cause some kind of data breach, because in a lot of cases, those application teams hadn't been previously responsible for managing their security perimeter or managing any of those base practices around that.

So we've put in place a whole variety of things from best practice guidance, you know, reference architecture is really giving some strong underlying foundations to how teams are going to approach the use of cloud. We put in solid training schedules for different teams to make sure we upskilled them and they knew what they were doing. But probably most importantly, we wanted to have some kind of central visibility and control of what teams were doing out there in the cloud, and to some extent that clashed with the whole DevOps approach, where we were wanting them to take more responsibility and take more ownership of the operations.

But at the same time, to be a good corporate IT department, we felt we couldn't just let them go in and make the mistakes... obviously we had to make sure it was secure. So that was something we really struggled at first then, and had to dig around with a lot of different tools to find a way to do that.

You know there is kind of a conflict between DevOps and the notion of governance. But the thing is, at the end of the day, you know as they're building DevOps organizations and tool chains, things like that, the developers realize the value of putting up guardrails to ensure that they don't do something that's going to put the systems at risk, or take too many CPUs. Cost governance: the ability to kind of put API governance around who can access that and what times of the day and what they can do and how many resources they can do and also the links with governance and security. So it is kind of an initial pushback as you said. That's in my experience.

However I think quickly and as long as there's some good training and people can explain easily, there's a huge synergy and a huge, huge positive impact that governance can have on DevOps. Are you finding that?

Yeah absolutely. I mean the reality is no application team wants to develop an insecure application or one that's a resource hog and costs a lot. They all have that end goal in mind that they want to be good corporate citizens. They want to build the best application they can and do that as quickly as possible and respond to the market. But they want it to be secure of course. Nobody wants to be seen letting the team down in that regard. So there is that balance to be had, and I think we've very much found that the way we had to approach that, had to take that into account.

So at the same time, while they want to achieve that security and good best practice, no application team wants someone coming in and telling them what they're doing is wrong or coming in as the overlord that thinks they know best. So we actually deliberately made a decision early on.

A very simple thing, names can make the biggest difference. But rather than calling our centralized cloud team the cloud ‘Center of Excellence’ which seems to be the industry standard, we felt that that seemed very ‘ivory tower’ ‘we know what we're doing, we're coming in and we are just telling everybody else what to do.’ We decided not to go that route, and instead we called our centralized team the ‘Cloud Enablement Team,’ a subtle difference but it was all about enabling those lines of business to make the best decisions to have the right architectures in place, to have the right approach to security and architecture. And that was so much better received across the organization.

Teams were willing to let us... there wasn't this perception that we were a gate in the process or we were telling them what they were doing was wrong. But instead, we're standing there beside them, helping them upscale and really helping them along that process. So that's definitely helped.

Yeah, a collaboration approach needs to occur between the cloud team and the development team and the ops team and the security teams and things like that. And it is a bit of a struggle because in essence we're reinventing the enterprise as well as reinventing the organization, as well as kind of leveraging new technology, and in technology we need to bind on and that technology, new database approaches, governance, security things like that.

So what advice would you give an enterprise like yourself that's on the journey in the cloud and is really realizing there needs to be some retraining, some re- culturing, which is a huge issue, and some... resetting of expectations on how people can drive cloud into the future and do so productively?

Yeah. So I think the first thing that has to happen and we have to do is set a good understanding of what the underlying principles were for using a cloud platform. That sounds very basic and very simple, but just to have that ‘level set’ across the organization because we had that diversity in the organization as well. We had some teams at different maturity levels who felt that they were completely upskilled, were ready to just go out and start using the cloud, full time for all of their their infrastructure and you wouldn't need any assistance. We had other teams that were very nervous and were still wanting some kind of central support and to do some of those tasks that had always been done for them.

So we knew we were going to have this blended operating model, at least initially until we got all the teams up to speed. So to achieve that we had to have a base level set of what the principles were going to be for using cloud. And we took that down to a very simple level, initially created a list of policy documents that were just simply a single A4 page that defined what we meant by a certain task. So something as simple as patching: they're looking at moving IaaS to virtual machines, virtual machines into the cloud running in an IaaS mode, and how is that patching going to be done, and what is the patching level that needs to be maintained, how do you do backup in cloud? How do you do monitoring? All those simple tasks that historically have often been done for teams in the data center by corporate IT. They had to pick up that baton and start doing it.

Or maybe there was going to be that central team that would help them initially on that journey; before we could start any of that, we had to level set as to what it all meant. So those principles were really important and then let us build a variable operating model on top of that. So it meant that when we went to a team and we said “Are you going to be patching all of your virtual machines in cloud?” Then they know what we were talking about. We're all on the same level. There wasn't any confusion, and we almost put in place contracts if you want, service level agreements between the line of business and corporate IT, not as strict as that, but effectively that, which meant that we could have that governance and assurance that everybody was on the same page.

And when one team said they were going to be being responsible for patching or backup, we knew what they meant by that. So that was a huge help, and then getting the right tool in place that helped the visibility of that and make sure that teams were actually doing what they said they were going to do.

There's a lot of third party tools in the market. We looked at a number of them and we've actually settled in the meantime on using the native tool within Azure, so we're using Azure policy and putting in place a really good governance, technical governance model that gives us visibility into making sure teams are adhering to those policies. That can be everything from a security aspect when making sure there's no virtual machines out there that have a public IP address and exposed directly on the Internet, right through to cost management, making sure that certain very expensive virtual machine types are not just being spun up left, right and center and the cost going out of control.

So going forward we have this challenge ultimately that we have to, in essence grow innovation, grow agility, compress time in the market, do all these really core benefits the cloud really has. I think what you're getting at is it's kind of a tradeoff in terms of our ability to do that, which I think we can do if we have a good governance layer in place. It's automated, abstracted, easier use but that's the challenge, right?

So we're growing into more complex environments, complex architectures, complex data models, federated databases that exist in the cloud or on premise. We have to bind them together using an abstraction layer. We have to deal with security that's holistic to the majority the systems out there, like identity access management, things like that.

So the only way you're not going to end up in an insane asylum ultimately is to think in terms of how we're going to automate these things. So what are some of the best practices that are emerging in terms of governance automation, security automation, ops monitoring, automation things like that?

So yeah there's a number of things we're seeing, as you say automating, is going to be very important. So for those teams that are lifting and shifting a lot of what they're doing today into cloud that despite our best efforts of trying to modernize, there are still some teams that are doing that because they need to. Then that becomes much harder, but for the teams that genuinely are modernizing their applications, then really driving a lot of that earlier in their whole lifecycle, earlier in their devChain and making an automated part of their build process has been hugely important, so automating security early in the process and not leaving that to the last minute.

I know there's a lot of buzz words out there around that, around DevOps and those kind of things, but actually making that happen has been fundamental to us, bringing that agility into the conversation, but if you're building your application in an agile way to some extent but not checking the security until you're ready to go live, [that] becomes a huge gate and is going to slow down everything. So it's that old adage of looking for the pinch point there, and making sure that you're looking at the full end-to-end process. so: automating that, bringing it in earlier into the whole build process, so every time that application is sent a new build, it goes through automated checks, scans for security vulnerabilities, they're doing that code check, static code analysis etc, is a huge benefit in actually bringing in more agility.

At the other end of the process, there are absolutely some good automated solutions around monitoring, [that] are bringing more intelligence into what's being done. So the real benefit we see on that side is again those teams that are starting from a lower skill base on the operational side, who had just been developers and relied on corporate IT to do everything for them. As we see all of those monitoring tools beginning to bring things like AI and intelligence into that, and they're actually correlating a lot of the information across the environment, and popping up alerts that those teams would never have noticed before or not been able to interpret properly, they understand what those alerts mean a bit more in normal everyday language that they're seeing, rather than having to dig in the logs they could respond to that much quicker. It just makes it a much simpler process for them.

So last question, it's kind of more selfish in nature as well. If you're going to write a report on governance in the cloud, what are some of the top three topics you would cover? What would you want to learn that's not out there already?

So if I was writing from what I'd already experienced, I think a number of things from what we've already covered: setting those underlying principles upfront would be right up there, making sure you've got a toolset in place that can then validate that those principles are being met, has been hugely important. Then actually agreeing that operating model, would maybe be number three and working out how you're going to go about that with a business, because teams that haven’t been used to operating in that kind of DevOps model, it is a real jump for them. Making sure they understand what that transition is going to be has been hugely important for us.

So that's the three areas I would focus on, and my historical experience as to where we are today. Going forward, I think that there still is a gap from the security side, particularly when it comes to adopting more PaaS and serverless solutions going forward in particular, so how we could properly get a good visibility of that, and particularly that's deployed, a lot of security tools are still very focussed on traditional infrastructures, which translates reasonably to a IaaS type deployment, where teams are just lifting and shifting.

But when teams begin to truly modernize an application, whether it's even containerization to some extent, but definitely down the serverless route, how do you put governance around that in a proper way? What are the right tools that are out there to do that? For me there still seems to be a bit of... either a gap in the market, or maybe just a gap in my knowledge (that's highly plausible as well), that's really where we are now beginning to look and beginning to work.

Yeah I find people that are cloud architects, CTOs, Chief Cloud officers, things like that, all these new titles out there are going to live in fear of the serverless container world, because we can build things so quickly. So in other words, we have shadow IT that can not only go out and get a Salesforce.com account or other SaaS provider account, which is a bit more innocuous than someone who's actually building things and moved data and is dealing with things at the raw level, which has potential for causing disaster.

I think that is very difficult to get a rope around those people and ultimately in the corralled effect that they need to in essence, operate in the centralized infrastructure, centralized security, centralized governance, things like that. So final guidance, what would you tell the enterprises to go off and do in a couple of sentences as far as dealing with governance?

Make sure you have a plan. Don't just let teams go off and do their own thing. You want to drive agility absolutely, but there still does need to be some oversight at the center. Make that as slim as possible, make it as automated as possible and so that those teams can get that agility they're wanting, but at the same time, don't just assume that the people that have never had operational responsibility before will simply know what to do. They do need to be trained, up-skilled in that area, so they're going to be successful.

Well I couldn't say it better myself. We'll end it there and that's a great note. So anyway please pick up a copy of my book Cloud Convenience, Silo Convergence available on Amazon and other places books are sold. Also make sure to follow me on Twitter @DavidLinthicum, as well as LinkedIn where I have SOA cloud computing courses on LinkedIn Learning. So Gordon, what would you like to share with the audience as far as getting a hold of you?

Yeah I'm more than happy to have conversations with people. I am active on Twitter @GordonCloud, and on LinkedIn as well, so people are more than welcome to reach out to me there. I'd love to have conversations with folks.

Yeah reach out to Gordon, he's actually doing... everybody else is talking about it, but Gordon is actually a practitioner trying to make it happen, so he's a warrior in the cloud computing world. So if you enjoyed this episode of Voices in the Cloud, please check out the other ones, also removing hybrid cloud and multi cloud complexity is a focus of a report that I wrote for GigaOm Research. If you’re interested in finding out more about taking IT to the next level, download the single report and subscribe to GigaOm research for future forward advice on data driven technologies operations and business strategies.

So until next time, best of luck in building your cloud computing solutions. We'll talk to you next week guys. Bye bye.