How Software Delivery Management Clears Up the Confusion of Embracing and Implementing DevOps

Since the term was coined back in 2009, it wouldn’t be a stretch to describe DevOps as an impactful if not tectonic shift in software development and delivery in the past two decades. The move to implement DevOps has encouraged, among other things, better collaboration between siloed Dev and Ops teams, more reliance on automation, more focus on culture and better use of feedback loops to refine delivery processes.

In theory, DevOps has been a game-changer. But, in practice, its usefulness is more difficult to define. As DevOps enters its teenage years, the idea of a fully integrated software delivery function aligned toward a common goal of generating business value is more illusion than reality.

Are DevOps teams themselves as connected as they should be? The reality is that developers and operations personnel tend to have their own versions of “dev DevOps” and “ops DevOps,” working against each other inside supposedly integrated teams. Though they may have set up deployment pipelines, each side tends to use its own tools, access its own information and follow its own cadences, leading to occasional missed handoffs and delays in delivery schedules.

Looking across the enterprise, DevOps cultures fray further. A perfect DevOps practice envisions teams in different departments, business units and geographies all in sync, delivering value via software on a reliable cadence. In reality, enterprise DevOps is difficult to pull off because most organizations haven’t implemented shared languages, comment processes and best practices across all of their teams with management buy-in.

Then there’s the issue of connecting DevOps functions with the rest of the organization. Some definitions of DevOps extend the concept of collaboration to other stakeholders beyond conventional engineering functions, such as quality assurance, testing and security. But how extensively does a DevOps culture tie together the goals, needs, resources and processes of others in the organization that rely on software delivery, such as product marketing, sales and executive management?

Delivering Better Software

Gartner describes DevOps as being focused on “rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.” In other words, delivering faster and in a more organized manner. But has DevOps helped software-first organizations deliver better software? Has it helped them institute the right processes to deliver the right software at the right pace to drive the most value possible to the organization’s bottom line? Paraphrasing the “If a tree falls in the forest …” proverb: If you deliver software and no one is there to consume it, have you truly delivered value?

Even if you’re doing DevOps relatively well, there’s a level of integration that’s missing from today’s software cultures. It’s the mission to tie together all functions of software delivery—not just those relating to what goes on in the labs. It’s the commitment to do more than just deliver better metrics. It’s the mentality to define everything relating to software delivery as a discipline all its own, like finance or sales—not just serving other disciplines.

A new technology category is emerging that aims to build on what DevOps has accomplished and extend those gains across the software delivery function. It’s called software delivery management (SDM). An SDM strategy is based on four foundational pillars that elevate software delivery to a core business priority, reflecting the level of importance software has achieved in today’s business environment:

• Common Data – All information within and around software delivery activity is captured and stored with a consistent domain model to enable and facilitate connections to processes, shared insights and collaboration.
• Connected Processes – Processes orchestrate software delivery and connect functions together to efficiently bring ideas to market with maximum value and adoption.
• All Functions Collaborating – All functions and teams within and around the software delivery organization work together to amplify value creation efforts.
• Universal Insights – Visibility and insights enable understanding and continuous learning from data across, up and down and throughout all functions in the organization.

Driving Improvements Across Organizations

Adopting an SDM strategy on top of an existing DevOps culture can help an organization in a number of ways.

Having disconnected tools, disconnected data and a lack of common language make it difficult for one side of the organization to know what the other wants. Even in mature DevOps implementations, software delivery ends up being a patchwork of different processes for different teams.

It’s also difficult to determine if our teams are delivering the right end product if there’s no shared visibility and insight. SDM helps by establishing common data and common processes, giving visibility and insights across teams of different maturities, different tools and different technologies so you get all functions to collaborate. That way you can be sure you’re not just deploying more—you’re actually delivering continuous value.

You can’t manage what you can’t measure. What SDM offers is a model to understand how you’re performing with DevOps by and large, what teams are performing well and what teams aren’t, and how you can leverage those insights to improve.

Tips for Implementing SDM

Here are five ways SDM build on the successes of DevOps:  

• Integrate your tools: Disconnected toolchains make it difficult, if not impossible, to orchestrate a delivery process end to end. Try to get DevOps tools onto a common platform where they can share information across teams and organizational functions.
• Capture data: Ensure you’re establishing an audit trail and capturing data on events and actions that are taken across that end-to-end process. Then collect those data points in a common data store as normalized objects. Making common data accessible across functions allows you to, for example, reconcile a particular support request to the right user story and commit to the right change that is being deployed out to a server.
• Don’t fail to communicate: Once you’ve created your data store, establish a strong relationship and regular communication with the business side of the organization. Continuous delivery isn’t just for developers anymore; software delivery functions have to address business needs. That can’t be done without high levels of communication.
• Establish KPIs: You should have a taxonomy or hierarchy of business objectives you’re trying to achieve with your DevOps implementation. Establish the hypotheses that can achieve those objectives and then integrate the features/user stories or implementation-level entities that will drive you toward them.
• Leverage observability practices: This needs to be done so you can measure those performances against KPIs. If you believe that updating your user interface will increase the amount of time users spend in your SaaS application, you need to establish what that target KPI is. Then, as those changes are delivered, measure, analyze and adjust to continue to drive those toward the hypothesis.

Conclusion

DevOps has taken software delivery a long way and implementing an SDM strategy can take it the rest of the way. It won’t change DevOps, but it could reinvigorate the practice. Deploying both strategies in concert, software delivery management and DevOps can focus less on automation and tools and more on the outcomes and on the people and steps involved in driving those outcomes.