Hi, guys. Thanks for coming this morning. Or, it's my afternoon very much, so I've been up since about 4:00 today. So my presentation is called "Software is Eating the Enterprise," and some of the topics may well have come across in the last couple of days.

But I hope the way that I've presented some of the things might be at least something that you guys can take away. So also, it might be a bit confusing because, on the printout, it said I work at M&S, which is a big retailer in the UK. Obviously, my deck now says something very different. So I'll explain that in a second.

So I've got 30 minutes to go through about 60 slides, so it's going to be like a rapid-fire presentation. I'll probably skim through some of it. But, bizarrely, I actually managed to get this domain name a few years ago, enterprisedevops.com. So if you go there, you can download my deck, and feel free to have it on your laptop as I'm going through.

So very briefly about me. So 2011, I joined M&S at the start of a big program of work to re-platform their website and pretty much a lot of the back end systems as well. So it was about 150 million pound project. And the company really at that point was very good at big projects, very much waterfall.

And I was brought in from these startups. I don't know if these are familiar to you guys in the US. Pretty much their revenue is about 100 million each, but M&S was more like 10 billion. So I was brought in to be the agile guy back then when people didn't really know what the A word meant.

So the purpose of my presentation today is really, fair enough, I used to work for a company that was 10 billion pounds, 10 billion revenue. I'm now working for one which is considerably smaller and four years old. But what I found really interesting and why I think it's still relevant is that everything I learnt whilst at Marks & Spencer, I'm applying every day in my startup. Not my startup, but the startup I work at.

So quickly on M&S. So I was there for three and a half years and, bizarrely, I just created a DevOps team within this big organization because I started to do stuff. I was really brought in to be the dev guy doing the governance on this big program. But actually, over the period of time, we rebranded ourselves, and we got rid of the name DevOps for a while, came back again.

But essentially what we were trying to do was just make the whole organization better at doing software engineering. The team itself, across the world, was about 650 people. A lot of them testers. I think about half of them were testers, which is bizarre.

And we were modifying and building 65 apps. So there's lots of dependencies between these apps. Ultimately, the project was successful. Went live in February this year.

And I think the underlying success of that is lots of different reasons, but one of the key things that people didn't really realize is we always knew where the code was. We always knew which build was in which environment. We always knew who checked in the code and why, and which component was related to another component. So people didn't really have this big issue of, "Oh my god, we got into this nightmare sitting integration phase where we don't know what actually we're testing." It was all very smooth, and we knew what we were doing along the way.

And I set the scene that I was trying to agile enable Marks & Spencer because it was a pretty much a big iterative waterfall, bit of Scrum-ful project. But everything behind the scenes that we were doing would enable us to be product teams and agile in the future because we'd have all that foundation in place. So quickly moving on to Cambridge Satchel. We make things like this.

Handmade in the UK. So we have the same problem, actually, that Marks & Spencer has. We have the same components on our architectural diagram, but we just have it at a very different scale at the moment. Some of which I'm going to build my own, some of which I'm going to go into the cloud.

But essentially, the architectural diagram is exactly the same and the challenges in terms of retailer, picking up in store, shipping to store, buying on the web, is exactly the same whether you're 10 billion or 10 million. So I've joined in the last six weeks, in fact, after a bit of funding, $20 million from Index, to move this company from 10 million to 100 million in the next three years. So it's fantastic for me. I've got a clean sheet of paper in terms of technology, and the lessons learnt at Marks & Spencer's and the DevOps journey that we've been on are actually making me change the strategy of how I'm going to go about building our technology.

So as part of this deck, I've got 10 quick points. I'll try and get through them as quick as I can. So the first one, over-communicate your plan. So I found myself at Marks & Spencer, drinking a lot of coffee and going to lots of buildings and talking about the same thing over and over again.

What were we doing? I think the previous presentation was saying a similar thing. You need to really explain why you're doing this DevOps thing. What does it mean to the business?

I'm very much a whiteboard guy with Sharpies and whatever, so I always had a back pocket of these things and back pocket of diagrams that I could explain. Whenever I was anywhere, I'd be the first person to get my A3 printer out and say, "This is what we're doing. This is what it's all about." And people started to take notice. They were like, "Okay, this is the guy who seems to be really interested in the code and the software engineering stuff." And actually, we outsourced that a while ago.

So this is really interesting that someone's now talking about it and quite obsessed about it. So I got my team to be very similar in that way. I don't know if any of you guys saw the presentation from Stephen Fisherman, I think, yesterday from Auto Trader about trying to talk to different people in the organization. You might have people that are a bit threatened, there might be some people who are desperate to learn, and you have to really reach out and make those friends because you'll need them in an enterprise to try and call on some favors over time.

So this is some of the diagrams. That one on the right, sorry, on the left, is the one that I'll go through a few times in this presentation. But all the time, I was trying to make it visual. How can we explain what this DevOps thing is about?

Because the minute we mention DevOps-People were just rolling their eyes and kind of not listening. So I was like, "Okay, I'll show you a nice diagram. Maybe that will explain what we're talking about." I also stood up in front of the big program on the big day of reckoning when everyone got together, I was like, "Let's start this three-year program of work." And for some reason, I don't know where it came from, I was like, "It's all about the code." When they asked me, "Johnny, what are you doing?" "It's all about the code. We're all here to write code, ultimately." And that stuck with me throughout three and a half years.

I was always from the senior guys. "Oh, it's all about the code, Johnny." It's like, "Yeah, yeah, I know I said that like three and a half years ago." But it really is from application code, config code, test code, test data. We were all getting up and going to work basically to help those developers offshore write some good code and to control what they were doing. I had a few arguments with people about that, but that's very much my view.

But what I didn't mention really back then was the team. So it's about the code and how good your technology is, but it's also about how good your team is. And this is a kind of format that I pulled together. So I don't know if you can see around the room.

Again, feel free to download it. So along the bottom there is the kind of capability within software design and architecture. In the other direction is the team, how good the team is, the process, et cetera. It's very similar to the electric cloud version yesterday, but I can only think in two dimensions, so this is what I was sort of communicating.

So if you look, the speed of delivery is kind of towards the top. So if you're in the top right-hand corner, you're that kind of U word. I won't even say it. I think everyone's heard it too many times this last couple of days.

But you're pretty good at getting software out if you're up there. And you've probably got really good technology, and you've probably got a really good team, probably paying them the top 10 percentile to enable that to happen. So if I flick through these, right at the end, over here in the quarterly release cycle that maybe your enterprise might have, fundamentally, you've got bad working practices and bad software. It's hard to admit that, but even if you've got some great legacy developer writing some crazy code and he's fantastic, the fact that that software is dependent on 50 other systems and there's no automated tests and there's no automated builds, actually in my view makes that pretty poor software.

And the fact that his working practices are such that it's getting released every quarter is also not particularly great. So as you walk through the different scales, you get to the point where you've got great software and a great team. So I think you probably get that. So please understand this diagram because I'm going to use it throughout my deck.

So then you come to excellence and craftsmanship. I think someone else mentioned this the other day. So we very much treated all of the stuff that we were building as a craft. It's not a really boring subject, software engineering.

It's a craft. And if you treat it as such, actually it's very beneficial for the organization. So the way I see it, getting a quarterly release cycle and that big integration phase, those very expensive environments with IBM backends or whatever. It's very expensive and to get 30 applications all talking to each other with the right test data, with the right teams and multiple people sharing these environments, that can go into hundreds of thousands of dollars or even, I think in some cases, like a million dollars for a real integration test environment.

As you go up the stack, it's getting a bit cheaper because you're in the cloud, you've got all these things. You might have a really expensive team, but it's a much smaller team. You're not wasting your money on rework and the cost of building the wrong thing. So second, I probably need to speed up a bit.

I'll go through this quickly. So I had this issue where my team were insourcing some of the devs, so most of it was offshore. But we were saying, "Well, we had a strategic direction to get some in-house talent to start to own a lot of this stuff and own some of the software engineering." So I was in the position where I had the developers on the ground wanting to do all this stuff. I had the senior board saying, "Yeah, these companies over here can release 10 times a day.

We want some of that." And then everyone in the middle going, "What is this?" And I was kind of in the middle there saying, "This is what it is. Here's my diagram. Let me take you for a coffee. Let me explain it." But ultimately, it was around pace.

So this is a diagram, very simple one, of an e-commerce system. It's got a product information management system, an e-commerce backend. It's got a finance system. It's got a frontend and an app.

So ask the board, "You want to release 10 times a day, but do you really want to release all of this 10 times a day?" And I was struggling coming from a startup background thinking, "I really would love to do all this stuff. At my last company, we did all this kind of automation, but I'm stuck with this big thing and I've got the board saying we want to release this every day." So what we did was, before Gartner really came up with their pace layering, we said, "Okay, we're going to do paces." So we're going to say, "Some of this stuff we're going to release really fast. Some of this stuff we're not going to release really fast because we can't." And actually go back to people and say, "Is this what you mean? Do you really want the backend finance system to be deployed every day?

Do you really want that payment system that takes £10 billion a year to be deployed every day? You probably don't, and you're probably happy with the governance and systems to help that compliance." So again, putting it on the chart, you can then explain what you're trying to do. So yeah, we're going to aim right at the top there to get the frontend really well architected and we're going to try and release that every day. But we're not necessarily going to touch the finance systems because that's just going to take us years.

And of course, this will only really work if you've got good separation between these systems and we were lucky at the time to have APIs between each real big system.So you probably want to be here, but do you want to be there for everything? And I think if I was sat in some of these presentations earlier and saying, "Well, yeah, everyone's doing all this stuff really fast." And I'm sat there thinking, "Yeah, some of it you can do really fast and maybe some of it, don't bother right now." And that's the kind of judgment you need to take in trying to be able to explain it. So time for a bit of animation. There you go.

So really, are you going to try and move this entire stack in the right direction? Or are you going to leave some of it and selectively choose where you're going to go? So this relates to kill dependencies. I'm really going to have to speed up.

So again, the same diagram. This bit, sort of the lower quadrant, if you want to call it that, is what I started to call the legacy zone. So that's the stuff that generally enterprises have. They're quite a way from being this company that can do really cool funky stuff at the top.

But it turns out that enterprises can do that stuff at the top as well. There's no reason why they can't do that. It's just that that is probably a smaller app. Maybe it's something that's above an API, or maybe it's a mobile app or something that can run in a completely different life cycle to everything else that you've built before.

And when we started to think like that, it was really interesting. So one of the patterns we started to look at was, okay, we've got this big ear file, for example, a big Java app. We want to deploy it every day. It's got so many dependencies, and it's got very little test scripts or anything to really be able to do that every day.

So why don't we just shrink that a bit and take out the bits that we really want to deploy every day and move that bit into the fast area? So actually, we moved to a model where this big e-commerce platform, we kind of kept where it was and produced a front end in a different technology that we could actually recruit for, that enabled us to publish the front end at will, in fact, more than 10 times a day. So remember, this is a company that's 130 years old, and suddenly they've got bits of their application that they're getting out really fast. So I guess you've all seen this book, probably, "The Lean Startup." And everyone in the whole organization is saying, "Yeah, we want MVPs." Everyone wants an MVP.

"Let's do some little small thing here, and we'll get that out tomorrow." That's all very good and well if the product owner understands DevOps and understands the relationship between the bits of the application that will make up that MVP. So in this model, you've got the new funky little app that they want as an MVP up the corner there. But if you're not careful, it's got some dependency on some legacy application that needs to be tested with some legacy app. And then suddenly you're in a non-viable product.

So you've got to choose something else to be your viable product. I'll let you potentially download these and look at it. Don't create new legacy. So I like the phrase, leave a legacy, don't create legacy.

So I feel I've left a bit of a legacy at M&S, and that's they're at least doing DevOps, and the board knows about it. And hopefully, I didn't leave any legacy with me, with some of these new applications. So it's very easy to do that, though. You start a new initiative, and you're saying, "Yeah, we're going to do some test-driven development, and we're going to do some automated deployments." But then the project manager comes along on sprint four and says, "You know what?

We're running a bit late. Why don't you just stop doing that automation that I don't really understand anyway?" Then suddenly the capability of the team is such that they're no longer that agile team that was really good and could do a sprint and get it out the next day because they haven't got all their scripts updated. And then I've seen this happen. Suddenly that really interesting, let's do this really cool app, has again got a dependency on some other system, a back end system.

Then suddenly, you've actually just created some more legacy because that has to go out on a quarterly release cycle with everything else. I'll just skip through this. So for those who came in late, you can download this at enterprisedevops.com, which is my link. So this is another key one that I kind of distilled from my experience that it's definitely not just an IT problem.

In fact, the IT part of it is the easy bit. In a big organization, you have these big project methodologies, and I turned up from startup world and there's all these acronyms that... HLD. I was like, I didn't know what HLD was.

A bit embarrassing to say, "Can someone explain what HLD means?" "Oh, it's a high level design." "Oh, of course. Right." HR recruitment and reward. At the very highest level, sometimes the CIO has got the wrong structure, which is forcing people to have the wrong behavior. And also reward.

In a large organization, it's very difficult to say, "Well, actually, for this agile team over here, we're going to start paying them on the success of the team rather than individually bonused and on some kind of bell curve." One of the key things is about the finance and procurement. Lots of tools that I wanted at the time didn't come about because it wasn't corporate policy, or there were particular reasons that we couldn't find the money to actually get them. So again, you've kind of got this equilibrium that everyone's trying to get up into that top right-hand corner, but then potentially you've got the wrong hiring policy, and you're not getting the people who actually know how to do that stuff, or they're just not up for it. You've got the wrong team objectives and the wrong third party.

So your third parties might be on a not on a time and materials basis. There may be no need for them to actually try and automate anything because they're quite happy with 50 people doing manual tasks. As I said, the wrong contractual and financial frameworks. Definitely the wrong technology choice.

So in the e-commerce landscape, there's loads of big applications that you can buy, but none of them haveTests. None of them have build automation. None of them have anything that actually makes you move into the top corner. So you've got to be really careful.

And probably when you're thinking about what technology you want to bring in, ask that question, do you have those things available? So you're a unique thinker for yourself. So this actually I found quite interesting because in London, there's this kind of anti-pattern DevOps team. So everywhere I went I was like, "Yeah, I've got a DevOps team.

They're building DevOps capability." And people are like, "Johnny, that's such an anti-pattern. You shouldn't have a DevOps team because it's just not the done thing." I was like, "Okay. Oh, forget that. I'm going to have one anyway." So we found having this team that could create the Amazon accounts and not worry about that and get some of the Jenkins stuff installed and just do some of the framework behind the scenes that would then enable different Scrum teams to have a head start, really bootstrapping their DevOps journey, really helped us.

I hear some people say, "Well, I'm going to, over time, get rid of this team." But actually, these guys are doing a quite solid job of just getting a bit of clarity on some of those tools that we're using. It's not to say you can't use other tools, but if this team are doing the right job, an individual Scrum team will go, "I'm going to use that because that's going to save me time rather than reinventing the wheel in my own way." And so think for yourself. So up in the top quadrant, there's loads of blogs and loads of things you can read about. As you go further down, it's much more unknown.

And I guess over the years, if this conference continues, it'll become a bit clearer what's happening down there. But I guess what I'm saying is, there's an opportunity for us to really understand and learn and try things out because people just haven't done it yet. And actually, the enterprises are so complicated that you're going to have to make your own innovation around how you get DevOps to work in an enterprise. We felt our way through and I had a bit of a good situation that people didn't really understand what I was doing, so I could just get away with stuff.

But in a lot of enterprises, it's very locked down and individual roles are very difficult to shift. But it's about thinking, okay, there's all these cool people doing all this cool stuff, but I've got a really hard challenge. That's actually quite easy. I'm going to try and do something innovative with my mainframe or something.

Make your tools work for you. So I had every vendor on the planet probably come to me and say, "Oh, you've got this big program. You need these tools." And I spent a lot of time looking at most of them. So if you're interested in any tool, feel free to drop me a line.

I'll give you my verdict. But ultimately, it shifts you a bit. It might make your team a bit better. It might make your software a bit better because you now automated some stuff, but it's not going to solve your problems.

Your problem might be that you actually chose the wrong technology in the first place, or you need to think about refactoring it or train your team to be more agile. Another thing that we found was about tool sets. So I won't name any names of some of these enterprise testing tools or configuration management tools, but none of them fitted what I wanted. And I was fighting for about two years to just get my own tools, which by the way, were free, which was interesting in itself.

And build a software factory. Again, I don't know about in the US, but in the UK, this idea of having a factory is quite, what's the word? It's not very popular and it sounds a bit like, oh, you're trying to get these developers to be just a machine. But actually what I'm talking about here is there's a lot of repetition in setting up some of these systems and connecting these tools together.

For me, that's just a factory. And it surprises me actually, here's a foggy US traffic light. But I think a lot of CIOs are like, "I've got all these teams. I've got hundreds and thousands of people, but I don't really know what they're doing other than this rag spreadsheet I get every Monday with different colors on it." Whereas for me, I want to know exactly what's going on, what the suppliers are doing, what they're checking in, how frequently we're building, what features are being deployed.

So for that reason, we went about creating this factory. So I'll just skip to it. I've got to thank this other company, Magenta, for these slides because I didn't do these ones. So essentially you need some tools that control your requirements, and they have maybe your wiki, so you keep all your documentation in one place.

We actually did a lot of behavior-driven development, so we've got a little thing there, you probably can't see from where you're sat. A tool that linked those tests and features and documentation together. And then something to actually build the code, something to store your code and your binaries. And in an enterprise, you often have a lot of binaries that are third party.

Whether you bought this system and this third party updates it regularly. But you've got to treat that as if you own it as well. And you've got to config manage their binaries as well as your own code. And then systems to run your tests.

This is where it starts getting a bit funky. So someone checks some code in, and this master application tooling, we were using Jenkins but there's many other things you could use, triggers the need to build your code. Now, if you're an enterprise, you've got lots of things being built. You can't rely on just one Jenkins box down here building all your code.

So I was lucky that I had a team who were really into Amazon and elastic environments. So every time we wanted to do a build, we would build a slave that was just doing this build job. So it'd run the build, it would scan the code. And importantly for us, it would run Fortify, which is a security scanning software, so that the security team were happy from the minute we checked some code in that we were thinking about security from day one.Then you need something to run your test.

So we had another kind of slave that said, "Right. What am I going to do now? I've got this build and I've stored this build. I'm going to run the tests, provision an environment, and then provision a test lab." No one seems to talk about this test lab.

It's not very much use having your test running on Firefox, if you've got every other browser on the planet that's actually using your system. So for test lab, we actually use Sauce Labs and BrowserStack. I'm not sure if there are other ones. But essentially, you pass your test suite to them, and you say, "Run this on these devices and these browsers." And then the result of that can come back to your tooling and say, "Yep.

We're good to go." Or in that case, something failed. And the beauty of this is that these are things that you've just spun up. And in that test environment, we would store all of the outputs of that device. So even if the test environment was then killed and shut down, we'd have the logs of what happened when we were actually using it.

So yeah, you can get rid of these things and maybe keep your test environment. So if you imagine the power of this for a tester, so there's a requirement that's linked to this feature file, which is your BDD specification. The developer checks in the code, it updates the ticket. It then kicks off a build that then updates the ticket to say, "Yeah, I built okay." It then kicks off your tests, which then says, "Yeah, that ran perfectly." And then what we had was a way of putting in the ticket the actual test environment to test in, because my history of testing was that so many times a tester's like, "Hey, I finished my testing.

Hate to tell you this, but you've come in early and went home late, but you've been testing the wrong environment." And sadly, I've seen that more than once. So it's about having a full information about what you do. So this was the stack of things that we plugged together, and there's a few stalls upstairs I noticed that you can buy some of this kind of glue that does some of this stuff. Whether it's quite the same as what we did, I don't know.

But ultimately, these things down here, whether it's in my world, in e-commerce, whether it's WebSphere, ATG, Hybris, or Demandware, or something else, it's kind of irrelevant. The fact that you've got to test something and you've got to store your requirements, you've got to store your code, is the standard thing wherever you are. And this was really important for our suppliers. So most of the code was written offshore in India, but we forced them through our factory, so we knew exactly what was happening.

You can do what you like in Delhi, but until that code comes into my code, and until I build it, and until I scan it, and until we package it, I don't really care what happened. And that really helped us control what was going on. And again, I think it was one of the successes of that program. So I've started this new role.

I've got no technology. I'm building some. But the first thing I'm building is, in fact, this factory. In fact, I can't see how you can work without one.

We're manufacturing code, and we need some way of handling it all. So certainly one of the first jobs that I'm going to be doing. Couple of minutes left. I mentioned behavior-driven development.

I don't know how many people here have come across it. It's definitely quite big in London. I think it probably originated there. A guy called Dan North.

But quite honestly, I've tried Agile throughout my career, and it wasn't until I started doing BDD that actually everything started to fit together, and people were doing automation all the time. And forcing people to do feature files actually represented what we were trying to build and storing that feature file with the code, with the tests, so we were keeping everything updated. Recently, was looking at an e-commerce platform, and they were saying, "Yeah, yeah, it's great now. We support DevOps because we've got this thousand suite of Selenium tests that go with it." I'm like, "Okay.

What about when I start changing that system?" "Oh, yeah. Well, that's up to you then." For me, that's no good anymore. The features, your tests, your data, your config needs to be one whole that you can pull together. So last tip, prepare to be the enterprise of tomorrow.

In fact, prepare to be the large enterprise of tomorrow. So that's my plan at Cambridge Satchel. There's so many decisions that you can make that actually you end up... I'm not saying the enterprise is a bad place to be, but there are certainly things and decisions you can make today that will help you in the future.

I stole this diagram, so I probably need to put some reference to where I stole it from. But this is just trying to show the trajectory of trying to get this DevOps journey working does rely on a lot of coordination and thought, otherwise you just end up probably back where you started in legacy world. So for me and Cambridge Satchel, it's a new world out there. There are SaaS platforms, et cetera.

So the plan is to not even have these things to worry about. I'm going to focus my team that I'm going to recruit on the front end, on the apps. I need to work on this order management system to sell the bags. So I'm going to move them into this space.

I'm going to make sure that we're really good at that. But all the rest, I'm just going to get off the shelf, whether it's Salesforce, Zendesk, whatever. I don't want that problem because I want my team to focus on the top bit. Things I'd like help on, test data in complex environments.

I haven't really seen anyone do that really well. Also, behavior-driven development. How do you make sure that everything stays in sync at all times? And this whole idea of this DevOps factory, and I'm about to go out and build it again for myself.

But if anyone has already built it or there's a way of just buying one, let me know that isn't millions of pounds. And that's it. Thanks for listening. As I said, I've got a blog which no one really ever goes to, although it's quite a good domain name.

But you could download this deck from there, and I'd happily take comments or email me. I'm really fascinated by the subject and would love to help you guys out, and likewise, share experience. Thank you.