If structural engineers built bridges the way software engineers wrote software, then the news would be filled with stories about bridges collapsing. Of course, this is not the case because the engineering process for building bridges is well defined (and has been around far longer than software engineering). Bridges and structural projects are built on strictly defined specifications and with requirements that do not deviate. So is this even a fair analogy?
Imagine a structural engineer that had to make massive changes to a bridge while traffic was crossing it. In this scenario stories about bridges doing unexpected things, like falling down, would be more commonplace. No, the analogy is not fair at all! Writing software has become far more complicated because the old days of writing code that is built on strictly defined specifications and requirements which never deviate are gone. To clarify this point even further, consider the following. Amazon releases a new software update every second, Google every 10 seconds, and Netflix every 90 seconds. Imagine the bridge you are crossing was being updated at that frequency. I doubt you would feel comfortable crossing bridges like that at all. What if one of those updates to the supports was flawed? These are the challenges software engineers have to cope with on a daily basis. This is why the DevOps model exists today.
The consensus regarding the definition of DevOps is that it is a process that unifies the roles of software DEVelopment and IT OPerationS. These are not separate, but interdependent entities that come together to put software into production. Once you move past that definition, the debate continues about what exactly is DevOps because it can encompass many things.
At FP Complete we define DevOps as stated above, but with the addition of all the tools, processes, and people that come together to produce software that has the shortest time to market, least amount of errors, and least expensive cost. This trifecta is an engineer’s dream – faster, better, cheaper. To realize this dream, you can’t ignore that there are always tradeoffs between faster, better, and cheaper. Would you want to cross a bridge that was constructed fast and cheap, knowing that quality was compromised? On the flip side, if you were in the bridge building industry how could you compete if you had the world’s safest bridge, but it cost 50% more to operate and twice as long to produce? This is the balancing act the DevOps framework tries to resolve in the production of software.
If your company values increased productivity, profitability, and market share then DevOps is essential. Even if your goals are non-financial, DevOps will enhance your ability to achieve those goals. The State of DevOps report soundly backs up these claims. More importantly, if your competition has already implemented DevOps and you haven’t, you are already behind. That’s how Walmart feels now that Amazon has built the world’s most efficient shopping platform.
When your organization moves towards developing a DevOps culture, it’s signaling to everyone that participates in the production and release of software they have an equal stake in the success of the company. It’s an all for one, one for all mentality that will break down the communication barriers between teams and make everyone accountable. Once DevOps roles and responsibilities are implemented positive changes will occur, and everyone wins.
The biggest winner is the end-user of the software you produce. They get software that doesn’t crash because it was properly tested in QA. They don’t have to wait for the features they need because your continuous integration/continuous deployment (CI/CD) process ensures they get what they want as soon as possible. Most importantly, now that you have selected the right tools and have automated much of the software build and release process you can produce and operate your software for less. Those savings can be passed along to your customer and give you an edge on your competition. In short, when your customer wins, you win.
To start down your path to DevOps success you need to build a proper DevOps organization which includes all the proper team members. However, the size of your organization plays a big role on how granular you can be with your team. But size doesn’t really matter if you properly define the roles and responsibilities across the organization. The important thing is to make a commitment to the process and get started
The core responsibility that needs to exist is the person who owns the entire DevOps process. This person would usually be someone in a senior position. They are the keeper of the process and procedures and guarantor of the delivery of DevOps value. I like to think of this person as the DevOps evangelist. Aside from the leader, you would need to establish, at a minimum, the following roles: Code Release Manager, Automation Expert, Quality Assurance, Software Developer/Tester, and Security Engineer. The DevOps duties for each of these resources are described below.
In building your DevOps team, you may have to incorporate some of these responsibilities under a single person due to resource constraints or hire an outside consulting firm like FP Complete which can augment your team with the proper skill sets.
As any HR manager will tell you, drafting the perfect job description to get that ideal candidate is more of an art than a science. The internet is polluted with job descriptions for DevOps personnel, and a quick Google search will back up that claim. FP Complete is continuously searching for DevOps Engineers in our own job listings. The most important thing to consider is the culture of your organization and your business objectives. Make sure the job description emphasizes these two points and how important they are in your final candidate selection. Aside from the obvious technical skills your employee needs to possess you are looking for a team player who has excellent communication skills that enjoys taking on new responsibilities and is goal oriented. One caution, don’t select someone who is a technical fit but may not be a cultural fit. That one bad apple will ruin everything you are trying to achieve with your DevOps organization. At a minimum you want to fill the following roles.
Your decision to implement DevOps is sound, but now you must make sure you can execute. There are many things to consider when heading down this path and these six tips will ensure your success.
Most people would like to have a fully functional DevOps environment tomorrow, but taking on everything at once will doom your project from the start. Boiling the ocean is an impossible task so why try? Start with something you can boil, like a small pot of water. In other words, find a small DevOps project and make that successful. It could be as simple as implementing automated testing, distributed version control, or some other automation task. DevOps is all about automation so find a task to automate and get started.
By demonstrating a small win, you minimize your risk of failure and prove to yourself, your team, and management that DevOps works. Also, this makes it much easier to measure the benefits of this win. For example, you may be able to state that you were able to speed up testing of software by 43%. Don’t stop there. Translate those savings into money. If you were doing manual testing and this automation reduced that manual effort by 43% then do the math and show off the results. These concrete results will get everyone excited and hungry to do more. By combining a series of small wins, you will soon have a big win to brag about.
It’s not likely you are going to do everything right the first time you try, so get out of that mindset from the beginning. Things can, and probably will go wrong so learn from the experience then adapt and change. With all the DevOps tools and advice out there, it’s not hard to get overwhelmed and choose a tool or process that is not optimal for your needs.
More importantly, the openness to failure makes this less stressful for the team. Creating a culture of experimentation and learning allows them to feel invested in the process. Encourage the collaboration between the teams in the decision-making process to start breaking down any pre-existing barriers.
The control
mechanisms that are currently in place to manage your people and
projects may not be
suited for the
DevOps world. You have to be willing to look
at items that prevent agility, scalability, and responsiveness and
change them. DevOps will provide agility, scalability, and
responsiveness, so anything that hinders that process needs to be
aligned with the new model.
The are many people involved in the delivery of production software, and DevOps needs to include them all. The chain will only be as strong as the weakest link, so communication across the entire DevOps chain is critical to success. This has to go all the way up to executive management. Don’t just say the words and hope for change. You need to create incentives for desired behavior and build that into the process. Focus on the items that create the most value for your customers – the people who use your software. After all, it’s all about them. Instill this customer first mentality in your team so that they can focus on work that creates value for their customer. This will help remove the internal power struggles that may exist because the customer is always first.
Everyone in the company is sailing on the same ship. If the tide goes up so does the ship and everyone on it. But if the tide goes down so does the ship, but no one on the ship is to blame. It’s critical that when things go wrong, you don’t go into blame mode. DevOps is a team sport and when things go wrong everyone steps in to make it right. Singling out a person or team for a failed deployment will set you up to fail in the future because it will immobilize your team. No one wants to look bad, and if they know they will be shamed for making a mistake, they will shut down, and all your DevOps gains will be lost. Create a culture that celebrates wins and forgives and forgets losses.
No one expects you to know everything or make things happen overnight. The DevOps journey will take time, but if you are in a rush, there are plenty of resources to help you move faster or make fewer mistakes. If you have the budget for some outside help, then do your homework and make sure you find a company that is in line with your culture. Leveraging another company’s expertise to help you build your DevOps environment and culture can work incredibly well when you find the right partner.
If you liked this post you may also like:
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
