Data is the Key

Editor’s Note: This blog post was updated on August 20, 2019. The CloudBees solution for Software Delivery Management preview program is now available. To join the program, click here .

For the last couple of years, CloudBees has been in the process of inventing a new category of enterprise software, which we formally announced as Software Delivery Management (SDM) in April this year. I took a first stab at introducing the concept in a blog post right before our announcement event in San Francisco on April 18. Since then, key customers and industry influencers have been in constant dialogue with us about how critical the problems SDM will solve are to their companies and providing a wealth of detail of use cases to help guide our ongoing development.

Now SDM is here! Our DevOps World | Jenkins World conference is this week. Ben Williams, our VP Product Management; Shawn Ahmed, our VP Product Marketing; and Marina Harrell, a Senior Manager in Engineering here will be demonstrating what they are building and launching as well as announcing a public preview program on stage in the Wednesday am keynote April 14, 8:30 am PT . In the last couple weeks, in the runup to that event, Shawn provided a bit more detail on why SDM is a game changer and the benefits of software delivery management .

What I’m going to do in this post is discuss what I think is the key dimension of SDM that differentiates it from every attempt that has gone before to solve problems in software development - data done right. Nailing data problems has been the key to every other impactful category of enterprise software in other functional areas, from CRM and ERP to HRIS and ITSM.

To establish these categories, the pioneers and leaders in each of them have had to:

• 1. figure out the canonical entities and relationships for the base data models relevant to their functional areas;

• 1. map the processes they manage and the data produced by adjacent systems to them; and

• 1. make those models flexible, customizable and extensible enough to map to each of their customers’ unique business processes and ecosystems’ evolving toolchains and ideas.

That’s one of the most important things we are doing for the first time across the domain of software development - sorting out what all of the fairly common but loose concepts like features, products, teams, sprints, releases, deployments, lines of business, artifacts, environments, observations, behaviors, bugs, tasks, customer requests for enhancement, market datapoints and hundreds more really are and how they relate to one another and to the processes critical to all the functions involved in software delivery. Not just engineering but product management, product marketing, documentation, design, support, operations, marketing, sales, customer success and management all the way up and down the line from the c-suite to first line engineering managers. These are people that all intend the best for their companies and want to work together, but their functions have often had subtly different views of the same realities of these concepts, frustrating attempts to collaborate seamlessly.

Sure, you can argue that issue tracker tool X has had a model for agile development that related sprints to stories to epics and the like for years. And ARO tool Y has diligently mapped environments to releases to applications for ages too. But these were local attempts to solve the problems of functional silos, not to get the entire organization to work together as an interconnected single organism. In software delivery, until SDM, we haven’t established organization-wide understandings of key concepts and how they flow across silos. As I noted in my introductory blog post in April, the era of #continuouseverything forces us to finally do this - as there isn’t time for weeks long handoffs of big batch releases between parts of the organization anymore.

So one of the fun things for me in the last year and a half or so has been to watch the team go through the process of discovery on what those entities and relationships are. I’m a firm believer that creativity is just the process of digging to discover more and more fundamental truths. Science and technology advancements frequently take the form of different individuals having near simultaneous identical discoveries while swimming in the same pool of ideas and prior art.

Seeing different PMs and different engineers and others around CloudBees’ product organization discover some of the same things once the basic idea of the SDM took hold has been inspirational. Within CloudBees we have hundreds of engineers, PMs, product marketers, designers, technical writers, managers and execs with experiences that have brought them to a passion for DevOps and continuous practices. When their experience engaged with the idea that you could build an enterprise system with common data behind it, the lightbulbs started flashing all over the place as people realized the many pains of their prior (and, let’s be frank, current) software lives such a system could solve. This SDM data model discovery process will be ongoing at CloudBees the next several years, but the last year plus here has been one of those intense periods that has produced a nucleus that I think will define this industry and category going forward.

I don’t want to steal Marina, Ben and Shawn’s thunder Wednesday but I’ll highlight just one early such simultaneous discovery: features to SDM are what opportunities are to CRM. Think about it.

For those less familiar, CRM is “Customer Relationship Management” and is used by the business to track their ongoing relationship with their customers. This is really a euphemism for tracking new sales and renewal opportunities and related interactions like support tickets, marketing touches, etc. and tie them to their customer contacts and account hierarchies. The business outcomes of revenue, bookings, recurring revenue, etc. are based on the flow of opportunities through a sales pipeline. Looking at aggregations of the opportunities and where they are in the sales process lets different people in the business forecast where they’ll be and know what they’ve done. I could go on, but you get the gist. Opportunities are really the primary movers through the system that make the business go. A business that never closes an opportunity isn’t going to stay in business very long.

Now to my claim about features being the same thing for a software organization. Features arise through the processes an organization has to listen to customers and the market to discover problems, and then design solutions to them. Features (and changes to them, big or small) are the increments of value that can move through the system and be delivered back to customers and the market. Seeing where features are in delivery is seeing how value is flowing. Marketing and documentation need to match what features are imminent or delivered - sometimes at the granularity of specific users. Compliance likely has concerns at a feature level. A software organization delivering no features is delivering no value to customers, and won’t stay in business very long. Really, the era of #continuouseverything is about getting software delivery to the granularity of features and managing a constant stream of them!

Yet do organizations have a system that is a single source of truth of software feature definition and status analogous to how a CRM is that for sales opportunities? Not till now.

Personally, I can’t wait to see what the team has built in action this Wednesday.

- cfrln