Jul 24, 2020
DevOps Roles and Responsibilities
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.
What is DevOps?
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.
Why is DevOps Important?
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.
DevOps Team Structure
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.
DevOps Job Descriptions
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.
DevOps Evangelist - the DevOps leader who is
responsible for the success of all the DevOps processes and
people.
Code Release Manager – essentially a project
manager that understands the agile methodology. They are
responsible for overall progress by measuring metrics on all
tasks.
Automation Expert – responsible for finding
the proper tools and implementing the processes that can automate
any manual tasks.
Quality Assurance or Experience Assurance –
not to be confused with someone who just finds and reports bugs.
Responsible for the user experience and ensures that final product
has all the features in the original specifications.
Software Developer/Tester – the builder and
tester of code that ensures each line of code meets the original
business requirements.
Security Engineer - with all the
nefarious operators out there you need someone to keep the
corporation safe and in compliance. This person needs to work
closely with everyone to ensure the integrity of corporate
data.
How to Implement DevOps
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.
Don’t boil the ocean
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.
Don’t be afraid to fail
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.
Improvise, Adapt, Overcome
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.
All for one, one for all
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.
We all rise and fall with the tide
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.
Ask for help
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.
SUGGESTED READING
If you liked this post you may also like: