Anders Wallgren

Now, the more astute among you may realize that the title of the talk and the title of the slide here are different. It's actually the title on the slide here that's not quite accurate. The theme is very much in line with what the abstract talks about. I just wanted to point that out so there's no confusion.

This is a little bit of an overused phrase these days: software is eating the world. But as with so many overused phrases, it's there because it's kind of true. Everything I buy these days seems to have software in it: washing machines, refrigerators. Actually, not that I bought either one of those recently, but they do. A modern car these days is a traveling data center, right? Ninety CPUs in a new Mercedes. More lines of code in a car than, I'm told, Office, Windows, Linux combined. A little bit scary. So software has eaten the world. It's not a question of is; it's already happened, and we're drowning in data as a result of it, which is part of the theme of what I'm talking about today.

In terms of architectures for applications, that's changed as well. Microservices: new, hot, everybody's doing it. And they do make a difference. We did a little bit of a survey and realized there's revenue-growth implications of companies, software organizations, that are able to deliver their applications in the form of microservices, loosely coupled architectures. It's not really the theme of today, but it is kind of leading up to what I'm talking about here.

If you've been to this show before, you've certainly seen these types of numbers before from the State of DevOps report, in terms of the just vastly better speed and quality that CI/CD practices and DevOps in particular bring to the software delivery process. What I always like to point out is we're not talking about percentages here anymore. We're talking about multiple orders of magnitude. Pretty soon we're going to need exponents in these slides in a few years, I would imagine.

DevOps practitioners, organizations that are elite performers in DevOps, we're delivering faster, with fewer problems, easier to roll back and fix when there are issues, shorter lead times. All of these things make these software organizations more competitive, better at delivering value to their customers, all of the things that we want out of a software organization.

So we've got new architectures. We're all of course doing CI/CD and DevOps, but still, getting software out the door is difficult. It's a tricky problem for most of us. I would say all of us. So there are still problems here. Even if I'm in a highly functioning DevOps organization and I'm a developer, I might still be asking myself questions like: "Why am I building this feature? Who's it for? Why do I have to waste my time troubleshooting all these problems here? Am I really bringing any value to end users? Why is the release date the most important feature in our product?" That's something I've asked myself a million times over the years. The answer is customers.

Even for the high-performing DevOps organizations and high-performing software organizations, there are still a lot of questions and still a lot of problems. What you really want to do, ultimately, and this really gets to the theme of the presentation, is that DevOps is not just about Dev and Ops. Software delivery includes a lot of other organizations and a lot of other stakeholders. We're talking about the executive suite, product management, sales, marketing, support, all of these things.

Ultimately, if you're going to deliver a compelling product with compelling features that brings value to your customers and they give you back whatever it is that you want from them -- money, love, respect, what have you -- a lot of different stakeholders need to be involved in this. At scale, it isn't really just a bunch of coders sitting in a corner typing code and deploying it to Kubernetes every five minutes. That helps, but that's not the complete picture.

To give you a little bit of an example of this, a quote from one of our large financial services customers. I'm just going to read this because I think it's so very relevant: "While we're doing phenomenally well in our DevOps practice, if we're unable to have better visibility, measure the actual business impact, and connect our software development and delivery practice to the rest of the organization, we will no longer be competitive in the market."

Part of what this talks about is, I was going to say a new kind of silo, but it's not really a new kind of silo. It's been there the whole time, but it's data silos from all of the various tools that we use. All of the various stakeholders, all of the cross-functional teams that we use, have a ton of different tools that get used from even pre-commit: design tools, product management tools, all of those kinds of things, all the way through to when a product is actually live and in production, whatever that means. Whether that's a web application or whether it's some firmware that's burned into a chip and goes on a satellite or what have you.

Really, the key thing that we're all trying to do is tie what we're doing to the business objectives, because we work in organizations that are typically for-profit businesses. I would say even if you're a not-for-profit, you still can't lose a lot of money, because you'll run out of it eventually. But this is a big problem, even for high-performing organizations. The process of delivering and realizing the value of software involves a lot of people working with a lot of tools and data, not just DevOps.

If you think back five, 10, 15, 20 years, back to the bad old days when everybody was siloed: Dev writes some code, throws it over the fence to the QA organization, who tests it for a while, throws it back because it's not working, back and forth. Then we throw it over the fence to the ops people and they're like, "Okay, how do I deploy this? How do I run this? What is this?" I'm not going to claim that the industry has solved that problem for everyone because it's a very complex problem, but we have made great strides. But it's not just a DevOps problem. It really does go across the organization.

If you think about a product organization, you've got a couple products here, A and B. We're trying to deliver features. We're trying to deliver value to our customers that they find delightful and bring value to their lives, or at least their work lives, sometimes their real lives as well. We're trying to do this at the same time that we're trying to generate revenue. So we have to come up with something compelling, we have to have some ideas, then we have to realize those ideas in software, and then we have to get that software out the door, operate it, support it, all of those kinds of things.

We have a multitude of tools. If you broaden the purview outside of just the DevOps kind of silo, you're dealing with things like Salesforce. Your salespeople are doing forecasting based on the products that are coming in the pipe, and they're trying to sell these things. There's a tool that probably most software developers don't spend a lot of time in. But still, it's part of the process, part of what we do.

Jira, of course, as an example, is something that a lot of developers use, support organizations, product management organizations, those sorts of things. This is not a product pitch for all of these products, because this could just as easily be Rally, VersionOne, Bugzilla, for that matter, all of those things. Then you might be doing continuous integration with Jenkins or CloudBees Core. You might be doing continuous delivery, application release orchestration, continuous delivery release automation, depending on which analyst you follow, with something like CloudBees Flow. So there's tons of tools out here. Then you deploy that into production, and maybe you're running in Google Cloud. Maybe your support organization uses Zendesk. So there's a whole ton of different data silos ultimately that we're dealing with here.

Now, here's the problem: at some point, things get stuck. We don't deliver on time, or we don't deliver quite the right thing, or it doesn't work, or all of these kinds of things that you run into. Certain features are moving forward the way you expect them to, and other processes, other efforts, get stalled.

What I'm showing down here is just that there's lots of data being thrown off by all these systems. Again, don't take these product names literally. Insert your favorite product here, because this really isn't about these specific ones. But we all have, and actually some of us have multiple of these. I'm working with a customer who is still working with four different SCM systems, some on-premise, some in the cloud. I'll tell you what: the on-premise ones, they're not going anywhere for the next decade. Too many engineers on there. They're not going to move it, all of those kinds of things.

There's a lot of complexity. There's a lot of tools. In the larger organizations, I go out talking to them and I say, "Well, what do you use for this? What tool do you use for SCM?" "Well, we got a few." "What tool do you use for bug tracking?" "We got a few." Oftentimes you're dealing with multiples of these, not just ones.

That's even more so if you're in a large organization, say, that's built through acquisition, mergers, those sorts of things. Your first step is not generally when you pull in a new product team to say, "Oh, by the way, now go rewrite all this stuff that you wrote in Python and Go, and then stop using Bugzilla and start using VersionOne and XYZ." You don't want to mess with what's working. Presumably it was working or you wouldn't have acquired them in the first place. But it's messy.

We don't always know, we don't always have visibility into what the problem is. Where is the blockage? We know the sink is backed up, but we don't know where in the pipes the problem lies. That's a big challenge. In a world of data silos, dispersed tooling, we require tremendous effort every day to keep on top of this. What's honestly the number one tool I see used to manage this stuff? Spreadsheets.

Get all the stuff out of this Jira instance, get all the stuff out of that Jira instance, get a bunch of stuff out of GitHub, get a bunch of stuff out of Perforce, get a bunch of stuff out of VersionOne, try to correlate it, try to figure out what's going on. A lot of that stuff's still going on. That's not core competency. That's not what any of us want to do on a day-to-day basis. What we want to do on a day-to-day basis is deliver valuable product to our customers so that they, again, give us money, respect, love, whatever it is that we're looking for.

In order to solve this problem, organizations have to become more seamless and more connected between all the stakeholders. That requires a number of things. That requires that we have a set of common data that we can operate on. I think I've just gone through the nightmare scenario of why there isn't common data, because we all have 50 tools or 100 tools that we use on the path to delivering software and managing the processes of bringing that software out.

What we want on top of this is just some universal insights. We want to be able to reason across these different sources of data because we have questions, and the answers to those questions are in the data -- often, frequently, not always maybe. But the data doesn't live in one place, hence the spreadsheet approach. Hence pivot tables.

The processes are not always connected either. This is something that we've worked on over the years and, I would argue, have gotten better at over the years in terms of making sure that if we sit down and do a value stream mapping -- and when I say we, I mean the industry, not me-we -- we do value stream mappings, we try to discover where the hidden work is, we try to figure out what are the things where we're spending time that we didn't expect to spend time on, all of those sorts of things. But it's still kind of largely a DevOps-centric thing. It doesn't help product management. It doesn't help sales. It doesn't help support, all of those things.

What we really want is all functions collaborating together, seeing the same thing, making the same decisions based on the same data. What we're working towards at CloudBees with software delivery management, and our solution for software delivery management, is bringing all this stuff together, giving you a common set of data. Now, this doesn't mean throw out all your tooling. In fact, it's quite the opposite. It means whatever tooling you're using, we'll ingest that data. I would say we're sort of the Switzerland, except I'm Swedish, so I'm going to say we're the Sweden of this. Great if you use CloudBees Flow or CloudBees Jenkins or Core to do your CI and CD stuff, but if you don't, that's fine too. We'll ingest that data as well.

There are a couple of ways that you could solve that common data problem. You could say, "Oh, just buy my tool that does everything from soup to nuts, and then you'll be happy," but now you're kind of locked into one vendor, and that's not always good. You may not have the freedom, luxury, resources, capacity, time to do that because you have 50 different software teams using maybe core 25 tools that are common, and then there's a whole other ecosystem around them that aren't common across all of these organizations.

Getting access to all of that data and making it available so that we can start to connect these processes and start to answer the questions that we all have is a tricky thing. That's where the CloudBees solution for software delivery management, that's what it's all about. That's what we're working on.

To go back to my kind of ugly picture here for a little bit, we've got some blockers here. Things are stalled. We don't know why. We've got a ton of data, a ton of signal. But what's the signal, and what's the noise, and what's relevant to figuring out what the problem is across all these data silos, if you will? The idea is to start to bring some order to this. Figure out what all the data sources are, get all that data into a common data model. That starts to give you a little bit of the capability to reason across these things and ask and answer very interesting questions that then lead you to, "Ah, that's the problem. The reason we're blocked here is this. We've got a pull request that's been stuck for too long," or, "The reason we're stuck here is we have some build failures," all those sorts of things. It lets you do it in a way that it isn't just something that somebody spends a day to figure out. It's just in your face all the time.

These are the obvious questions that we all want to know, and this is the kind of visibility that we all want across the organization, across all functional areas. Everybody cares about this. The salesperson is interested in when is that feature going to get delivered because I have a ton of customers who want to use it. The product manager wants to know how's the progressive rollout going of this new feature. Are we still just in internal usage or are we starting to do a little more rollout to various other constituencies? All of those kinds of things. What you want to get to is the happy state where you understand what the problems are, what the blockers are, and you can start to remove them.

This is the nirvana that we want to get to. What I want to show you in the remaining slides that I have here are some things from the CloudBees solution for software delivery management, some of the screens. Some of these things, I'm going to be perfectly honest with you, are a little more prototype-y than others, and some are more real than others, and I'll talk about that in the last slide in terms of how you guys can help.

Here's an example of bringing all the data together. We call this our product hub. We're looking here at our song streaming product, so that's the product that we've chosen up here. Right away you can see we've got DORA metrics over here. We've got all kinds of data sources coming in here in terms of support tickets and what are people liking about it, all of those kinds of things. We can see what features are in play. Because remember, what we're doing here is we're delivering features. We're working on concerted efforts, whether you call them epics or tasks or features or missions or value streams or what have you. This is what we're working on, and you want to know where are we stuck? Why are we stuck? Or if we're not stuck, great: what's this team doing that this team isn't doing that they're so much more efficient at doing this?

Bringing all that data into one place means you don't have to go visit a multitude of different tools to answer these questions. Or kind of the flip side, which is almost a worse scenario: pick a tool that does everything for you, and then you don't have best of breed anything. You have kind of lowest common denominator of everything. The product hub is the kind of functionality that you get in the solution for software delivery management when we bring all of these data sources together, pulling from your CI systems, your CD systems, from your repositories, from your issue tracking systems, from your feature flag systems, from your support systems. I probably mentioned some of these multiple times already. But that's when you start to be able to answer these kinds of questions without having to chase down 14 different data sources and munge it in Excel or Google Sheets until there's blood coming out of your eyes, which a lot of people spend a lot of time doing.

If you care about things like value streams, it also allows you to start really looking, again, in one place. You start to get to see what are my value streams, what are we working on. In this particular case, we've kind of subset it a little bit, what we want to see here. If any of you are CloudBees DevOptics customers, you'll probably recognize this screen because it's something that's in the existing DevOptics product and, of course, will be the kinds of things that you'll see in the solution for software delivery management as well.

Again, really unprecedented visibility into your value streams no matter what tools you're using underneath. I want to emphasize that. No matter what data silos you're sitting on top of with all of these awesome tools that you've chosen -- sometimes, again, lots of organizations have many different tools to do the same thing -- but all pulled together. So if I'm stuck somewhere waiting for a pull request, it doesn't matter that this team is using github.com, this team is using GitHub Enterprise, these guys are using Bitbucket, these guys are using Perforce. It allows you to start to reason around, "Hey, are we stuck in SCM somewhere? Are we stuck in branching hell or code review hell or those sorts of things?" It really allows you to look at your whole value stream all the way out into and past production to figure out what's going on and to see where the bottlenecks are.

Ultimately, and I'm going to be perfectly blunt here, this is conceptual. This is not there yet. But this is the kind of stuff that we could start to drive as well, which is an efficiency dashboard. How are we doing? What kind of recommendations can we pull out of this? Hey, most organizations consider a pull request to be stale after a day or two. So maybe create a policy that gives you an alert, a badge, a notification, whichever way you prefer to radiate that kind of data if you have a pull request that's been sitting there for more than 24 hours, or a day or two or three or whatever makes sense for your organization, and starts to give you, across the organization, across the entire enterprise, visibility into the whole software delivery management workstream, which is pretty key.

Again, in order to do this, you need the common data. You need the visibility into the processes that are behind these things so that you can start to ask these kinds of questions and radiate them out.

If I'm an individual contributor, I might be more interested in this, which is the contributions view. If I'm working on a particular epic here, I can see who am I blocking, who's waiting on me, why am I blocked? Is there a pull request that needs to get merged in? Is there a branch that's broken and not building? Is the dev environment down? I can start to answer a lot of the question. Again, instead of having to go visit multiple tools in order to find these answers, that data comes to you instead of you going to the data.

Instead of me going to Jira to ask one part of the question and then going over to the build system or the CI/CD system to figure out another piece of data, and then either correlate them in my head so my head explodes, or throw it into Excel or what have you, we have kind of one place. The data comes to you instead of you going to the data. That's a really powerful aspect and lets you involve all of the different stakeholders because now it's visible.

Now I can go in as a product manager and look at the progress of a particular feature, or for that matter, as a support person. Because as a support person, one of the things I might care about is, well, is that feature even turned on for that user? Because if we're using things like feature flags, using, for example, Rollout, which is a great product that we acquired just recently, or whatever feature flag system you're using, whether it's homegrown or one of the others, again, we're Sweden, so we'll ultimately pull from all of these data sources. Of course, our own will probably have most favored-nation status, to be honest, but we'll talk to anyone. We'll ingest data from just about anything. The idea is now you can start to see what all the relationships are between these things. Instead of you having to go visit all the different data silos and then try to integrate it all in your head, it comes to you. And not just you, but everybody in the organization.

That allows you to do more interesting things in the future. Let's say I'm working on a feature. Where's the definition of that feature? Where are all the artifacts around the design for that feature? I can start to do things like provide visibility into what are the InVision designs that are related to this functionality, what are the epics that are involved in rolling this kind of thing out, and I can get all of this visibility again in one place, no matter what tooling I use. If today you're using product X for issue tracking, or maybe team A uses product X for issue tracking but team B uses product Y, today you're kind of stuck. The idea here is very much that there's obviously a common data model here. One person's issue is very much like another person's issue, whether you're using Jira, Bugzilla, what have you. There's a core common data model. There's a lot of power, especially for larger enterprises, in being able to ask these questions in a very generic sense without having to get very specific about where did that data come from, or having to go dig in and become a Jira expert or become a Rally expert or those kinds of things. That's very much a core part of our efforts here.

That allows you then to start doing really interesting things. Let's say that you want to start using feature flags. Because we know the features that are being worked on, because let's say that we extracted that information from Jira, from the epics that are in there, and we've put some definition around that. We have a lot of information about what's in production and what's not in production because we have that information as well. You can start to not just make visible the kinds of things like feature flags, but also make them actionable. From this kind of dashboard, you can sit and say, "Well, we're still using this only for internal customers or internal preview folks, but we're about to unleash the hounds on the rest of the world. Maybe we'll start with EMEA or USA, or maybe we'll do a little bit in each," those sorts of things.

If you've ever worked with feature flags, you know what a freeing and amazing thing it is to be able to sort of deploy darkly, and have things be in production but be able to control how you turn it on. To be able to preview it for people, to be able to pull the switch and turn it off if there's a problem. So that instead of having the big-bang rollout of, "Oh, here's our great new feature," you've got 100,000 people who use it the first day, and it just craters because we forgot to do scalability testing or didn't do it well enough, or found a corner case that we didn't know about before. You get to play with it a little bit more.

Feature flags, whether you use Rollout to do it or build it yourself or another product, check them out because they're incredibly powerful and incredibly useful in getting stuff into production without breaking it, and being able to experiment and show some people one thing and show some people another, do A/B experiments, all of those kinds of things. Very powerful concept.

What I've shown you there, and talked about quite a bit for the last 28 odd minutes, is just this idea of common data. There are data silos. We might be awesome at microservices. We might be deploying multiple times into production every day, every hour. We might be rolling features left, right and center into the world and doing all of these things. And yet we're kind of not at nirvana just yet. We're not at the point where we can ask all these questions and figure out where the bottlenecks are without walking the hallways, without digging into all of these different data sources.

If you want to check this out, it's in preview right now. Some of the things I've shown you are in preview. Some of the things are not yet in preview: feature flags. But if you go to next.cloudbees.com/join, you can sign up for the preview and start to check it out. We've already started rolling out some of the early features. We're going to be rolling out more and more as time goes on.

Q&A

I've got about a minute and 45 seconds left. So if there's a couple of quick questions, because I noticed a hand up, I'll take a question.

Audience: One of the big issues that I'm seeing nowadays as people are moving more and more to containers and microservices is the overwhelming complexity with these apps starting to show up. Are you guys doing anything to help with that, help people get a better understanding of what they're looking at and how they can deal with their applications as they--

Anders Wallgren: Right. So I'll repeat the question for those that couldn't hear it. Correct me if I'm wrong, but as we're starting to use more containers and microservices and these kinds of things, that actually increases a lot of complexity. Microservices are not simpler, folks. They're very difficult to do. One of my favorite Twitter accounts is Honest Status Update, and one of my favorite updates from there was one that said, "I'm so glad we changed to microservices. Now every outage is a treasure hunt." One of the only benefits of a monolithic architecture is there's only one thing to break. Whereas if you have 500 microservices and something's broken, Lord help you if you're not doing good monitoring and logging and those sorts of things.

So how do we help? I would say a couple of things. One is there's definitely help in some of our other products. CloudBees Flow helps you a lot with those. Obviously, Jenkins as well, depending on how sophisticated and complicated you want to get with that. But part of what we're doing here as well is to uncover where these problems are.

To give you a more concrete example, let's say that you have a microservice. You have two services you're trying to release. One depends on the change in the other. Well, the one that you depend on is stuck. Why is it not in production yet? So what do I do today? I hunt down the person who's in charge of that, and I ask them, "Why is it not in production yet?" They say, "I don't know. Let me find out." Then either an hour or two or a day or a week later, or maybe they never come back to you and say, "Ah, here was the problem."

One of the real values here is you'll be able to see the data yourself. You don't have to go find that person. You can dig into that service, let's call that service a product. Maybe there's a new feature that we added to that service, and you can see what the bottlenecks are. You can see that there's an alert saying, "Hey, there's a pull request that's been rejected, and so that's why we didn't go." Or it made it into staging, but then it blew up because of some problem. I don't know, we forgot to make a schema change or the kinds of things that tend to happen. The idea very much is pull all of that data together and give you one place to go look at that data as opposed to having to go track down all of the people.

As much as people use the phrase, and I hate the phrase, "one throat to choke," it's never just one throat. There's always multiple throats that you need to choke to get to the bottom of these problems. Very much the vision for a CloudBees solution for software delivery management is the data comes to you, and you can ask those questions, and possibly -- not possibly, probably -- the person that is responsible for getting that service out that you depend on already knows because the system's already told them. That is what we're doing with the solution for SDM.

I'm out of time and, out of respect for the next person, I'm going to say thank you very much for attending the talk today and enjoy the rest of the show.