Editor’s Note: This article is a first in a series of blogs about Software Delivery Management written by Shawn Ahmed, vice president of product marketing.
We truly live in exciting times … software has transformed every part of our existence. I remember the world just 20-30 years ago it seems so analog compared to now. The pace of innovation around us driven by software is sort of like the expansion principles of the universe, it’s scale and velocity is exponential and it’s become a part of every direction of my life. Clearly, it’s not slowing down any time soon either …
When I see a new incredible software-driven innovation, I remind myself that the teams behind it somehow managed to deliver amazing innovation, despite how difficult it actually is to do so. The bigger the development organization gets, the more teams you have working on different parts of the software. Teams may be working on completely different products and features across those products in different states of maturity and in different stages of value delivery. They’re grappling with complex architectures that span on-premises and cloud infrastructures or dealing with the daredevil nature of going completely cloud-native. Some teams are developing, some will be testing, some are operating the software. Let’s not forget to mention the people responsible for supporting the software and successfully implementing it in the market and all the people that work on researching and ensuring we are building things that actually matter. The product managers, doc writers, the designers and the product marketers to the people upstairs with C’s in their title worrying about the software keeping them competitive.
Bring on Software Delivery Management
In a prior job, I remember coming into the office before anyone else arrived because, as an engineering manager, I struggled with collecting and getting a complete end-to-end view of my product and feature development activity across the SDLC. I’d start manually collecting data from development toolchains that seemed to exponentially grow and get more complex. Think more than 40-50 tools across the various teams, and of course, none of them shared anything…siloed and disconnected.
If you self-identify here, I am sure you will agree what a pain in the ass it is. Honestly, even with all that effort, most of the time I couldn’t identify the bottlenecks and inefficiencies that impacted (as my good friend Ben Williams would say) Delivery of Value. My teams were busy and all I wanted to do was to help them be more efficient.
Or maybe you identify with the developer that comes in the morning just trying to wrap their head around what they should focus on first? Digging around for clues and information in Jira, GitHub, Jenkins, etc. to get started. Or just trying to understand where and why their features are stuck across the software delivery value streams. Or when they are about to start building something new, just quickly being able to understand any previous work that has been done, any potential UI mocks, documentation outlines or POC architecture docs. Or how about you just want to know where your feature fits into the universe of value and who is using it and how. You just want to get feedback early and often on the features you’re developing.
Yeah … I know, I am just touching the tip of the iceberg of crazy. That’s why I am so pumped about the new category of software being dubbed Software Delivery Management (SDM). The sole purpose of this category of software is to unlock the true potential of software value delivery. The concepts and pillars of SDM were first introduced by Christina Noren in San Francisco months ago. The brainchild of industry luminaries like Sacha Labourey, Francois Dechery, Ben Williams and their amazing development organization tried to put some pillars into place to guide their efforts. Those pillars are:
- COMMON DATA – All information within and around software delivery activity would need to be captured and stored with a consistent domain model to enable and facilitate connected processes, shared insights and collaboration.
- UNIVERSAL INSIGHTS – Visibility and insights would need to enable a common understanding and continuous learning from data across, up-and-down and throughout all functions in the organization.
- COMMON CONNECTED PROCESSES – Processes would need to orchestrate the entirety of the software delivery value stream and connect functions together to efficiently bring ideas to market with maximum value and adoption.
- ALL FUNCTIONS COLLABORATING – And finally, all functions and teams within and around the software delivery organization would consequently work together to amplify value creation efforts.
Okay, so what’s in a category you may ask? Do you actually have any software in the category? Anything built that’s even remotely close to the guiding pillars? Any running code that can actually solve those pains and reach the Promised Land that presumably comes when you use software that supports SDM?
Short answer: YES!! We have been busy at CloudBees 🙂 And if you want to learn how CloudBees makes Software Delivery Management possible through its brand new software product called CloudBees SDM, come to DevOps World | Jenkins World in San Francisco August 12-15 and hear more about the unveiling of the product. We also have an early access Preview Program you can participate in, on the journey to software delivery value!
