The origin of DevOps is broadly attributed to Patrick Debois five or so years ago - you can learn more about the history of DevOps here. DevOps runs the risk of becoming a word without meaning as the industry rallies to attribute it to every product and service in their portfolio. The reality is that I can't sell you DevOps, and you can't buy it.
DevOps is more than simply automation. It includes things like culture. It's a way of working that values collaboration with a shared view of success. As the name implies, this collaboration is primarily between developers and operators, but it is not restricted to that.
DevOps means that you see the end to end delivery system from concept to production, your DevOps scope is any group that are involved in that workflow. So if you're willing to make a cultural investment in changing how you work, then you can start to implement some of the working practices that DevOps recommends.
But before you jump head first into identifying work and managing constraints, ensure you know why you want to make DevOps part of how you succeed at IT services. Many successful implementations have been driven by a desire to:
• Reduce time to market for new products and features
• Build more agility to adapt to internal and external influences
• Unlock cost savings offered by cloud platforms
• Eliminate the risk of shadow IT services
Successful DevOps adoptions are easy to spot. They are the organisations that talk about making tens and even hundreds of code releases into production every day, where there seems to be a constant flow of new features to keep users engaged and loyal.
The leaders here are internet giants like Google, Facebook, Netflix, Etsy and more. But whilst many of these grab headlines, there are large numbers of success stories where organisations require internet and web services as a significant portion of their go to market channel, examples are Spotify, thetrainline.com, even Rackspace.
Is your organisation a good fit?
From the eclectic list above it should be apparent that DevOps is not an exclusive club, anyone can pick it up and try to make positive changes in their business. However, there are some common traits that identify the strong fit candidates for change:
• Existing strong culture of collaboration and open communication
• An executive leadership team who sees IT as a business enabler
• Sponsorship from a high enough level to allow challenges to status quo
• Revenue and brand derived substantially from web and mobile channels
• Established organisations who view internet start-ups as a threat
• Start-ups who want to be more nimble than their established competition
• Applications that are self-built and developed on open technology
All of these provide compelling business drivers to embrace change as an opportunity to create an advantage in your industry. But the transformation will be hard at times and leaders who are sponsoring these initiatives need patience and clear expectations to ensure the team are given every opportunity to succeed.
As with cloud transformations, DevOps transformations will not be universally successful. In fact you should expect to fail at times. The trick is to fail fast, learn and repeat. Removing fear of failure is deep rooted in culture where incident reviews are a blame session rather than a learning outcome.
This is why it is vital that you must commit to the culture as well as the working practices. However, the risk of not addressing DevOps does carry risks itself. If your competition gets faster to market with features and products, what does this mean for your business? If your competition can open up financial advantages by increasing operational efficiency without impacting margins, how will you react?
DevOps adoption should not be driven by fear, but not making it part of your IT plans should be a well-managed risk in your organisation's strategy.
Where to start
So hopefully, you've reached the point where you're interested in getting started. Here are some prompting questions to get you going:
• Which application am I going to build this model around?
Don't do this wholesale across your IT estate. The application and teams around them are key factors in success, identify a candidate application and create a bubble of autonomy around it.
• Can I draw out the entire process from idea to production release?
Simply drawing out your processes is a great way to identify stakeholders and eliminate waste. Never assume you have all the right people in the room in the first meeting!
• Where are my constraints?
The key to increasing flow through a system is to manage constraints. Creating capacity either side without addressing the bottleneck will not increase output. Work out which parts of your system slow you down and improve them.
• Do I have the skills to execute this?
DevOps skill sets are in high demand right now. Take time to understand if you have the right resources to succeed? If you don't, make plans for additional hiring, training, or look to introduce a third party who can help offload some of the core functions.
There is a huge amount of reference material online. DevOps as an approach values sharing, many organisations have published materials about their successes and failures for you to learn from.
- Chris Jackson is the Chief Technologist for Rackspace EMEA.