I attended a DevOps Connect breakfast briefing at The Royal Exchange on Wednesday 4th February 2015. The briefing, run by Ranger4 and DevOps.com, was centred around a Gartner paper released in 2014 called Seven Steps to Start Your DevOps Initiative by Ronni Colville. This paper lists 7 key recommendations for successfully implementing DevOps. In this post I discuss my insights for each step, based on my experience as well as discussions triggered from this breakfast briefing.
1. Define DevOps for you
One of the most common problems encountered when embarking on the DevOps journey is not knowing where to start. DevOps is being implemented very widely now, and there is a lot of debate and research about what constitutes “proper” DevOps, but knowing how to apply that to your organisation in the right way for your business is the difficult part. Based on my experience, the best place to start for 99% of organisations is to thoroughly assess your current state. Only once you know where you are, can you start to plan how to get to where you want to be – an organisation with high DevOps maturity.
DevOps at its heart is about providing more business value. Any DevOps initiative should begin planning the strategy by analysing the business goals. From there, you can work down to determine DevOps objectives which will further your business goals.
Once you have a very clear understanding of your current state and your DevOps objectives, then you can work out a detailed implementation strategy to get there.
2. Pick an app
In my experience, choosing an application to focus the DevOps spotlight on as a pilot is a good way to start the DevOps journey. Once the enterprise level DevOps goals have been defined (in alignment with business goals), they can be translated to your chosen pilot app. It is important to choose an app which is key to the business as this will help keep momentum and make sure that enough focus is given, particularly from senior stakeholders. If the chosen app is too complex, or if the team are already overwhelmed with “keeping the show on the road” then it will probably not be easy to make real substantial change in that area as your first foray into DevOps. This app will call for a lot of focus from senior management and lots of drive, so it may not be the best app to start with.
Pretty much all greenfield applications are being built nowadays with DevOps principles in mind already. In my personal experience, existing applications are usually the ones which can benefit most from a DevOps transformation. However, the larger and more complex the app, the more difficult it can be to automate. But this is where the value really comes from!
3. Pick the team
One of the biggest challenges to successful implementation of DevOps, which should be addressed right away, is that of the team structure. There is no right and wrong when it comes to deciding how the application team should look. In my experience, a commonly followed structure is to create a completely new team who sit in between the dev and ops teams, and focus on automation initially to fully automate the release process. This relies on the new “DevOps team” having very close relationships with those in both the dev and ops teams, and being able to instrument change while the others get on with their day jobs. We now see people calling themselves “DevOps engineers” – who are primarily automation experts, and they probably fit most snugly into this type of team structure.
Another option is to merge the dev and ops teams into one big team. This straight away gives developers and operations staff an insight into the other side of the fence, and setting up a buddying system to pair each developer with an ops engineer might help here. However, I have seen that this can be a challenging structure as the staff can struggle to embrace the change easily and quickly enough to make visible progress initially. Another factor to consider here is the segregation of duties required in some industries, which needs to be managed effectively.
4. Pick a methodology
Once the application and team have been identified, methodologies should be considered. In my view, if there is an established SDLC already in use, then the best place to start is with a detailed assessment of the SDLC to streamline all the tasks and processes. Depending on the business requirements, moving to a more agile methodology might be suitable as well. Agile is generally very well suited to DevOps as it relies on regular integration and testing, which can only be achieved through well designed automation.
This blog will continue with my views on the final 3 steps to successfully start your DevOps initiative next week.
To find out more about our DevOps Advisory and consultancy services, contact us now!
If you want to get a better understanding of your organisation’s status quo, we offer a DevOps Advisory Assessment Service.