I attended Computing’s DevOps 2015 summit yesterday (Wednesday 8th July at Hilton Tower Bridge). Let me start by saying if you have a chance to attend one of Computing’s conferences do so. It was incredibly well organised, the material they presented to kick-start the day was really interesting and all the presenters and panelists had insightful and useful experiences to share. There were a few threads that that seemed to run throughout the day and some of them took me by surprise. I’m going to highlight a few of the things that struck me from yesterday while they’re still fresh in my mind but I also encourage you to search twitter for #ctgsummit to see the stuff we were tweeting about during the day.
“attendees from small businesses to banks, from insurance companies to retailers have accepted DevOps as essential”
I was on a panel discussing the business case for DevOps. What impressed me the most was that we didn’t really discuss the case for DevOps at all. It was clear the attendees all understand that DevOps is essential. We spent most of our time talking about how DevOps can work in heavily regulated environments, how to make a compelling case for DevOps to non-technical executives and how to rapidly show the value of taking a DevOps approach. It’s been obvious to me and many others, for sometime, that DevOps is the next step in Technology’s evolution. Last year was frustrating because of all the talk about DevOps just being for unicorns and the distraction of enterprise DevOps and bi-modal IT. While I’m sure we haven’t heard the last of all that attendees from small businesses to banks, from insurance companies to retailers seem to have accepted DevOps as essential for their future. Now we can have much more interesting discussions about how we approach DevOps transformations.
“Some of the most successful modern businesses started their DevOps initiatives ten years ago.”
That leads me to something that irked me yesterday. I wasn’t really in a place to object as the comment was raised during a later panel event. There’s still the impression that the best way to approach a DevOps project is to start with a small initiative. I’m sure that’s the easiest way to do it and I’m sure it requires the least investment and hence convincing of executives but I don’t think it’s the best approach anymore. Some of the most successful modern businesses started their DevOps initiatives ten years ago now. Think Netflix, Etsy, and Amazon Web Services, these companies are now giants. They also talked extensively about the methods they were using at the time and continue to do so. The next generation of successful companies learned from those lessons and now the Fin-Tech industry is poised to do to Wall St. and The City what Netflix did to the cable companies. If you start with a small DevOps initiative now and it takes you 2-3 years to complete your transformation you might well be surprised by who your competition is when you complete your journey. You might find yourself a decade behind companies you’ve never heard of who are eating your market share.
“the biggest barrier or advantage to DevOps is senior management buy-in.”
Another consistent thread that ran through yesterday’s event, from Computing’s own Primary research presented at the start of the day through every panel and presentation was that the biggest barrier or advantage to DevOps is senior management buy-in. I know from my own experiences that without senior management buy-in a DevOps approach is limited in what it can achieve. Lack of senior management buy-in held us back from our ultimate potential at Playfish and it’s one of the reasons Hive has been so successful. If your business is considering tackling a small DevOps project because you’re struggling to get senior management buy-in I suggest an alternative approach: There is an absolute wealth of documentation out there that states very clearly that responsive technology departments make their organisations more successful. There is another wealth of documentation demonstrating that DevOps makes IT departments more responsive. Puppet and Thoughtworks produce the State of DevOps Report that makes those points very clearly. Harvard Business School and Oracle have a report that makes a similar point. Computing’s Primary Research certainly suggests it judging by the data I saw yesterday.
“the product-centric approach to DevOps was another popular theme.”
I was my very pleasantly surprised, yesterday, to see the product-centric approach to DevOps was another popular theme. This is particularly gratifying to me because I wrote a whole book about why that’s a great approach and how to implement it in technology organisations. It’s been a hot topic with various DevOps luminaries in recent months but it’s clear that many organisations are making it work. Boyan Dimitrov told an amazing story about Hailo’s product-centric DevOps transformation. What I find most remarkable about Hailo’s story is that they understand that a product isn’t just something that directly generates revenue. Their back-end services are also products in their own right. There was a lot more than this short summary but I wanted to highlight the particular themes that really stood out for me. If you’re considering a DevOps transformation and don’t know how to get started feel free to get in touch.
This week’s update is another short one we’ve just come back from an awesome holiday in the lake district. I’d had an intense few of weeks of writing and interviewing and then to top it all off I contracted some sort of flu or virus thing. Kylie’s contract had just come to an end and so we decided to take a short break before she started her next one. As you can see we had a great time and the weather was wonderful!
I love the lake district.There’s something about the fresh air and the countryside that really refreshes me. If anyone in Cumbria is considering a DevOps transformation please feel free to get in touch :).
I’ve returned ready to get the framework into a first draft state and published on Github so you can all get your teeth into it. On that note Kylie has finished her initial assessment and she’s provided some initial feedback that I’ll be working on this week.
Finally I’m participating in a panel discussing the business need for DevOps at Computing Summit’s DevOps 2015 event next week, July 8th. I hope I’ll see some of you there If you’re not interested in seeing me speak you should definitely hear what my friend Phil Hendren of Mind Candy fame has to say. While I’ve been leading DevOps initiatives and teams for the last 6 years Phil’s been engineering the solutions that make it happen you can find Phil’s blog here, it’s a great source of practical DevOps advice and tools.
I’m late bringing this to you as I’ve been ill for a few days so please accept my apologies. Last week I read a great piece that makes a really strong case for DevOps. If you think businesses can continue to thrive while they isolate their software, operations, network and test engineers in separate teams and assigned to projects by resource coordinators then you need to read this article.
I won’t write too much more here because I really just want you to read Ms. Macvittie’s article. I do want to close by saying that I’ve heard a lot about the dangers of optimising too early I’ve also seen many examples of what happens when you optimise too late. I think cross-functional product-centric teams can help maintain the balance between feature development and optimisation whether that’s service optimisation as discussed in Ms. Macvittie’s article or refactoring: https://devcentral.f5.com/articles/microservices-and-http2
* Featured image: cotswold-stone-wall.jpg by: thesuccess found on: Morguefile.com
I know that some of my readers are impatient to get their hands on the my new project: the Next Gen DevOps Transformation Framework. I’m as eager to release it as they are to play with it but it isn’t quite ready for it’s public debut yet. I have created a project in Github where I will release it but at the moment it just hosts a readme. If want to keep an eye the project you can find it here: https://github.com/grjsmith/NGDO-Transformation-Framework
With the framework I’m attempting something quite challenging. I don’t mean writing the framework, anyone who’s seen DevOps in action and read around the subject a little could create a framework for a DevOps transition. The challenge is presenting it for two audiences with two very different perspectives. I’m trying to create something detailed enough that engineers and managers can argue about it and contribute to it and yet something simple enough that budget holders can understand at-a-glance what they might be getting their organisations into.
Two months ago when I announced I had started work on the framework I mentioned that one of my goals was to create something that would have helped me while I was at EA. I failed to convince the central operations group to adopt DevOps, I was able to convince them of the benefits of DevOps but I couldn’t present them with an approach that they could plan and budget for. The framework successfully presents the scale and complexity of a DevOps transformation but I’m struggling with presenting the evolving benefits of the DevOps approach as the organisation progresses through the framework.
That’s where my secret weapon comes in. My girlfriend Kylie just happens to be a very talented Business Analyst. One of the things Kylie excels at is presenting complex data simply and effectively. Kylie’s working on the framework now and we hope to have the first version ready for release by the end of June.
Much has been written on the subject of corporate culture, more has been added since the advent of DevOps. Luminaries such as Patrick Debois, Gene Kim and Jez Humble all talk about DevOps and Culture on a regular basis. Every organisation I’ve worked in has been obsessed by it’s culture. After 20 years in small startups and global enterprises I’ve come to the conclusion that culture isn’t something that can be controlled, measured or managed directly. This gives me a great excuse to paraphrase one of my heroes the late great Sir Terry Pratchett: “THEN TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF CULTURE…”
Culture is created as a by-product when we work and play together, the nature of our culture is determined by our purpose and habits. A group that is encouraged to learn from failure and improve as a result will be curious and innovative. A group that only looks inwards for help and is discouraged from interacting with other groups will become defensive and narrow-minded. Groups have a tendency to reach out to other groups when they can speak the same language and have the same goals. Groups tend to become defensive when they perceive they have different or opposing goals to the groups around them, they take on a besieged mentality when they don’t even share terms of reference with the groups around them.
If you want to change a group’s culture you need to change how they work together, how they work with others and the habits they share. If you want a culture of innovation you should expose people to foreign ideas and concepts by creating the opportunity for groups with different skills and perspectives to work together on proposals that will become new projects. If you want a collaborative culture you should create the projects that require people with different skills and perspectives to collaborate.
As far as I can tell, there are currently two successful DevOps models. The directly collaborative cross-functional team model that encourages groups to work together to deliver services and the Service/API model that encourages groups to have rapid, predictable interactions by presenting APIs to each other. If we want collaboration we must break down the silos and allow engineers with different expertise and perspectives to work together. Consider a monitoring/feedback project where software, operations and test engineers work together to delivery better quality tests and monitoring. If we want groups to communicate with each other’s services via API calls we need to ensure all groups have the resources necessary to create good quality API’s. That includes Network, Operations and Test functions as well as focusing on the APIs between services and between clients and services.
The choices we make about how our teams work each day, the things we encourage them to do in the morning (whether we encourage them to check out the quality of the service or just look at their teams project progress) how we encourage them to behave when they make a mistake all contribute to the culture we create. We choose our culture when we decide how our teams work together and what we ask them to focus on and the opportunities we present them to learn, grow and receive recognition. In my experience DevOps happens when the opportunity exists to collaborate.
DevOps accelerates the rate at which the opportunities to collaborate present themselves. When I joined Playfish the Operations team existed as a service provider to the game and platform teams. Operations then built a few tools and shared the code with the games and platform teams and that created a few opportunities for operations and software engineers to work together. As those collaborations yielded more and more interesting and valuable results the level of collaboration increased as did the quality of the service that was provided. This then made more software engineers curious about operations and that yielded more opportunities for collaboration and learning until we had some teams that were almost entirely self-reliant for their regular day-to-day activities that made more space for greater levels of collaboration and so on and so on…
I write a lot more about how to build and foster collaboration in IT organisations in my book Next Gen DevOps: Creating The DevOps Organisation. Available on Amazon now.
*Image credit: Yoel on Morguefile
Since I started working on the framework I’ve had the idea that I wanted there to be a visualisation of the entire framework.
I have a visual imagination. I’m most comfortable considering the big picture and I wanted to give people, like myself, an at-a-glance view of the framework. I also thought it might help people understand the scale of the framework and help place their organisation within it.
I’ve had four major attempts at this so far and I think I’m getting there. Unfortunately the Scrabble people might sue me if I go with this version :):
There must be millions if not billions of words published online about how to start a new project.
I know there are because I read a lot of them before I started writing Next Gen DevOps: Creating The DevOps Organisation.
Most of these articles can be boiled down to two main pieces of advice:
1. Step back from the project and look at the whole domain and then create a structured approach.
2. Dig in a little and get started until you get a sense of the complexity of your project and then step back again and take a second look.
So why does everyone starting a DevOps transformation immediately get cracking on Continuous Delivery?
It’s, arguably, the hardest technical activity in a DevOps transformation. Continuous Delivery in an enterprise with even a couple of years of legacy might involve the orchestration of hundreds of configuration items, the management of thousands of variables and an extremely complex validation process to ensure everything works as it should. There are organisations out there who still aren’t benefiting from reliable continuous build processes who are nevertheless downloading configuration management tools and starting to code the management of application properties. There are still businesses who consider testing to be an entry level role who are trying to get their entire estate to deploy continuously multiple times a day.
Don’t get me wrong I’m all for Configuration Management. If you can get that nailed you unlock a vast amount of potential, it’s just that it’s starting in the middle of the project!
I don’t know where your organisation is or where your strengths and weaknesses lie but before you start building building complex models for divining properties and environment variables you could consider configuration files as artefacts. Manage the creation, modification and deployment of those like you would your applications. You could also ensure you have your deployment tools in version control and treat them like you do your revenue generating services. Manage the development of them with stories and ensure their development keeps pace with the development of the services they need to deploy.
If you really want to push the bleeding edge you could include systems and testing experts in your development projects and ensure that your testing, monitoring and deployment capability is as sophisticated and as capable as your revenue generating services are
Good luck out there and feel free to drop me an email if you need a hand.
Oh and if anyone is wondering about the featured image, that’s my Dad teaching me to climb trees. If the reference is too subtle you start climbing trees at the bottom of the tree where it’s simplest but sometimes hardest to get a good grip :).