Organizations striving to be “software-first” businesses are focusing their investments narrowly – on creating the best development and deployment practices they can. They’re implementing DevOps cultures, standing up CI/CD pipelines, integrating new sets of tools, training staff, and organizing new procedures – all to make software delivery more efficient.
To an extent, the moves are paying off. Tech leaders such as Netflix and Facebook are releasing multiple times per day, and cloud-native development initiatives are helping newcomers become more nimble. Organizations of all sizes and scope are deploying code faster, failing less, and recovering more quickly from downtime than ever before.
But is the software-first movement succeeding in its larger mission – to deliver quality apps that impress end users and generate optimal value for organizations themselves? That’s a question that stretches beyond metrics. It zeroes in on how organizations define the actual software delivery function and how high a priority they put on that function. Does software delivery begin and end in the DevOps process?
Or does it extend in both directions – further left, to how the product is envisioned, planned and prioritized, and right, to the way it’s marketed and sold – and back through a rapid feedback loop, to be continuously improved? Are organizations committing to sustaining end-to-end software delivery systems that remove any blockers?
They try. But they’re hamstrung by the toolsets and processes that govern today’s software sector. As organizations grow their DevOps maturity and then attempt to scale into the software-first mode, most will hit a ceiling. Unless they’re able to a) measure, manage and continuously improve their core CI/CD capability, b) fully connect software development efforts to the broader product and software organization, and then c) ultimately connect those efforts to the rest of the business responsible for bringing software successfully to market, they’ll fall short and no longer be competitive.
The root cause of this disconnect is that information is locked into stand-alone software tools and isolated within teams and functional groups. The teams have their mandates, and work within silos, without common processes, a common data model, a common language, or universal, shared insights. They collaborate amongst themselves but not as well with other teams and other functions across the organization. If they can’t work together, talk to each other, or share information, they’re flying blind. They don’t have the visibility they need to continuously increase and augment the value generated by the software.
This problem, of course, isn’t new. Organizations have been hunting for a software delivery “holy grail” for years. Plenty of SDLC/ALM fads based on shiny new “fully integrated” and opinionated tools end up costing money and wasting effort without generating much true value. All-in-one solutions usually involve ripping out the trusted tools, forcing engineering and development teams to learn a whole new way of work. They might be able to streamline some procedures within a small segment of the delivery process — but prevent using the right tool that best gets the job done, ultimately slowing things down.
What’s needed is a management layer that connects – and guides – all the functions related to software delivery. Here’s a look at a new concept called Software Delivery Management (SDM) that proposes a way to do this. It’s not a set of tools. It’s not based on proprietary technology. It’s not another process. It’s a foundation that brings organizations tools, teams, and processes together.
Software Delivery Management
Software Delivery Management (SDM) is a way of connecting teams and tools across an organization, enabling visibility, collaboration, and governance through a unified process and common data, to deliver better software faster, resulting in increased value to the customer and measurable business outcomes.
Just like DevOps breaks down the walls between the development and operations teams, SDM breaks down the walls between development, product management, UIX teams, documentation teams, support, and product marketers. It allows them to communicate better, understand each other’s needs, and ultimately make software that isn’t just bug-free, but also effectively addresses the business needs and creates value for the customer.
How do organizations build an SDM function? They can start by creating systems that enable the four pillars of an SDM model – common data, connected processes, universal insights, and all functions collaborating.
Establish a system of record: Build or buy a system of record with a common data model that brings in your different data elements. This would include a persistent and extensible data store, modeling software delivery lifecycle entities, and recording all software delivery activity to support subsequent queries, visibility, analytics, insights, and workflow orchestration. You can organize that data in a common model and language that everyone can access.
Have a flexible common data model to get universal insights: Either through APIs or some other way, you need to be able to connect different tools. The idea is to go beyond just your DevOps toolchain and bring in information from data sources such as CRM, Financials, and Support. Then you find a way to leverage that data – either through queries which then could bring invisibility or through insights that could then be turned into a policy.
Find a way to bring those things together. It’s the only way you can democratize that information so the development teams understand who’s doing what and when and with different components. Then your different stakeholders – product marketing, sales, customer success management, support – also have a view into this data. They may get it through a weekly report that someone is manually putting together and pushing out. But it still enables that visibility so people can plan and support the big initiatives that software delivery is putting together for a particular set of users or customers as improvements over what they’re using today.
SDM in Action
How does SDM work in practice? Here’s a hypothetical example of how a typical software delivery organization gets blocked by existing practices and how a software delivery management layer might help remove those blockers.
Let’s say the Product Leader at a music delivery business wants to upgrade a music player by adding three principal features: a better UI, an improved editing function, and a different way to package a playlist. Without an SDM strategy, this would likely be written in a standalone document as a set of complex requirements and then sent to the development team — and the dev team has no context on why the features are important. The Dev team would translate the requirements into a tracking system as user stories or features but without a complete understanding of the customer and business drivers. The fact that the CEO’s idea comes from data pulled from customer support tickets and RFEs is completely obscured.
Unfortunately, the display and editing capabilities weren’t expressed clearly in the original requirements document, and even more, was lost in the translation into stories. This gap goes unnoticed. The playlist capabilities were implemented incorrectly. The project is released to customers, but adoption is lackluster. Instead of the hoped-for reduction in support requests, support teams get a flood of requests from customers who don’t understand the user interface or are having problems getting it to work.
Meanwhile, a competitor who had the same market challenge releases a new set of features. The competitor’s new capabilities aren’t the same, but they meet the same customer needs. At first, the competitor also sees weak adoption but can rapidly integrate the feedback from the sales and support teams into new releases. After fixing the confusing user interface and providing appropriate documentation for the product marketing team, adoption soars. The competitor wins industry innovation awards, and our CEO’s music delivery company loses customers, revenue, and possibly even key developers who leave to work for the competitor.
If developers had known at the beginning why the new features were being developed, could they have suggested tweaks that deliver the same business goals? Better yet, had they understood the customers’ need, they may have been able to suggest an alternate approach that was even better. If support and development had access to common information and connected processes, could they have collaborated better? This is why it is important to bring development teams into the mainstream of business operations and planning.
SDM Strategy Adopted
If the music delivery company followed a Software Delivery Management strategy, the entire software development organization, and related areas would engage when the data from customer support was being discussed, before the display, editing, and playlist capabilities were settled on. Instead of a requirements document being thrown over the wall, development and product stakeholders would be able to engage in a conversation and have the context related to the business needs the features are being designed for.
Each story assigned to a developer would be linked back to a concrete business goal with the associated customer, market research, and expected outcomes. The developer would have the context and insights necessary to build and deliver the right functionality that meets customer requirements. Support could weigh in with input they have received from customers about the new functionality. Finally, the field organization could share what they have been hearing and seeing in customer and prospect accounts they have visited.
When the conversation about business goals and customer impact includes development, product management, UIX teams, doc teams, support teams, product marketers, and the field organization, everyone gets a more complete picture of how a feature is or is not meeting customer desires. Together, they can determine the best way to meet the business goals creatively and efficiently. If a feature isn’t working for end-users, that information is surfaced quickly and immediately integrated into future iterations.
If development on a particular feature has a bottleneck or blockage – a security vulnerability, a code quality issue, or a pull request waiting for review in the repository connected to this feature – information may be in the tools today, but it’s not surfaced centrally in the context of a feature. With SDM, multiple teams can see this immediately and act proactively immediately.
This will help the scrum team assess any potential blockers to surface this immediately, while you’re working, bringing this information transparently to the teams. If such blockers become a frequent issue, a good way to manage this is through the use of policies. Implementing policies along the software development process can help teams work more efficiently while also ensuring specific actions are taken promptly, or certain thresholds are met before moving to the next stage. The result is delivering quality, secure software to customers.
SDM also gives management the ability to assess the organization’s performance in different ways. In specific teams, tooling is in place to assess those teams’ efficiencies. But how did the business performance across multiple teams, across multiple workstreams, using different tools? It becomes more and more difficult to assess this holistically in one single place and connect it properly. And then, from that analysis, how did the business perform to create this output?
This goes into the CD and the CD process. Then from there, it lands in front of the customer. Who has access to it? Is it feature flagged? Is it accessible to everyone? What is the performance of this feature after we’ve implemented our improvement, our enhancement, or our new feature? How does this relate to what we set out to do – to improve the player’s user experience and to increase the engagement for our users? Can we measure this?
SDM gives more stakeholders more visibility into what others are doing. It’s really about sharing information to collaborate better – the intersection points between teams and roles and people. Like between Dev and Ops, it’s a collaboration between product owner, business and development teams. SDM is about connecting all the roles and functions for the full lifecycle – from ideation, plan, build, test and release, to realizing value to the business, along with a fast feedback loop to improve. Sales, field, and product marketing can use the information more effectively and plan better around it. Organizations can release products more quickly because of CD, but using SDM they can build supporting processes around it so they’re more effective.
Software Delivery Management not only allows for better decisions and expectations at the beginning of the software lifecycle – but it also extends the feedback loop throughout the software delivery process, through actual customer success, and back. This provides an endless loop of input about what’s working — and maybe most importantly, what’s not — to drive continuous improvement in software quality and functionality. This reframes the role of software delivery in the enterprise, recognizing it as a key business driver.
A Post-COVID Future
Creating a management layer on top of existing processes and tools is important in any environment. It makes sure products are getting out on time, they’re being developed with high quality, they’re secure and they’re meeting the needs of your users. Today, with the disruptions caused by COVID-19, it’s even more important. When you look across your software delivery process, you need to know where things are, where people are, how your work is progressing, and if blockers need to be removed. Manual steps that were OK before aren’t now. You have to automate it.
That’s where SDM comes into play. CI/CD is all about building the code, testing it, and getting it out. SDM gives stakeholders, both left and right, visibility into every aspect of the software delivery process. By linking information, teams, and processes, organizations get that extra level of visibility and insight to continue to evolve into software-first businesses in the future.
