Martin Croker

My name's Martin Croker. I'm responsible for the DevOps practice at Accenture.

But instead of talking about one of our clients' transformations, I'm going to talk about ours.

Please bear with me, this is new material. I've recently updated my slides. If it looks like I don't know what slide's coming next, or I'm a bit confused, there is a possibility I don't know what slide's coming next, and I'm a bit confused. I'm also quite pleased that somebody advised me to take some of the words out of the deck earlier today, because those of you at the back would've needed a microscope or a telescope.

So, when we talk about Accenture, and I'm going to do my best not to spend a huge amount of time talking about Accenture, but I want to set some context. We're looking at over 100,000 technologists. We operate in pretty much every country globally, with most of the FTSE 100 in some way, shape, or form. Not all IT, not all DevOps, but we have a presence. We are partnered with most major technologies you'd have heard of. And therefore, when I start talking about scale of DevOps, I have scale in terms of industry, country, culture, technology. You name it, that's part of the makeup of the challenges we're dealing with at Accenture.

My role is twofold. My role is both to develop a consulting practice, and have the people and the skills necessary to support our clients. And I also play a part in our journey to make sure that we're bringing the best of the technology we can to our application services engagements. And we do a huge amount of work doing software delivery, software implementation, systems integration with our clients.

So, with that context, we've heard an awful lot today about the things that are disrupting our industry. Be that business change in terms of the need for business agility. Those of you who are operating in pretty much any industry are going to be receiving a rate and a volume of change, be that taxi firms with Uber coming in, financial services with fintechs coming in. Huge rates of change in terms of business disruption.

And that's being driven by a huge rate of technology disruption. Be that digital, be that cloud, be that API-driven. There's a lot, and lots changing. We've heard about lots of it today, so I'm not going to dwell on the point. The point I wanted to land, though, was that every industry, every technology is changing. And for the avoidance of doubt, that includes mine.

The contracting, the buying patterns that start happening as Agile comes to the fore, as Lean comes to the fore, as we start looking at different technologies, obviously have a huge bearing on the way in which we deliver software, too. And that's pegged both in terms of the delivery approaches we can use.

So we've heard about Lean, we've heard about Agile over the course of today. Those delivery approaches result in slightly different contracting approaches. They result in different skill sets, changes to our methodologies. So a huge change to the way in which we deliver, and also a change to the technologies and the architectures we need.

We start looking at having to make sure that people have the right skill...

That's so distracting.

And by the way, this is my best side. Actually, this is my best side.

So, making sure we've got the right technology skills in terms of cloud architectures, Docker. New technologies emerge so quickly. And if we take Docker as an example, I think we seriously started playing with it two years ago, maybe. And now it's ubiquitous. Most presentations at this conference will have mentioned it. I was at DockerCon last week. They're a company of 250 people, and can attract an audience of 4,000 just to their conference. And that's just a review of the rate of change, and the rate at which new technologies spring up.

The idea of open source suddenly creates this huge dispersal of technologies. No longer are you choosing between IBM, Oracle, et cetera. You're trying to keep track of tools with stupid names like Chef, Puppet, and a huge growth in names, many of which have been created by somebody in a garage, growing in popularity, and creates a real journey just keeping up with the terminology.

And then the extensibility and the platform architecture, the idea that you're building on top of SaaS products, you're building on top of platforms. You're creating microservices and building services up. Again, change the way in which our technical architects need to understand and build solutions. Not just in terms of consuming that technology, but making sure that when we leave products behind or services behind, we're leaving services behind that have that extensibility within them as well.

No one's defined DevOps today, or no one's given my definition of DevOps today, and I have the advantage that I'm stood up here with a microphone. So, I thought I'd give mine.

So, my perspective is our primary purpose when we start talking about DevOps is actually around the business agility. It's that idea of being able to go from somebody having an idea, to the business achieving value from that idea and sustainably operating it.

And that involves a huge collection of disciplines, from config management, to pipeline design, to test automation. But ultimately, the goal is idea to value quicker, more rapid feedback, more experimentation.

The second component of my definition is DevOps-centric architecture. So, when, as technical architects, we start looking at building a system, it's no longer just about the functionality. It's about two other concepts.

Design to operate. Are we creating a system that can be operated effectively, cheaply, sustained, and in a robust way?

And secondly, design to deliver. Are we creating a system that has the right attributes amongst it in order to be delivered in an effective and a cost-effective way?

So if I was to take a design to operate example, I'll use anti-fragility, immutable servers. What happens if a server fails in life? Does my application survive it, or do I need to take action?

And the same thing when we start talking about design to deliver. The idea of getting to smaller, more granular microservices, the boundaries between them, removing the systems reaching into each other's database, and isolation makes a huge difference to our ability to effectively design systems. Sorry, effectively deliver systems.

And finally, software-defined platform, infrastructure as code, cloud, call it what you will. Even with content management systems have given us the ability to rapidly change images or rapidly change content in a system without resorting to IT or without resorting to a huge waterfall change.

When we start looking at continuous delivery, that brings that concept of flow down to the application. And we've heard some of the presentations today that have taken it all the way down to the data center, and the ability to define as code and treat through a life cycle the infrastructure, the firewall rules.

I'm from the development side of the house, so the frustration I've had time and time again as the operator got the firewall rules wrong, sat there overnight waiting for it to be fixed. All of that goes away by virtue of being able to test that through the life cycle.

So the software-defined platform, final and third leg of my definition, all of which I would then wrap with Lean IT, culture, cloud, et cetera. So those are the things that we're trying to achieve as we start working towards DevOps within the practice.

And there are a number of levers that we need to hit for each engagement in order to do that. So as we start talking about project and/or a service, or depending on what governance construct you use, we need to be working with the stakeholders. Here, as a service provider, we have additional challenges because not all of the stakeholders work for us. And to Philippe's point earlier, many of them are expecting us to be the expert, are paying the bills, have a very strong view. And ultimately, their views get embedded in a contract. So for us, when we start talking about changing the way we deliver, we have an additional step of making sure that we're commercially enabled to do it.

And then we've touched on some of the others. Delivery approach embedded in methodology, the architecture we're using. There are a variety of things to do.

We've got about 2,000 engagements at any one point in time, at least. So the scale that we're then, or I'm then trying to drive those levers on is at a really large degree.

So I've stolen this pyramid, which is a metrics model that came out of our first global improvement initiative in about 2004. And the construct when we looked at us as a service provider is there are a set of areas and set of domains that we need to operate in, ranging from our capability platform, what skills and people we had, through to the tools and the methods we were giving them in a delivery platform. Within that construct, running series projects or engagements, and ultimately governance over the top.

So taking this construct, I just wanted to walk through it and talk about some of the things we were doing in each of the levers and try and draw the lessons.

Mark Rendall, one of my team, as we're going through this, wanted me to really highlight some of the lessons learned and the challenges we've had over the way. And I think one of the first ones was actually realizing that it wasn't a single-dimensional problem.

And the other big step for me actually was realizing that it wasn't one I could solve on my own. Now, that may be self-evident, but I'm quite controlling. In fact, I am probably a quintessential control freak. I think that might be why I come from a DevOps background, which seems counter-cultural now.

Everything I do within the firm inherently overlaps with at least one other group, maybe multiple other groups, and that's true of pretty much everything I do. I say only half in jest, if the DevOps team at Accenture were the only people doing DevOps, that would almost be the definition of failure. So creating that construct where we're able to collaborate and work with others to do that has been one of the real keys to the success of what we've been doing, creating those tools and the ecosystems that let us have that collaboration.

So we do a lot of consuming our own platform. We've built a platform we use for our delivery. We make sure we're the first and primary user of it, and only when it's working for us do we roll it out. And given it's a collaboration platform with shared version control, with tools like HipChat and Jira, et cetera, we then make that available for the collaboration on the tools we're working to.

So working through this, starting with people. And the first and most obvious thing with people is training. With 100,000 technology practitioners, that's a lot of training to do.

What we found as we look around is that we could find the courses we wanted for industry technologies. We could work with our partners like Chef and Docker and Oracle and Microsoft to find the technology courses. What we found a lot harder was to find a course that gave people a feel for what good looked like, an opportunity to experience continuous delivery.

So we created our own. We created a two-day training course. By the end of this year, we'll put over 3,500 people through that. That course's primary purpose is to give people just a sense of what they might be aiming for. Now, we don't expect people to walk away from that, having done the delivery, being a full-on practitioner. What we expect is people to have a guiding star, something to aim for, have experienced continuous delivery within our environment.

We also do a lot of training of our technologists. We recently revamped all of our core training for new joiners, not just to add DevOps as a module, but to rip it out and put DevOps right at the heart of the way in which we deliver. So really focusing on embedding that. Not, here's how you write Java and here's an afterthought of DevOps. Here's how you do software engineering in a modern construct. It's one thing, not taught as two.

And the final area where we do, or I do a lot of training is of our leadership. Making sure that our solution architects know how to design and shape a deal construct right, to include early delivery of value, and that our delivery leads have the tools necessary for support of delivery of Agile.

Recruitment's, I guess, a no-brainer. Like everyone else, we're competing for talent. It's hard. And for a service provider, a lot of that comes down to ethos and reputation.

And then finally, finding ways of measuring those people's skills. My background is technical. In fact, my background, if I go back far enough, is a sysadmin. I really believe in measurement metrics. I think the uncertainty principle of if you measure it, you affect it, is a great effect and can be used to power things.

I have more dashboards and metrics on the skills we have within the firm, where they are, which industry group is doing well, using that to set up competition between North America and Europe, and who's building the best skills at the biggest rate. Huge focus for me on measurement and metrics and skills, both through certification and training attendance.

And when we start talking about knowledge and awareness of the wider practice, it's a real journey of continuous experimentation for us. The DevOps Academy, recently tuned. We just ran a specialist conduct for our leadership in Netherlands last week, and as a result of that, we'll be cycling it back in, we'll be revamping the course, we'll be going again. We'll be continuous. All of the principles around DevOps, we applied to our journey to achieving it.

I don't have the power to mandate across the board to all of our engagements, you must use this tool set. I'd quite like the power. But sadly, both our own architects, for very valid reasons, have opinions. And occasionally those opinions are wrong, or as I like to better phrase it, disagree with mine. And our clients have opinions. Our clients have enterprise architectures, enterprise directions. So I'm not in a world where I can mandate.

But what I can do is create a happy path for making sure that there is at least good practice or ideal practice by default in the way in which we deliver. And that's been the focus of our DevOps platform, which is a very, very grandiose term for a glued-together set of open source tools, pre-configured to be usable in very short time. And I make no apologies for having chosen open source tools. I think the community's done some brilliant things and, in fairness to us, we've contributed this back as well, so you'll find it on GitHub.

This is the problem I have to solve. 2,000 engagements. Five or six industry verticals. Huge number of platforms and capability assets, all of which we need to get to the right point and the right engagement in order to be useful, and do it in a way that can support on-premise infrastructure or cloud infrastructure.

And again, I'd like to say on cloud by default, I don't have that luxury. We have clients who, for regulatory, security, government regulations, are unable to do so. So the DevOps platform we've created, we've used a quite simple base construct of using Docker or Docker Compose to get us the cloud portability, and then I run two versions of it. I run a dedicated instance that we can just fire up as we need anywhere. It'll run on client's infrastructure, it'll run on my laptop. And then we run a managed service that lets us provide that in a multi-tenancy way across services and get economies of scale.

This is where I learn about DevOps. It's really hard for me to remain credible and relevant. I guess I'll get feedback later on how I've done. All of the principles around continuous delivery, service management, immutable servers, ChatOps, this is my ability to use it in a construct of a service I'm responsible for. And I run a shared service team of about 300 people supporting a variety of clients. So it's at a reasonable level of operation that we can make sure that the practices we're applying are reasonable, and I'm not advising people to do things I look at and go, "I'm not really doing that myself."

And then the construct we've built on top of this is a concept of a cartridge. So as we start talking across the variety of technologies we support, I need to find ways to mobilize an SAP project effectively. I need to find a way to mobilize a Hybris project effectively. I need to mobilize Java. If there's a technology out there, there will be a project in Accenture doing it somewhere.

And therefore, the mechanism we've used to create this happy path is to take the concept of a cartridge which pre-configures a reference architecture or a sample for delivery of a particular technology set. And we have an emerging set of cartridges in varying states of maturity that are being developed.

The other thing that this gives me is the ability to really focus on the InnerSource construct. I'm not in a place to tell the SAP group what the right static code analysis for SAP is. By creating this open source construct, they can own it, and that both increases the leverage of it, but it also increases the ownership of it.

So I guess the point I'd be dwelling on here is that one of shared ownership and creating a happy path and making it easy as possible to do the thing that you want people to do, because sadly, I lack the ability to mandate down to the technology.

I spoke about how this is built. Actually, I've used CloudFormation as an example. We've also created Azure Resource Group templates for it. The ability to spin up very quickly from Docker Swarm lets us throw all of those tools down.

If anyone was at Jenkins User Conference last year, I did a demo of this live on stage where I went from nothing to a fleet of servers, deployed a change through a continuous delivery pipeline, destroyed the servers, and left the stage, and that took about 10 minutes, to give you an idea of the art of what's actually possible.

And the history of this is actually is the labs environment from the training course, and then we pivoted, realizing it'd be useful client demos. And what I find is you talk to people about DevOps, and you talk on stage and you get your PowerPoint out, and by about quarter of an hour in, they've glazed over. Maybe that's just when I'm talking.

And then you go, "Let's make it real." And you show the CloudFormation script, you show the Docker Compose file, you fire it up, you create a change, and suddenly people walk away really impacted by understanding what the art of the possible is.

And they know there are constraints. They know it's hard as you move out of Node.js or out of Java, but the same principles apply of continuous delivery to Siebel. I've supported an environment team. We're supporting 70 Siebel environments, and overnight we deployed to 40 of them. We've done build deploy automation for a full Oracle RAC stack. These are not easy things. They require more investment, but the same principles apply if the return on investment is there.

Oh, and then lastly, CloudRush on top.

So continuing my journey up the stack. The other features, obviously methodology, I'm not going to talk about it, but is impacted as we start making this change, and obviously making sure we've got the right partners to do it.

And when we start talking about core delivery, and again, I intend to skim this, because I think it's material that would be non-unique to me. But as you start talking about how you measure and manage a delivery project, as you start making that transition from Agile to Waterfall... Sorry, Waterfall to Agile.

Back in the room. I knew I was doing something wrong.

As you start making that transition, the metrics that you might use for managing the enterprise and the portfolio change, and one of the challenges we're grappling with at the moment is what are the metrics that are best for managing that portfolio of projects as you start looking to make that transition or start advancing down that journey.

The triangle I've taken comes out of program, as I said, high-performance delivery from the early 2000s. And we operate our core delivery center on an incredibly small number of metrics. There are metrics elsewhere, but it's about 12 that are mandatory on every engagement. But those come from a slightly older era. As we start looking towards that journey and the change for how we manage those metrics in the new world, we're busy working out how we evolve them both to understand the maturity of projects on a DevOps journey, but also, does cycle time become the key metric? Does time to value become the key metric? And making sure we focus on the things that really make the difference and let us know how we're doing in this transformation.

MyWizard, I don't intend to talk about a huge amount either, but it's beyond... It's not my favorite name. I hope I'm not being recorded. Please tell me I'm not being recorded.

I love the name MyWizard.

But actually, the construct behind it is really powerful, which is if we have all of these management tools and all of these metrics coming in, the idea of being able to pull those into a data lake and start running analytics over those and start understanding both where success and failure lies, and also start optimizing performance by doing it, is something that we think is going to become a real differentiator. So it's something that's really exciting and happening now for us.

And dwelling on my theme of the DevOps principles are relevant to the structure of the journey that I'm helping with, I see that we have a pipeline. Now, what I want to do is affect delivery here. I want us to be delivering engagements in a particular way to optimize the speed and time to value. That's what I want, and the efficiency.

To do that, actually, as a minimum, I need to be affecting here. We're pretty good at adhering to delivering what we sold. So if I want to change what we delivered, I need to change what we're selling. If I want to change what we're selling, I actually need to be influencing the offerings we're changing.

Now, that might be very specific to a service provider industry, but I think the base principle of understanding that pipeline of cause of effect and working out where you need to start and influence in the pipeline has relevance.

And as we talk about affecting that journey of transformation into an enterprise, starting with a vision, I guess is self-evident. Any enterprise is going to have a set of blockers and enablers to doing DevOps, and I've been describing some of those in the form of our DevOps platform, the training we're doing, having common tooling, having the right partners, having the policies that make it easy. For example, we recently changed a number of policies like our open source policy to make it easier.

And then the enterprise is going to have a set of blockers, be that a CAB process or firewalls between production and development that are totally air-gapped. Whatever they may be. So I think at an enterprise level, all I can do is try and add those enablers and target the blockers.

But then there's ultimately, for each engagement or each program, you've got the hard work to do of then going through it and helping and educating the team and helping to make the transformation.

I guess greenfield, it's easy. Modern architecture, jump straight to the concepts I was describing in DevOps, designed to operate, designed to deliver. Where I think it gets harder is where you've got existing. And the way I think about it is the Boston square between the value of doing it, or for any given application or, in my case, engagement, and the ease at which it can be done.

So that might be, when we talk about value, the volume of change, the agility requirement, how much does it actually drive your business? ERP systems might not need to change very much, but your website certainly will, and that's an easy and a trite example to give. But it's not the only example when you start looking at your agility requirement for an application.

And then the ease, and that's going to be a factor of a whole variety of things, including the technology you're working with. Are you using a platform that generally makes infrastructure and automation hard? Infrastructure automation in mainframe is absolutely possible, but it's not as mainstream as Java. In the same way infrastructure and AIX is absolutely possible, but it's not as ubiquitous as Linux.

It's how easy are the tools there for you? How mature are the team? Are they going to understand the concept? Are they really chomping at the bit to do it? Do you have the right champions in it? And the interdependency between things.

So if your applications are all monoliths reaching into each other's database, that might not be an easy place to start, and actually your start point might be to change that. But having got those priorities, to me, we're on a journey of continuous improvement. It is not a, we're going to bring you DevOps. What we're going to help you do is establish that continuous improvement process to be able to then start applying it across your portfolio.

And that ties to all of the techniques and technical practices that we've been talking about. Using automation, using APIs to create those boundaries, creating that isolation that starts improving your ability to effectively deliver because you've improved the design to deliver concept by creating that isolation boundary between.

And lastly, the ability to measure a portfolio. And I've touched on it a bit through MyWizard concept of a maturity model. I think there are plenty of them out there. This was ours, targeted at understanding exactly where we are on any engagement from the worst we could think of to the best we could think of, with a clear view of what the minimum acceptable was.

I was asked to finish with a slide. I slightly misunderstood in terms of what I wanted, but what I really want for me personally, for us, is to be a participant and a member in the exothermic... Actually, that's not true. What I really wanted to do was use the word exothermic on a slide. That's what I really wanted to do. And I quite like getting the phrase catalyst in as well.

People say you can't buy DevOps. You can buy a catalyst to help you achieve it. You can buy a change agent. You can buy a coach. So really wanted to use the word exothermic, and obviously, I've touched on ADOP, and if we've got a degree, that's our DevOps platform, then that would be very welcome, too.

I think that's me for time, isn't it, Owen? Must be good. Pretty much. Yeah. Pretty much. I'm happy to take any questions if they are there, or am I not? No.

I'm happy to take easy questions afterwards.

Thank you for your time.