This is a good time to reflect and recalibrate for the coming year as 2019 comes to an end. We’ve done a lot in the DevOps space over the last year, and looking back at my time before ShuttleOps, we’ve had a lot of learnings while delivering DevOps services to customers of various sizes all the way from SMBs to Fortune 10 organizations.
The tips outlined here are those that have held up over the years throughout our journey. By no means is this an exhaustive list since I’m only highlighting 4 tips. Some of them may apply to you based on where you are in your DevOps journey.
Focus on Business Outcomes
At times, the technologist in us can get enamored with all the tools that are available in the DevOps marketplace. It seems like there’s a new tool every month that plays a niche role in the end-to-end application delivery process. As important as the tools are, they are just a means to an end, and we shouldn’t lose sight of the business outcomes. The business outcomes should be our guiding light and we should revisit these constantly throughout our journey to ensure alignment.
Having some grounding in the areas of tooling available to help you achieve these business outcomes is key, but you don’t want to go too deep into tooling too early in the process. For example, this may include getting an understanding of:
- Source Control
- Continuous Integration
- Artifact Management
- Security & Compliance
- Collaboration Tools
- Public Clouds
- Deployment / Provisioning
- Configuration Management
- Monitoring / Alerting
Understanding these different areas should give you the baseline you need to have more meaningful discussions around achieving business outcomes.
The next step in actually determining what business outcomes you want to achieve is ensuring that all stakeholders are part of the conversation. Remember, DevOps involves combining technology, people, process and culture to achieve increased velocity in delivering software and all the voices are important if you want to make a significant organizational impact. The stakeholders that may be involved in this process could include the following teams depending on the makeup for your organization:
- Release Management / Change Control
- Business Stakeholders
- Executive Leadership
I can’t emphasize how important it is to have some level of executive sponsorship throughout your DevOps journey. We’ve seen it happen too many times where grassroots movements hit a wall without proper buy-in. Typically getting buy-in at the VP or SVP level has proved to be beneficial in our experience.
One thing that has worked well in terms of process for determining business outcomes has been an Opportunity Canvas. The Opportunity Canvas originates from Product Management but can be altered and used here for determining business outcomes. We’ve used Opportunity Canvas’ in the past that consisted of the following categories:
- The Problem(s)
- Users and Customers
- The Solution(s)
- Solution Today
- User Value if Solved
- User Metrics
- Business Problem(s) [if Not Solved]
- Business Metrics
- Budget (Time)
Out of this exercise, you should be able to walk away with numerous business outcomes that the organization wants to achieve that may impact multiple departments.
This brings us to our next tip, Prioritization.
Prioritizing the list of business outcomes that you’ve generated becomes key. If you only have a couple of large business outcomes, it’s important to partition these into smaller outcomes. Doing a big-bang DevOps approach is risky and most organizations will fail due to the complexity involved and the implications this has on people, process and culture.
When it comes to prioritizing, it’s helpful to chart the business outcomes against the perceived return on investment (“ROI”) and a project input. We’ll focus on three project inputs here, but there’s definitely more you can consider.
If achieving your business outcome requires you to change processes, you may want to ask yourself the following questions to determine which quadrant the outcomes fall into:
- What level of tolerance is there within your organization for changing a particular process?
- Will you be able to get executive sponsorship and oversight for this initiative?
- What does this mean for existing processes and what does the transition plan look like, if any?
People will be key to achieving your business outcome and asking yourself the following questions will help you start to asses how realistic trying to achieve this outcome may be and what timelines are required:
- Do you have the people today with the right skills to achieve the business outcome?
- Do the people you have today have the time to commit to this initiative?
- Does achieving the business outcome threaten jobs or cause roles to change and what type of resistance to change can you overcome?
- Can you retain staff long enough to complete the initiative? This one, in particular, can be very challenging at the moment since employees working on DevOps initiatives are highly sought after.
- Do you need to bring in external organizations or contractors to augment your team?
If you build it, they won’t come.
It’s critical that you consider how people will be onboarded to your solutions to make the business outcome a reality.
Employees have a full-time job as is, and it’s going to be challenging to bring them into a new solution. We’ve seen solutions that work really well within a team or two, but when you try to scale it across an organization various challenges can arise. Thinking through how you can streamline the onboarding process to a new solution can prove beneficial down the road (and this is part of the Opportunity Canvas after all).
Now that you’ve established the business outcomes you want to achieve and prioritized them against project inputs and ROI, you’re in a good position to evaluate tooling.
Tooling Based On Business Outcomes
It’s important to evaluate tooling for the business outcomes you want to achieve today as well as those you want to achieve at a future date. We typically call this process the selection of your DevOps Reference Architecture.
The basic premise here is to select what you want your end-to-end DevOps tooling to be based on the tooling categories outlined earlier. This will provide you with a clear picture of how all the tools fit together.
There’s nothing wrong with choosing tooling that works today but may require replacing in the future. However, it’s important to evaluate what this means in terms of impact. Given the rapidly changing DevOps ecosystem, this will most likely happen somewhere throughout your journey for one reason or another.
When you’re thinking about end-to-end application delivery, try and minimize the ways to production.
Focus on Process with Tooling
Today we have heterogeneous applications (in-house, COTS, legacy, cloud-native), that are being deployed to heterogeneous infrastructure (VMs, bare metal, containers, serverless) across different environments (VMware, AWS, Azure, GCP, etc.). If we start to have different tools and processes for dealing with each of these, we’ll quickly get to the state where the ecosystem becomes very complex and unmanageable.
If we try to focus on establishing a handful of processes that can be standardized across different applications, infrastructure and environments then life starts to get a bit easier. Once you layer in standard tooling to go along with these standard processes, you start to get closer to becoming a truly DevOps enabled organization.
Read more about tooling in the Selecting The Right DevOps Tools blog.