devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: Maximizing the Benefits of DevSecOps

When discussing security in DevOps, we often focus on the security tools instead of the DevSecOps process itself. In this DevOps Chat, ZeroNorth CEO John Worrall takes us to the root of “why” DevSecOps, focusing on the business benefit, gain and measurement of what we seek to accomplish through DevSecOps. John advocates we concentrate on the process and data enabling us to assess risk, prioritize the most beneficial security work and for decision making to creating business value.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Mitch Ashley: I have the pleasure of being joined by John Worrell, who is CEO of ZeroNorth. Welcome, John, good to be talking with you today.

John Worrell: Thank you, Mitch. Good to be here as well.

Ashley: And we’re talking about security and DevOps, DevSecOps. But before we get to that topic, would you tell us a little bit about yourself, let our audience know a little bit about ZeroNorth, too?

Worrell: Sure, I’d be happy to, Mitch. I’m John Worrell, CEO of ZeroNorth. We’re in the DevSecOps space, maybe with a different approach that, a lot of times people focus on tooling. We believe that you need to kinda build a process out first for DevSecOps to actually have business value, and I’d like to maybe talk through that with you, Mitch.

Ashley: That’d be excellent. I’m all about the business value, too. [Laughter] So, let’s talk about that. So, usually, when you say DevSecOps, it’s about shift left, how you need to get to the security people working with the software folks, how do you help developers write more secure code? You get to the tooling conversation.

So, I think you’re talking about—well, let’s stop for a minute and ask why are we doing all that stuff? Yes, let’s create better app security, but why do we need to make this a process that produces, maybe, some business value, measurable results, those kinda things?

Worrell: Yeah, you bet. That’s exactly right. We’re all for the tooling, we’re all for building the bridges between security and the Dev teams. But you have to have an objective in mind, and you have to have some help along the way. You have to have some data along the way that’s gonna actually get you there to pull all that together.

One of the best quotes I ever heard that got applied to this was channeling your inner Deming, which is, you know, if you can’t describe what you’re doing as a process, you don’t know what you’re doing, right, and there is a real lot of truth to that. If you step back and look at AppSec over the years, it’s been very tool-centric, very sporadic, anything but a process. When you look at DevOps, it’s a process, it’s repeatable, it’s scalable. It’s kind of a self-learning or positive flow of information with telemetry so you can get better and better at it over time just by learning from your past experiences.

And when you think about integrating security into Dev to drive DevSecOps, you have to think about it the same way, and I think that’s where it all starts. This is a process, this is not a tool selection, this is not just a scan or an integration, it’s that process that you need to build first, and then you can start building out your tooling, your technology underneath that.

Ashley: You have a really good point, and if I’m being over general here and generalizing this, as security professionals, we kind of think of, “Let’s buy boxes, let’s buy software, let’s put functions into the network, into software, and not into the software development process that will solve our security problem.”

But security is not just people attacking you, it’s also how you do your work and making sure you create a secure environment, you operate securely, write secure code. So, I think you’re spot on about the process and how you can do that consistently, referring back to Deming, right?

Worrell: Yep.

Ashley: You can’t manage what you can’t measure, your adaptation of that phrase. So, talk to us a little bit about how do you make that real? When you talk with people, how do you help them sort of elevate the conversation to that and then get on the right track?

Worrell: So, I think it starts out with that process conversation and whichever analogy you’d like to us for that. Think about it this way—the process, in our view, works like this. You’re gonna set some kind of a governance standard for your organization. You can’t have each Dev team setting their own or each business unit setting their own, you’re gonna wanna try to get global visibility so you can actually have effective global risk management. And we’ll start that as a kinda catch-all for the business objective—but in a sense, that really captures what we’re trying to do with DevSecOps. You need global risk management across your organization. That means you have to have some visibility into it, but you have to have a way to impact your current state to make it better, and you need a process to drive that in a continuous way.

It starts with setting some governance standards and saying, “Okay, what is our ideal objective for our top tier applications? What is our ideal objective or governance model we wanna put around our mid-tier?” or whatever the application categorization might be. Then you wanna make sure you’ve got a continuous process to build the data that’s gonna inform you, whether or not you’re actually meeting those objectives. You have to look at performance reporting so you can measure how you’re doing against that.

And then you have to be able to action that intelligence to say, yeah, that data is helpful to me for a number of reasons. Number one, I get visualization of risk, I can get prioritized remediation if I do this right so my developers can make intelligent business decisions about which vulnerabilities get fixed now before we progress the build and through the build. The third piece of that is, which teams need what kind of training on security coding, good security coding practices? Instead of trying to treat everybody the same, use this telemetry to say, “You know what? Team A is struggling with cross-site scripting. Let’s go do a lunch and learn with those guys and watch the immediate impact we’re gonna get from that” and then let the process continue and go all through. There’s a lot of technology in there, there’s a lot of things in there, but it starts with the process.

The next piece that’s really critical is the data that comes out of that, right?

Ashley: I was just gonna ask you about the data part of it. [Laughter]

Worrell: [Laughter] That data drives everything. It drives so much. You know, we had talked about this idea that you’ve got different tooling—well, sure you do. You want the best tool that you can get, you want best of breed. But trying to pull those tools or the data from those tools into some meaningful, actionable intelligence is a key step in the process, right? You wanna take different data points and put them together so you get a complete view of what the risk posture is for that particular target or entity or application you’re working with.

We talk about the analogy of the blind man and the elephant. You have four blind men all experiencing an elephant from different places, and they all can come up with a different understanding of what they’re really touching and trying to investigate. And it’s a perfect analogy for a multi-tool environment when you’re scanning across the pipeline that, if you just look at one experience or one tool, you’re not gonna get a complete view of what’s going on.

Imagine the difference of being able to just do static scanning and realize that you’ve got all these highs and criticals, but not compare that with your dynamic. So, a lot of those highs and criticals may not be exposed in my environment, right? I wanna pull those together.

I’m trying to understand, number one, where the risk is, but I’m also trying to optimize my developer productivity and making sure they’re not fixing a bunch of stuff that doesn’t need to get fixed, if I’ve got a compensated control in place or it’s just not exposed already. That’s not high on my list. I want to really focus in on what’s valuable.

So, that data can be used for making good business decisions on risk. It can be used for prioritizing remediation. That data can be used for, you know, call it the wall of fame, wall of shame. It’s how do you really measure and incent and reward your business units for meeting their risk management targets, right? Again, how do you help those that are lagging behind, how do you help them get better?

And that, to me, built into this process, is where you get real business value. You’re getting the faster delivery of software, you’re getting the better developer productivity out of this, you’re getting that risk management layer and visibility you need, but you’ve got it as a process, and you can measure week to week, month to month, quarter to quarter, how much better you’re getting at it. That, to me, is a real business solution.

Ashley: You know, you described a lot, so let’s unpack some of those things. The third piece of it usually is, you know, you talk about people process and technology people. What are the kinds of roles of people who are gonna be using that kind of information, that kind of data? Because we’re often talking about getting security information into the developer’s hands so they can fix things, but you’re also talking about, “Well, what should we fix? Let’s not waste our time on things that don’t matter, right? The environment secures against cross-site scripting, so let’s not worry a much about maybe that as something that can be exploited.” Who uses that information?

And then I guess the third part of it is, it’s about continuous improvement, that’s a cyclical process of, “Are we getting better? Are we getting value? Is there benefit to the work we’re putting in on this?”

Worrell: You bet. So, you’ve actually said a lot there, too, so, I’ll try to—

Ashley: I did. I’m just following your lead, John. [Laughter]

Worrell: Yeah. [Laughter] Good, we can confuse each other in this whole process.

So, you know, if we start with this idea of the continuous improvement, just kinda going backwards here, the whole goal is to have that process, which is a continual healing process, if you will, you’re always gonna get better. DevOps does that with telemetry about, “What is the productivity of my developers? What are my key metrics on how many story points I’m taking down, how many am I delivering, and am I getting better, sprint after sprint after sprint?” All great stuff—the same model plays out in security.

That ties back to one of your comments about the role of the CISO. You mentioned, you know, typically, security guys, via technology, they deploy it. And that works or a proactive control, which is what security’s been doing so much for. My days of running the product for RSA SecurID and working at CyberArk and any kind of blocking technology or control—it is. You buy it, you deploy it, you set it and forget it, for the most part, and it works, right?

By the same token, this isn’t really responding on the SOC side, either, right? This is not responding to an in process attack, this is a different approach to security. And I think the reason that’s important is, number one, businesses are demanding more business metrics, business telemetry out of their security programs, what am I getting for my investment? How do I know I’m investing in the right things? Am I spending in the right places? All of those things are really important, right?

And the role of the CISO, by definition, is evolving as well. And you can see the people that were running security teams 10 years ago are very different than the model who’s out there now. Many people have grown into that role. Other people have come from the business side of the house, and they’re not the technology experts that were good at configuring firewalls that were really trying to deliver business value to the organization. And if you’re gonna step from infrastructure into the world of application security, you need to be able to have value to the business, and this data is a great way to deliver value to the business.

Ashley: Really important point, because the CISO role is evolving, and oftentimes, it’s becoming a CIO/CISO kind of role, which means you’re getting into the application stack, not just the network stack. Not saying that they weren’t worried about the app stack, but now you’re getting much more into the nitty gritty of it. And are your security people software people? Well, not necessarily, but they are very accustomed to getting data and responding to that data, and in this case, maybe helping development teams, developers, others with understanding what the true severity, not what some scanning tool might say, right?

Worrell: You bet.

Ashley: Which is sort of our history with vulnerability management, [Laughter] to really help them understand, “Okay, great”—and then demonstrating to the business, to compliance, to whoever you may need to be reporting to, it could be customers as well, to say, “Here’s what we’re doing. Here’s the actions that resulted from investment in these tools, people, and processes.”

Worrell: And that customer angle is actually really important. And I hate to use the word SolarWinds, but I’ll use it. It’s just put, yet again, a big spotlight on software supply chain, software security, and how critical that is. And so many organizations now are asking of us, as well as our customers, “What is your software development process? Prove to me you’ve got one.” Right? Great use of this data.

When you think about your business line risk owners, the people that are actually responsible for data, they work for the GM or the SVP of that business unit, they’ve got the risk management challenge. They need this data to do their job well. If you take that data to the board, our data is being used as part of the quarterly board package to talk about how they are addressing and how they are improving the risk posture of the organization.

And then, I wanna go down, really, one level deeper. Because when you think about this, you know, integrating into the DevOps process means that it’s not necessarily just about the developer making that independent decision. Typically, there’s a product owner in there some place that’s gonna be making some decision about what’s gonna get done now versus what’s gonna get done later, right?

So, being able to feed that product owner with the data they need to help do the triage and make those decisions, that’s another great use case of this data we’re pulling together.

Ashley: You know, you mentioned a lot of roles, too, including the product person. In your experience with ZeroNorth—and I really appreciate your background in security, too, so we can relate about those days as well—what’s most often, when people come to ZeroNorth and say, “Hey, we need your help, here’s what we need your help with?” Is it the software team, is it the product team, is it the compliance group, is it the CISO/CIO? Usually, what’s that initial driver for engaging with you.

Worrell: Yeah, there’s probably two different ones we hear most commonly. One is, “Hey, I’ve got a somewhat mature program, I’m running two or three different tools. I can’t make heads or tails out of the data, or if I try to do it, it’s manual, I can only do it once a quarter or once a month, it’s just too labor intensive. So, I think I’m getting good, I’ve got a decent process right now for scanning, but I wanna start pulling that data together.”

The second use case is those that wanna start out on building what we would call a federated or a shared governance model, and it’s led by the security team, perhaps, but they know they’ve gotta bring in the business line owners into this process, or business line risk owners into the process. And they say, “Hey, can you help me get data out there so I’ve got a single source of vulnerability truth or my applications?” And I’m looking at the same data that they’re looking at, we’re all making decisions off that same set of data so we can build a governance model that makes sense.

The security guys wanna work in partnership with the business owners and the people that are actually doing the software development and risk owners in the business. But that relationship is gonna get built on having really good data and everyone using the same data. I think that’s another use case.

The third one, which is a variation of that, is people that are coming in and really saying, “Hey, listen, I need to go to full DevSecOps right away. I know that I can put this layer of reporting and analytics on top of my current tooling and that’s a great start, and I’m gonna build this over time.” It’s a fine strategy. Other people are coming in because they’re just getting started or they just have a business imperative to do it and they’re saying, “We’re going to DevSecOps right now, and we wanna do the pipeline integrations as well as the reporting and analytics that we’ve been talking about so that I do get that data in real time, I do have a consistent scanning process, it is automated, I don’t have to worry about the developer forgetting or not doing it, and I’m gonna get that data value out of this in that particular way.”

Ashley: Yeah, “Help me accelerate through the learning curve instead of making all those mistakes myself to get to DevSecOps, if you will.”

Worrell: You bet, you bet.

Ashley: That second example especially kind of is a multiplication of the first one, which is, you have Dev teams with all this data, maybe it’s the primary group—usually, it’s multiple, right? How do you pull it together into something? They can’t make sense of it. How do you do that across the enterprise to meet compliance requirements or even just your own internal assessment and reporting up the management chain maybe to the board.

Worrell: You bet. If you step back, the biggest concern we get out of just about everyone we talk to is a CISO or a Risk Manager saying, “Hey, help me, I’m flying blind. I don’t know what highs and criticals I’ve got in my production environment right now. I just don’t know. I don’t have visibility into it. And for me to get it, it takes too much effort, and once I get it, it’s outdated, because it’s 30 days old. I’m pushing code every day” or every week or whatever it might be.

And that is the primary motivator or so many people who just say, “Gimme that visibility, and that’s the starting point. And then at least I know what I’m dealing with and then I can start building out a program that’s gonna help me address that over time.”

Ashley: You know, you brought up SolarWinds, so I’ll bring up COVID. What have you seen happening over the last 12 to 18 months with the acceleration to the cloud, acceleration of digital transformation projects? Has it taken these same issues and just made them even more visible critical to address, or have new problems emerged?

Worrell: I think it’s more of an acceleration of the entire process. In general, COVID has driven people to be more comfortable or more reliant on relationships with their customers, with their partners, with their employees. And that means more software, by definition.

So, as digital transformation accelerates because of more online interaction and new business models that this opens up, it’s just really accelerated the pace and some of the maturity of people coming. The types of questions we’re getting from our prospects now are much more advanced than they were a year ago. And that just shows that the market is really getting smart about this and they’re kind of moving beyond the tool only approach to say, “Okay, how do I get some business value out of this that can really, really help us move our risk management program forward?

Ashley: That’s one of many indicators I see, kind of data points that are saying the technology groups, the software groups are getting out from under, looking at themselves and starting, trying to get aligned with the business and meet where the business is headed.

Worrell: And as a big consumer of software, as we all are in our lives today, I’m really happy to see that, right? I mean, that’s what I—I know it’s gonna take bringing the two together and working cooperatively in that federated or shared model to make this work, and I’m really happy to see that kind of a progress. Because, like you and everybody else, software just drives so much of our daily experience.

Ashley: It is. Can’t do much without it these days. Well, it’s been great talking with you, John. Where can folks learn more about ZeroNorth?

Worrell: Well, that’s easy, ZeroNorth.io. We’d be happy to talk to you. Take a look, see what we have, and if we can help you out or you wanna hear more about it, we’d love to chat with you. Thank you very much.

Ashley: Yeah, I think we’ve had a great conversation. Hopefully, that’ll spark some folks to elevate that conversation with you and the ZeroNorth team, so take care, we’ll talk to you again soon.

Worrell: Thank you, Mitch. I appreciate it.

Ashley: You bet.

April 21, 2021
Security Policy Management and Hybrid Cloud with Tufin

In this TechStrong TV / DevOps Chats interview, Colby Dyess, director of cloud product management at Tufin, joins Mitch Ashley to discuss security policy management across hybrid cloud, multi-cloud and cloud-native security. Recorded in late 2020, Colby shares some experience from working with customers during the rapid migration to the cloud in 2020.

The video and podcast audio of the conversation is below, followed by the transcript. Enjoy!

TechStrong TV Video

DevOps Chats Podcast Audio

devopsy.kinsta.cloud · Security Policy Management and Hybrid Cloud, Tufin

Transcript

Mitch Ashley: I’m joined today by Colby Dyess who is director of cloud product management at Tufin. Welcome, Colby. Welcome, it’s good to be talking with you. Would you introduce yourself, tell us a little bit about you and of course, tell us about Tufin.

Dyess: Yeah, well, you’ve got my name and my title, so I’m dialing in here from beautiful Southern New Hampshire where it’s fantastic weather. So, I’ve worked for Tufin Technologies, Tufin is really well known in the industry for providing security policy management, mostly in the organizations like the Global 2000 complex environments where you need to make changes to the network environment and you need to be able to do it quickly, safely, ideally you do it automatically and it’s secure. The Tufin product suite helps organizations do that and we’ve done that in the traditional space. Of course, our customers have adopted cloud, cloud native platforms, Kubernetes, and we’ve been taking these same capabilities for securing the environments and bringing them into the cloud, so no matter where you put your workloads, we can help you, and that’s mostly what we’ve been focused on.

Ashley: Good stuff. Boy, the center for the universe for a lot of folks. Kinda speaking of that and just thinking about the timing of where we all are, you know, there’s a lot of statistics. I run an analyst firm as part of MediaOps organization called Accelerated Strategies Group. Anyway, we have a lot of data showing some of the acceleration that’s happened, both in digital transformation and also move to the cloud, just in the last six to nine months. I don’t think that’s news to anybody, right? I don’t know if you need data to say that, because it’s happening probably in most people’s organizations.

Dyess: Right.

Ashley: If I put on my security hat for a moment, we always get plenty of notice when we’re making changes and doing new projects and accelerating stuff—sarcasm—so, I’m sure there’s a lot of security folks who are scrambling still just to not only keep pace, but make sure we’re all doing a good job of securing environments that our developers are taking this into, making sure we’re understanding the services we might be using now that we weren’t before, cloud services that we’ve been in. I’m sure you’ve seen a ton of that happening with your customers.

Dyess: Yeah. It’s no surprise. Organizations have been moving to public cloud environments for a long, long time, at least, technically, for the past 15 years, they’ve been doing it, but it hasn’t always been sanctioned, right? Let’s say over the past five or eight years, organizations have really begun to intentionally adopt the cloud. And now this year, of course, everybody’s moved to the cloud about as quickly as they could.

What we’re seeing, at least what I’ve seen a lot is, security is now scrambling to try and get ahold of some visibility—what’s really going on inside these cloud environments—and trying to put some sort of guardrails around the services that the Dev teams are using. That’s a real challenge because they’ve been focused so much on how to secure most of the on prem environment or use firewalls to protect the cloud space, but now they realize they’ve got to go a bit deeper, because the threats are pretty real out there and they’re really dynamic. And if you’re not sure how to secure the cloud environment, you’re going to leave yourself open to threats.

So, security has really been spending a lot of time trying to learn more about cloud and cloud native security controls. We spend a lot of time helping customers figure out the difference between cloud native security controls and on prem stuff and then how to combine them so they can be assured it’s all secured. We see that a lot, yeah.

Ashley: Well, you know, I mean, we’ve all been doing firewalls and intrusion prevention and access controls and the list goes on.

Dyess: Yeah.

Ashley: So, the topics aren’t new, but the environments are different and the services. It’s not like you can go into the cloud—no, let’s use all the things I’m normally using in my on prem environment. Maybe you can get some software versions of that. Sometimes it’s just better to use because it’s better integrated, you spend less time making the environment work by using what’s provided by the cloud provider.

Dyess: Yeah. That pattern is the same everywhere. I’ve seen that you’re gonna go to a new environment, you wanna take some of the things that have worked for you in the past and carry them forward. And a lot of times, that makes sense as you try to move quickly into the cloud. If you’re not familiar with cloud native security controls, you probably think, “I’ll just use firewalls and the process for managing firewalls in the cloud.” And there are a lot of options to do that, a lot of the traditional vendors in that space have tried to make a pivot to offer their same services, same capabilities in the cloud environment. So, it’s no surprise that we see a ton of that.

At the same time, those processes around managing all that stuff still takes too long. If you moved to the cloud, you went there for agility, right? You want to rapidly build applications and get them out into the market as quickly as possible. But if you’ve got to fill out a ticket to get a firewall changed and it takes three days for that stuff to be processed, you’re no longer as agile as you used to be when you could twiddle a little configuration in a Terraform template, redeploy, and—poof, you’re up and running all over again. That’s something that security teams—

Ashley: If you take another two days to answer that ticket, you’re probably gonna have a fourth after your third _____ while you’re add it to the mix, right? Some developers are gonna be like, “I’m outta here, let me go set up the next environment.”

Dyess: Yeah, it’s too difficult. You can’t wait. You don’t want to see shadow IT any longer, because IT was taking too long to respond, but you’ve got to respect that IT’s there, the security site of IT is just really trying to help protect the business.

But you know, you also saw Amazon and AWS, they both announced their own firewalls, right? Azure did a little bit back and AWS just did within the past month. And I think that’s really just paying homage to the fact that those are really good technologies. Firewall technologies really are good stuff and it’s more than security groups or NSGs, it goes beyond that, and the businesses really need these. These do address customer problems. So, we’re seeing a lot of folks ask about how do they adopt those new to the cloud provider, new technology, and how do they integrate them into the very agile processes? And I expect we’ll see a lot more of that.

In fact, what we are finding that we do often is try to help organizations see how they can get the most value out of the cloud native security controls, because these cloud environments are really, they’re pretty solid. And like you pointed out, the security controls are integrated into the services. So, it makes a lot of sense to use the services, they’re there to protect your assets and they’re so integrated in the services, you really should be trying to use them, but it’s a learning curve for security, so it means a lot to try and help them get the visibility and then start to affect control over that, so that they don’t have to slow down the rest of the business, swapping out, let’s say, a cloud native control with a legacy control [Cross talk].

Ashley: Mm-hmm. It is that tradeoff, and I think that’s one of those where it’s sort of, I think it puts security teams in a position where, are we gonna stick to our guns of this is the environment we’re gonna have consistent across all of the environments we operate in, or for sake of speed but not sacrificing security, maybe we do look at some other options and can those integrate into the monitoring and management systems as opposed to using the same firewall in every environment that we take with us there, right?

Dyess: Yeah, yeah.

Ashley: Easier said than done. I appreciate it’s not an easy job.

Dyess: Right. You know, whether you decide to use the cloud native security controls or use the traditional kinda controls, the virtualized versions of those or a combination of them, one thing I think we’re sharing is, we see a lot of conversations around how—which technologies to adopt and then how to actually manage those technologies.

And from my point of view, it seems like we’re almost too focused on getting down into the weeds about the specific security control and, as a security person, I think it makes a lot of sense to step back a little bit and try and focus on what’s the overall security policy. Instead of thinking what firewall should I use, should I use one from the cloud or should I use from my traditional vendor, maybe a better question to help organizations remain agile is for security to be able to focus on what the security policies are, what the guardrails should be, and then begin to get the practice of checking cloud environments against those guardrails, against these policies as part of your CI/CD pipeline, the whole buzzword of shift left.

That’s a real thing, right? That’s really important. That security can focus on defining security policies where they have the strength, but the actual implementation of enforcing the security policy is probably handled by the cloud operations or whoever actually twiddles the bits on the security controls. Like, if you can marry those two things together and you can do it in the CI/CD pipeline, then that’s a huge win.

We’ve seen organizations move a lot faster because security focuses on what they do and they get it codified in a way that can play in a pipeline, and now the app teams, they can make changes to an application or a cloud Ops can change the configuration of an environment and get an alert saying it doesn’t comply with the security policy. That’s great. To step away from choosing which sort of security device you want to use and focus on do things comply with the security policy? That’s a major shift, and one that seems to be really hard for organizations to do. I think to kinda get away from security being hands on with the control and now focused on the policy—it’s trust but verify, I think.

Ashley: [Laughter] Back to that old saying, right?

Dyess: Yeah.

Ashley: You know, in a way, it also comes down—you know, we’re used to, let’s first take an inventory and make sure we know what’s all out there that we’re trying to secure.

Dyess: Sure, of course.

Ashley: But it’s equally just as important to have, whether it’s change management practices or software that can help you with notifying when changes occur or understanding, so when a change occurs, how does that map back to policies that we have in place and are we still in alignment, are there gaps that we have to take care of? Because the environment isn’t—it isn’t an environment we control everything in any more. It changes by itself, because other people are changing it along with us. So, it seems like it’s a more dynamic environment than maybe what we had 10 years ago, if you reflect back a bit.

Dyess: Intentionally more dynamic, right? Businesses have to move faster, we also have to react more quickly to customer demand or competitive threats or whatever. So, the fact that we’ve got these dynamic environments is just a reflection of what we actually needed to have built, anyway. And now, we need to find a way to incorporate that back into our regular practices.

So, you made the comment about being able to track what’s changed and when and all that, but if you adopt more of an infrastructure as code model, you already have that. You don’t need a CMDB—maybe you do, but you don’t have to have a CMDB in place when you could go back to your Git logs and see, oh, here’s the pull request for the change that we made that allowed for this security group to be open or for this Azure firewall to have this particular rule. You can actually see that information, but these are, on the security side, these are new tools. As a security person, when was the last time you looked into a Git repo to see what the configurations were? [Laughter]

Ashley: The repo—right, GitOps and security, right?

Dyess: Right. Right, but we’ve got to get somewhere around there, as a group collectively, whether we’re writing the code or we’re managing the operations or we’re managing the security collectively, we’ve got to be able to collaborate and use these tools that I can’t say are merging, they’ve been around a long time. Terraform and Helm, Ansible, Chef, Puppet, the whole bit—these things have been around for a while, but to incorporate them now into our security practices is a pretty big leap for folks.

Ashley: Mm-hmm.

Dyess: So, we really try to encourage that the security team gets the visibility that they need, that’s the first thing, as you pointed out, right? You absolutely need to understand what’s deployed, what’s talking to what and whether or not things are properly segmented.

You’ve got to first get that visibility, but I think before you start jumping into let’s throw a bunch of other control points in there, consider what resources are there and how can you, on the security side, participate in automation, participate in these flows that your CloudOps, DevOps, SRE, whomever had set up. Because there’s a really good opportunity now on security to be part of this agile process and to allow the business to be secure, but to do so in a way that won’t break the developer productivity.

Ashley: Mm-hmm.

Dyess: And that’s, it’s uncomfortable, because it’s a big change, but it’s a change that I know it can be done successfully. We’ve worked with companies that have done that, you know, make the conscious decision.

Ashley: I almost wish we had stepped back and redefined shift left, because if, you know, I were king of the world for a nanosecond, I would think about it as, it’s not just about getting security people to work with the software teams earlier in the life cycle of software—yes, it’s that. But think about it this way of, the old world was, set the policies and then how do we implement the enforcement mechanisms, right, to make sure that those are being followed.

Dyess: Mm-hmm.

Ashley: I think in the world we’re in now, it’s, security people are, if you were gonna set up a security practice in an organization today, what I would do is, let’s start with how software is created, let’s work with the team about how the entire tool chain is set up, how that flow happens, both for application software, but also for the infrastructure and how that gets created where we’re talking about test environments and production environments and maybe you’re stepping into infrastructure as code if it really, truly is kinda dynamic Terraform or whatever kind of environment.

But start there, because if you understand how that’s done, now you know how to secure it. You know how to work with teams to help them secure it, then the next layer would be getting into the software architecture itself around microservices and things that are more porous than we’re used to, kinda the hard outer shell of monolith applications of the past.

That, to me, is the mental shift, the big mental shift for a security team to not necessarily be an expert at all that stuff, but understanding that’s what you’re really securing now.

Dyess: So, two things that stand out, like responses I can imagine people having right now and that’s, I don’t have time to go and learn all that stuff. [Laughter] I’ve already got 20 other tickets for all high priority things. I’ve gotta get on that right now, so I can’t go and learn all that stuff. Valid, that’s definitely the case in a lot of organizations, yeah.

And another problem related to this is security teams who maybe do want to know, maybe have some time to do that, but struggle that the application teams themselves don’t even know what makes up the application and what connections do they need. So, even the folks who you think would know because they built it, you’d think they would know the answers to some of these questions, but it turns out that they don’t—in a shockingly large number of scenarios, that’s the case.

Ashley: Mm-hmm.

Dyess: And so, if you’re gonna shift left, you’ve got to address not just the problem of the security team getting visibility in this—or maybe, actually, it’s the same thing. The application teams have to be able to come to the table to say, “This is what the application looks like. Here’s how it’s put together. Here are the resources it needs and here are the services that will rely upon it.”

Ashley: Mm-hmm.

Dyess: And so, if application groups can come to the table with that, then a security team can look at it usually very quickly, look at a map and say, oh, I can see where it needs to be segmented this way. I can see where he’s a resource that has too close of an access to PII, PCI, right? And so, that conversation could start a lot sooner if it’s part of your normal bill practices, you were generating these views, you had some way to produce an item that a network team or security team could look at, right? They don’t need to look at the source code, they need to look at your network topology, they need to understand what you’re connecting to.

So, if you can bridge that gap, that goes a long way. So, to your point, it’s not just like, “I just need to check if it doesn’t comply with the policy.” Sometimes, it’s even just trying to define the policy at the outset.

Ashley: Yeah, on what you’re trying to secure.

Dyess: Yeah, but also, while security never seems to get the heads up about the things that are coming down, the joke that you made at the beginning, it’s also the case that when the application team is building something that they don’t really have all the rules, they’re not sure what all the restrictions are, and there are certainly plenty of guardrails, guidelines that they could have if you give them access that they could pull from an API to do their own checks.

So, you know, there’s a model. We’ve done this before in the industry, back when I wrote code, we had a separate QA team, so we’d write code, we’d do a little bit of testing, but just enough, frankly, to get us through the build, right? And then we throw it over the wall and it went over to QA. And then thankfully, our development practices matured to a point where we realize we actually need to integrate testing as part of what we do. So, as developers, we had to own some of that testing, some more of the testing, but also importantly, the test team got involved earlier in the application life cycle, the model you were talking about. So, the QA teams could come in and learn a bit more and begin to set up some of the additional tests and participate in the build process, so what they did showed up in NMake.

So, I think security is on a path like that as well. I think security, instead of app teams just throwing it over the wall and asking security to figure out how to lock it all down, I think we’re going to, and in some places, some customers for sure are moving to a place where security is part of the process earlier, and if they can say, “Here’s some of the tests,” so now the guardrails, they can contribute some of that and they can go into this build process, then now you’ve really begun to get that shift left.

But I know this can happen. We’ve seen it happen before. Now QA is just integral to what we do. You can’t even imagine putting a product out without some part of QA being part of the build process and tests happening really early on, test planning happening early on. I imagine security just going in that same sort of loop.

Ashley: Yeah, of course Tufin’s been in this space for a while, has built up, I’m assuming, a body of knowledge about this. If you were gonna advise maybe a new customer or an existing customer on—okay, we’re always playing catch up, we’re really playing catch up now with how much more cloud services that organizations are using in such a short period of time, what are some of the sort of best practices or recommendations of, “Here’s to sort of get the first thing established, here’s the next thing to work on, here’s the next thing to work on.”

Dyess: Yeah.

Ashley: Any suggestions about that?

Dyess: Sure. We have this whole crawl, walk, run methodology, and it’s designed to help organizations take these small steps towards getting to really secured environments. And the first step right away is just to get visibility, which is kind of a “no, duh” statement, but it’s actually one of the big problems that orgs have. You’ve got to be able to see what’s deployed inside your cloud, what’s deployed inside your cluster, and which resources are communicating with each other, where are the dependencies.

So, understanding that is a really major first step. It’s true for the application teams, but for the security, it’s to know are things properly segmented, where are the biggest risks? So, getting that awareness, that’s really the crawl phase. And in the walk phase, that’s where you take what you’ve learned about what’s deployed, what talks to what, and whether or not things are segmented properly and then you begin to isolate. Here are specific accounts that we need to tackle or here are clusters that we need to tackle—like, hone in on the higher priority items and begin to define a security policy for those cloud native environments.

And as you develop the cloud native policies, which you then share with the application teams or the cloud operators, whoever’s responsible for configuring it. As you develop that sort of, that skill, you’ve gotta get to the run phase, and the run phase is when you begin to automate this. You automate generating security policies, you automate validating security policies, but at the very beginning, where most organizations are at right now is, first get the visibility and then the second step of defining a security policy. Not defining what is my security group definition, not defining what is my AWS firewall definition, but what is my security policy? What are the rules that should govern access to applications, assets, resources of certain categories? Those are two big steps to take right away.

Ashley: I think that’s some great advice. I’m curious, any thoughts as we—I think we all want to turn the page on 2020 and kinda get to 2021, and hopefully, we’re looking at a different kind of a year. But one of the things about 2020 is, we’re not gonna go back, I don’t think. We’re not gonna go back to, let’s rewind to January and start working in that environment again, right? Everything is changed with remote work or how much we’re using the cloud.

What are some things that you’re anticipating for 2021 as you look forward in the next 6 to 12 months. Do you kinda think it will be topics maybe not as talked about yet but will be more topical in 2021? I’m just kinda asking you—

Dyess: Are you asking for predictions of 2021?

Ashley: You know, I don’t see it, but I’m pretty sure, there might be a crystal ball right behind your chair, just look back a little bit there and kinda check back. [Laughter]

Dyess: [Laughter] Well, I think, given the maturity of the market adoption of public cloud environments, I think we’re going to see more security teams getting their arms around how to help in securing these cloud environments without necessarily always relying on the traditional devices. We’re already starting to see that even now. So, I think we’ll see more of the cloud native security control adoption. I know organizations have seen the benefits of doing that to lower cost of operations, just total lower cost of ownership, plus the benefit of being able to say when there’s a problem, I can call my cloud vendor, I don’t have to worry about vendors poking at each other. So, I think we’ll see more of that.

I think it’s the Kubernetes space that’s probably the most interesting, because it’s the least well known for most folks on the security side.

Ashley: Mm-hmm.

Dyess: So, I’d say maybe over the past year, there’s been a lot of emphasis, just like with cloud, slap a firewall on it and we’ll solve the problems of micro-segmentation later, but later is gonna happen real quick, and I’d expect in 2021, you’ll see securities start to get more involved in getting visibility into the clusters and then looking to define the security policies.

And not—again, not to try and define the policy of an individual cluster, but just the general rules, because there’s no way we can keep up with what will really be thousands of services running inside of a cluster.

Ashley: Yeah.

Dyess: So, we’ll see that. I think we’ll see more organizations at the security side have to deal with the scale and the rate of change and begin to participate in the automation processes that the Dev teams are using to manage it.

Ashley: Maybe that’s something we’ll hear more frequently. I wouldn’t be surprised if the—let’s think of it as cloud native security, not just as security, sort of think about it as one of you architectural approaches to how you do security.

Dyess: Cloud native. The native controls of the cloud provider—yeah, that’s a big shift for folks, I think.

Ashley: It is. We’ll see if something like that happens. And I think the things you said made a lot of sense. Well, it’s been great talking with you, it’s the first chance you and I have had to talk before, and—

Dyess: Yeah, it was good to talk to you, Mitch.

Ashley: – a lot of fun. Tell us a little bit about where folks can learn more about Tufin.

Dyess: Yeah, of course, you can go to Tufin.com, that’s T-U-F-I-N dot com. On the cloud side, like what’s really relevant to what we’re doing here, we’ve got a lot of resources at Tufin.com/try-securecloud. It’s cloud native security controls. It’s really designed to help you get visibility and control the cloud native security components. Great stuff there, free to use product. There’s a great trial for people to give a go. Tufin.com would be the place.

Ashley: Great. Perfect. Thanks. Well, we wish you the best and a even better 2021, we’ll look forward to that.

Dyess: Yeah. From your lips, man.

Ashley: [Laughter]

Dyess: Good luck in 2021, everybody.

Ashley: There you go. Hang onto that, hang onto that. Alright, well, take care. It was very nice talking with you, Colby—Colby Dyess from Tufin.

February 23, 2021
DevOps Chat: ITIL 4 and Achieving High Velocity IT

In this DevOps Chat, Mark Smalley of Smalley.IT, and Lead Editor with AXELOS of the ITIL 4 High Velocity IT joins ASG CEO Mitch Ashley to discuss his work creating this new contribution to ITIL 4. Mark shares the 5 value investments important for organizations seeking to operate at high velocity and some of the insights gained from himself and others covered in this ITIL 4 module.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · ITIL 4 – Achieving High Velocity IT, AXELOS

Transcript

Mitch Ashley: Well, I have the pleasure today of being joined by Mark Smalley. Mark is Lead Editor of High Velocity IT, part of the ITIL 4 initiative. Mark, welcome. He’s also with Smalley.IT, I believe a one-person firm. Welcome, Mark. Would you please introduce yourself, tell us a little bit about you and the kinda work that you do?

Mark Smalley: Sure, Mitch—thank you, thank you. Yeah, Smalley.IT, I’ve been on my own for about eight years now; previously, around 30 years at Capgemini and other managed application service providers. So, very much on the application side, very much on the service provision side. That’s really my background. The personal background—born in London, but have lived in the Netherlands, just outside Amsterdam, for about 45 years now, which is not a bad place to be.

Ashley: No, not bad at all.

Smalley: One of the recent—yeah, one of the recent initiatives I was involved with was the AXELOS ITIL 4 update, responsible for the emergence, I say deliberately the emergence of the high velocity IT module, because it was quite an interesting process, pulling in knowledge from various areas in IT service management, but also agile DevOps and out of the IT space completely. For instance, some people may have come across The Toyota Way, the management book about the Toyota manufacturing process. Professor Jeff Liker at Michigan University, he kindly contributed a bit to the book about the Toyota Kata, which is about an improvement method based on scientific thinking. So, drew in people from various fields to try and get this thing off the ground.

Ashley: That’s gotta make it really fun and engaging, too. Why don’t we start out with what do we mean by it? What’s a good definition of high velocity IT? How would you give kind of a working definition of that?

Smalley: I’d first qualify it by saying it’s not actually high velocity IT, but it’s more about higher velocity IT, because high would imply that there’s low and you say, you know, “High is good, low is bad”—well, that’s not the case. We’re on a gradient, on a spectrum from lower to higher velocity. We’re looking at the kind of organizations that you’d say would be more digitally enabled than most.

So, the kind of organizations that use technology to do things significantly differently or even do significantly different things because technology enables them to do that. And that requires a different way of thinking, a different way of working than many people are used to. So, the book’s about different ways of thinking, different ways of working, and primarily the people in the IT service management space who are now confronted with this digital stuff and how do we deal with that? And trying to get them—it’s sort of a guided tour through the kind of things that you come across in these more highly digitally enabled organizations to encourage them to unlearn the old ways of working that aren’t effective any more and integrate new ways of working, new approaches in how they do stuff.

Ashley: I think one of the really important and kind of fascinating parts of your work on this, Mark, is it’s not just about the bubble of IT or the bubble of my part of, my role in IT, it’s that high velocity for the whole organization and how you all work together. And I know it really—there are many places to start, but clearly, product management, there’s some outcome that we’re doing all of this work for, some product or service or offering that we have, and that’s a great place to really engage in kind of a systems thinking about this.

Smalley: Yeah, very much so. It’s taking the end to end perspective. We’ve defined five objectives to give us a bit of guidance in this space, talking firstly about valuable investments—are you doing the right thing in the first place? Are you automating the right kind of business processes? Are you building digital products and services that are appealing to the marketplace? Are you doing the right thing? Fast development—are you doing it quickly? Resilient operations—once it’s up and running, is it resilient? And deliberately using the word resilient rather than reliable, because the kind of systems we’re dealing with are often complex and therefore unpredictable in their nature. They will fail.

Ashley: Mm-hmm.

Smalley: You know, these are fail-safe systems, these are systems that should be safe to fail, so it’s about the resilience—how quickly can you get the systems back up and running? Then the fourth objective is co-created value. Then again, you have that broader chain; that’s when IT starts engaging again, with the user community, in that intricate and even intimate dance that they do together that’s, you know, to help the users derive value from the investment. And finally, the fifth overarching or underlying objective is all of the above—assured conformance, it should be able to assure conformance to governance risk and compliance requirements, whatever they are in your kind of organization.

So, it certainly is, what you said, the big picture, end to end.

Ashley: Mm-hmm, very much makes sense. You know, it’s interesting—tell me if this jives with what you’ve experienced. Highly reliability, the best way to do it is don’t change anything, right? Make it very stable. But we live in a world where business needs to execute quickly, but also dynamically to react to changing market conditions—you know, pandemic being a great example of that.

Smalley: Yeah, yeah, yeah.

Ashley: A tragic one, but very much one that’s outside of our control—but also, you know, offensive strategies to go after markets and that, and the degree that the whole chain, the whole kind of supply chain of the organization working together can effectively do that quickly and reliably, but also resiliently, because you want to be able to experiment and try things. And maybe you need to fail to find the right answer for product mix or whatever.

So, I’m sorry, I don’t wanna go on too long, but it seems like that’s an underlying driver behind all of why you took this approach, at least in part.

Smalley: Yeah. Well, certainly, if you look at the dominant thinking behind most of the guidance there’s something behind it. There’s that concept of co-creation, realizing that you don’t do stuff and chuck it over the wall, you have to engage with other stakeholders—one of the things.

The other main thing is dealing with, working in complex environments. Again, using that word complexity in the sense of complex adaptive systems, organizational systems where you simply can’t predict what’s gonna happen and where you, because of the volatility, the unpredictability of stuff, you can say that’s bad but from a research and development perspective, you want to be able to, you know, 10 initiatives will fail, but it’s that 10th one that’s gonna make you millions. You’re gonna benefit from that unpredictability.

So, it’s really, it’s from the start, through the whole life cycle that you’re dealing with the—with the unpredictability which, for many people in IT service management, is a bit disconcerting, because if you go back—go way back, and you look at where people came from, IT service management people were very much concerned with the stability of systems and putting a wall around them with the best of intentions, with the belief system safe is good, whereas the developers had a different perspective—fast is good. So, you’ve got this fast versus safe. And seemingly, irresolvable, that conflict.

But if you look at it creatively—and this is something that we’ve got a lot to credit the DevOps community for, and we reference extensively stuff that’s gone on in the DevOps world in the High Velocity IT book. The idea that if you—and it goes back to lean as well, lean in particular, agile a little bit—working with small batches of work, if you do work in small batches and more frequently, then you reduce the risk, ________ smaller changes and less risk in bigger changes. And the interesting thing comes along now—if you do changes more frequently, instead of saving them up for each, you know, masses of changes each quarter, no, do them every day, then you develop your capability to change effectively.

So, paradoxically, you’ve turned it around completely. The more often you change—small changes—the better your change capability and therefore the more confident you can be that the changes will go through pretty safely.

Ashley: Mm-hmm.

Smalley: And it’s interesting, the groups that have to interact together, like, if you’ve got a DevOps group or a classic IT service management group, they identify with their own belief system, and often, the belief system is, you know, safe is fast—sorry, safe is good as opposed to fast is good. And how do you—you know, you’ve got to get these people together and talk about this stuff to resolve the apparent conflict. But it’s great stuff trying to build bridges between these communities.

Ashley: Yeah, I’m totally with you and thinking of the sort of lean mindset and agile and iterative, which is very much where software product and organizations have moved to or are moving there. What are the—how do you deal with some of the legacy silos and sort of that self-protection of don’t change things or don’t, you know, let’s focus on keeping things stable or whatever the mantra of those individual groups are? How can this book, for example, this module help people start to expand their thinking around those issues?

Smalley: Well, firstly, if you look at organizations, they will vary in velocity across the various divisions and departments. So, firstly, you’ve got to take a look at which part of the organization are we looking at? What is the appropriate velocity in the business there? What kind of cadence applies to their work? Interesting looking at the pharma industry that’s traditionally been highly regulated with very long periods in which they work. There’s no point speeding things up if you have to wait years before you move to the next stage. It’s like doing the Olympic games—you don’t want the stadium there earlier; there’s no point. So, it’s got to be very much aligned with the business velocity.

So, look at the specific parts of the business and, depending on the kind of speed—and possibly, you’re dealing with legacy systems that don’t need to go that much quicker. And the advice we like to give in the guidance is, the first couple of statements, the guidance is not complete, and the guidance is not intended to be prescriptive. We don’t pretend to be able to dictate, proscribe how people should act. Rather, we’re trying to encourage them to take a look at the 9 concepts and models that we’ve adopted, the 25 techniques to see which techniques do you think would apply to you. So, be selective, pick and mix, take a few things out, experiment with them, see if it works in your environment.

Because this is going back to lean, you mentioned lean, going back to the lean movement, you’ll probably know many of our listeners, audience will know that the Toyota production system was the precursor to the lean movement. And one of the grand figures in the TPS Toyota Production System, was Taiichi Ohno, who came up with some wonderful sayings, one of which is, “You should think for yourself and face your own difficulties. Don’t try to borrow wisdom.” So, in other words, how another organization has done something, that’s not gonna work for you. You have a different kind of organization, so you really do have to dig deep and look at the specifics of your situation and pick the various parts that you think apply to you and just experiment and see whether they work. So, it’s—

Ashley: Really more of an adaptive approach versus prescriptive, right? It has to be done a certain way because one organization succeeded at it that way.

Smalley: Yeah, no, and of course, it’s very tempting, but people are looking for the quick fix. There’s a fabulous cartoon, if anybody wants to look up a great cartoon, if you look up “Simple but Wrong, Complex but Right” it comes up with a great cartoon and you see people following—there’s a sign pointing in two directions of people, the masses are following the sign “simple but wrong,” because they’re looking for a quick fix.

Ashley: Mm-hmm.

Smalley: And what better than looking at how another organization’s done stuff and say, “You know, let’s do that.” It’s not a good idea, usually. [Laughter] So, you do have to be very, very critical, very selective.

Ashley: Well, these are systemic changes, they’re not quick fixes or just change this one thing of how you’re working and suddenly you’ll get different results. And one of those is, we think about specialties or specialization of what we do, but we’re also now thinking, it’s specialty roles, but it’s also how those things work across the life cycle development operations, product teams. So, individuals and teams’ abilities to work cross functionally is a much higher order skill than maybe we valued in the past.

Smalley: Yeah, look at the—I think we can kind of credit the DevOps community for something, but look at the agile community, how the concept of multi-functional, cross-functional product teams have emerged where you’ve got business analyst disciplines, development disciplines, testing disciplines all working together.

It’s interesting to think about the definition of done that they often apply as a concept that you’ll come across in agile and scrum, you know, “When are we done?” It often, in the scrum world, it ends with a potentially deployable increment of software, potentially deployable. The key word is potentially—it hasn’t been deployed yet. So, it’s just asking for an extension of that domain of the team to not stop when it’s deployable but actually deploy it, so start involving the DevOps kind of competencies as well. Then you could extend it further to the service area, because product owners should be aware that the kind of product that they’re building, that needs to be accessed by people, and service is the vehicle that gives users access to your product. You built a great software product, but it’s only through the vehicle of service that people get to it.

And is the product owner, is the product team looking as much at service as they should be? And I think that’s often not the case, and I’d certainly like to, in the role of bridge builder, like to encourage product teams to take a closer look at service and think about the kind of characteristics the service experience as well that they expect their users to have. So, you can see a service substrate going through all of the life cycle, really, alongside the software and infrastructure artifact.

Ashley: I’m curious, you mentioned design earlier and maybe this is what you’re referring to. I’m curious if design thinking or the design approach is something that also influenced your work on this module, the idea that you’re really, the outcome isn’t the car, the outcome is the experience that the customer, the user of that vehicle has and expects, you know, from whatever the product is that you’re creating. Did that influence this work, too?

Smalley: Yeah, two things, there—design thinking, we’ve referenced more at the start of the process, thinking about the kind of specifications requirements that people have. But towards the end, thinking about the service experience, and you’ll be familiar with the concept of service level agreements, which are often unfortunately formulated. We talk in terms of availability and performance and security and stuff like that—all very technical.

But how do the users feel about this? We’re slowly extending that domain service level agreement to include experience level agreements, looking at outcome and how people feel about their engagement with either their technology or the people behind the technology. So, again, that’s that human co-creational dimension that you see in high velocity IT, alongside the technology.

Ashley: Mm-hmm. Yeah, the SRE world, I don’t know if we’ve talked about that, but it has this idea of service level objectives, which is a little less formal and restrictive as what we think of contractual SLAs of, each team really, you know, defining what they’re trying to strive for, for the service that they’re trying to deliver and the experience that people have. So another area, SRE, is a great one.

Smalley: Yeah, no, that’s in there as well. SRE is certainly something that significantly contributes to more resilient operations, just like chaos engineering, another of the techniques that we reference. But speaking about agreements, certainly, you should measure stuff. Whether you—you know, the trouble is, once you put something into an agreement between two parties, people start to game the system. Things—I think it’s Hawthorn’s Law. It’s like as soon as you make something explicit, intrinsic motivation evaporates.

Ashley: Mm-hmm.

Smalley: Yet you do have to agree something with other parties. So, it’s really, it’s a delicate balance, you know, what’s gonna work in this situation. Also looking at the relationship that you have with your customers and other stakeholders—so, assessing what kind of relationship, what kind of agreements and measurements are appropriate for each particular situation.

Ashley: I was thinking about, too, when you mentioned resiliency, and previously, you were talking about sort of the iterative nature, doing work in much smaller increments—that also gives more flexibility for change. So that, you may have a feature turned into a story that might be delivered over multiple iterations in an agile process, and somewhere in that process, you may have part of it released, but you may move on to other things or shift what you’re actually doing. So, it’s a way of dealing with some of the dynamic, changing needs of the business.

Smalley: Yeah, it’s—we reference four characteristics of the approaches that you’ll find in these kind of organizations. We reference lean, agile, resilient, but also continuous, and I think that fits into this category.

You know, things are changing all the time, so it’s interesting when you’ve got these traditional discussions between business people and IT people. You’ve got IT people almost blaming business people for the fact that the world has changed, who it’s the kind of the core values that you have, the belief system you have, if you have the belief system that things are changing all the time and that’s just part of life, that’s a given, then you don’t resist as much. We certainly try to encourage people to embrace and enable change as well. We used to talk about change—management change control, which seems to be a bit defensive. When now, it’s just language, but even then, we like to talk about change enablement—how can you get changes done as quickly and safely as possible?

Ashley: Very interesting. Yeah, words do matter. What’s the state of the community, the ITIL community in the adoption of some of the principles around lean and agile and DevOps and SRE. Are most folks starting to become aware of or are they educating, are they practicing? Where would you say we are in this journey?

Smalley: Yeah, well, I forget who said it. Somebody said, “The future’s already here, it’s not just evenly distributed.”

Ashley: [Laughter] Yeah, that was Stephen Hawking or someone.

Smalley: Yeah, that’s right, yeah. You know, some people are doing it. I’m very pleased to see on LinkedIn or Twitter a response from an organization in the U.K. that says, “This high velocity IT stuff, this reflects the things that we are doing.” This is a guy on the joint DevOps and IT service management come together. I mean, that’s his area of work.

Ashley: Mm-hmm.

Smalley: It’ll depend on the kind of products and services that people, organizations provide are the digitally enabled? How digitally enabled are they? So, it is very diverse. Lots of people for whom this is all pretty new, one of the things we, one of the objectives we have for the book is to familiarize people who know the old way of working, you know, working in silos, that kind of stuff, and get them used to—make them more confident, confident to engage in discussions with their DevOps, with their SRE colleagues about digital to get the conversation going.

Ashley: It seems like that’s very important because, as things evolve, new things come into the picture—DevOps, et cetera, SRE. It’s really easy to be sort of overwhelmed of, “Now, what’s that, and how is that different and why should I care, or does it apply to me?” So, it seems that maybe taking that approach in this module of trying to bring that together from an ITIL perspective, from an operational perspective makes, maybe, those topics a little more approachable, a little easier to consume and understand?

Smalley: Yeah, and one of the things we advise people is to look at the five objectives that I mentioned, from valuable investments to a short conformance, and discover, identify where the weakest link is in the organization or in that part of the organization. Because if you look at the theory of constraints, another body of knowledge that we reference, you should always be working on the weakest link.

So, that helps you to focus on a particular part—don’t be overwhelmed. You can’t do all of this. You wouldn’t want to do all of this at once. Pick your weakest link, pick something that seems feasible that you can think, “Yeah, I can make an improvement, there,” and very much in the sentiment of continual improvement. Of course, one of the DevOps tenets, the third way of DevOps is continuous improvement—learning and improving all the time.

Little steps. I think that’s the way we’d like to encourage people to go—just take it step by step. Because after each step, you refer to the systemic nature of this kind of stuff. After each step, you’ve changed the system, so you’ve got to look around and see what’s changed and then plan the next step. So, moving from what I call confirmatory ways of working in the high velocity IT books, you know, when you’ve got pre-determined plans and deadlines and milestones, because you can more or less predict what’s going to happen, you confirm that—during execution, you confirm that what you predicted in the plan happened.

So, move—and we’re used to that in IT service management, predetermined process. So, moving from confirmatory ways of working to more exploratory ways of working, where you take things step by step—so, evolutionary. As Dave Snowden, who some people will know from the Cynefin framework, says—Dave authored a great piece about ethics for the book, by the way, but his core area is, he’s known from his complexity work—he says, “You’ve got to move to the adjacent possible in an organization.” So, sort of feel where the disposition of the organization is, in which direction are they moving naturally, and try and give them a nudge in that direction, zig-zagging towards, you know, whatever you want to achieve. That more—again, that’s that working in complex environments, reflecting the and respecting the unpredictable nature of the world we work in.

Ashley: You know, we’re kind of borrowing from a lot of disciplines talking about this and one that comes to mind, I believe, it’s quantum mechanics that just observing something changes.

Smalley: That’s it, yeah, the Heisenberg principle.

Ashley: The Heisenberg principle, thank you.

Smalley: Yeah, shine a light on it and it’s moved. You can either detect the velocity or the position, but not both at the same time.

Ashley: Mm-hmm. Very good. Well, this has been really fascinating—yeah, go ahead.

Smalley: I think Schrödinger’s cat came into it as well, didn’t he?

Ashley: [Laughter] Very good. Well, you know, I think what’s fascinating about your work and the contributor’s work on this is, I venture to guess there wasn’t a lot of discussion about tools and technologies, because you’re really thinking about the how of how we do work, how we work together, how this leads to the creation of software toward some co-created outcome.

Smalley: It’s very much the people dimension as well. You see that just talking—I mentioned ethics, for instance. Ethics—people want to do the right thing. That’s an aspiration that people have. They want to trust and be trusted in the workplace—psychological safety. I’m delighted that our industry is talking about this kind of stuff more often. Talking about things like—I remember at a conference, you know, the good old days when we actually went to conferences, a conference in, I think it was New Zealand, in Wellington, where somebody was talking about social anxiety as a rather introvert engineer.

Ashley: Mm-hmm.

Smalley: And it’s great, because you know, people empathize with that, and it’s great to trust and be trusted, fostering an environment where people can feel free to express themselves without fear for their position or reputation. If you build that kind of a foundation in your organization—you know, all the tools fit into place.

By giving people the confidence to—and the privilege, possibly a final thought, people just don’t work in IT. Some people say it, but you know, I’m sure some people don’t just work in IT, they have the privilege of contributing to the well-being and prosperity of digital service consumers, right down at the end of the chain. And I find that inspirational, thinking, you know, not just what happens in my silo, but at the end of the chain, you’re helping change somebody’s world. And that’s the kind of, that’s what I like to say about this book—it’s guidance that matters for people like us, who care.

Ashley: Mm-hmm. It’s definitely inspiring to know that you’re helping people, right, in the work that they do.

So, Mark Smalley, it’s been fascinating talking with you. I applaud you on the approach you took on this, a lot of great concepts that you’ve incorporated in the high velocity IT module, and I hope folks will check it out, because I think there’s some super valuable things. Again, changing the system is just by first observing it and I think just reading the module, checking out parts of it would be a step in that direction. So, appreciate your contribution, and it’s been great talking with you today.

Smalley: My pleasure, Mitch. Thank you very much, indeed.

Ashley: You bet.

November 19, 2020
DevOps Chat: Adopting Agile + DevOps in Large Orgs

In this DevOps Chat, Akshay Anand, ITSM product ambassador at AXELOS, and David Crouch, senior advisor at Beyond20, join Mitch Ashley to share best practices and learnings from introducing and adopting Agile and DevOps in large organizations. Akshay and David discuss overcoming change management challenges and obstacles to increase adoption.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · ITIL 4 – Introducing & Adopting Agile + DevOps in Large Organizations

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. I’m joined by Akshay Anand, who’s product ambassador with AXELOS, and David Crouch, who’s a senior advisor at Beyond20. Welcome. Good to have you on, good to be talking with you.

Akshay Anand: Thanks for having us.

David Crouch: Thank you.

Ashley: Great. Would you first both start out – let’s do a little bit of introduction just to introduce yourself, a little bit of what you do and a little bit about the company that you’re with, if you want to start Akshay.

Anand: Sure. Yeah, my pleasure. Thanks for having us, as I said. My name is Akshay Anand. I’m the product ambassador for ITIL, working for Axelos Global Best Practice. Axelos was a company that was formed about five years ago as a partnership between Her Majesty’s Government and a large private sector company called Capita. We like to think of ourselves as the custodians of best practice bodies of knowledge, not just ITIL. We also manage PRINCE2, which is our project management, MSP which is Managing Successful Programmes, which is our program management, and a few others besides.

Before joining Axelos I was a consultant for most of my career in the IT service management space across both the US and the UK. I spent a couple of years as the head of service management for Macmillan Publishing as well. And that’s me.

Ashley: Great. David?

Crouch: Hi. My name is David Crouch, affectionately called Lower Baltimore at the office because that’s where I live and where I’m coming to you from right now.

Ashley: [Laughs]

Crouch: It doesn’t come with a _____. I spent about 20 years at Johns Hopkins University and Hospital before coming to Beyond20. Finished my time there working in the IT solution center which was our service management center for excellence. At Beyond20 we are a company that focuses on digital transformation. At the core of it we really try to improve the way people and organizations work by looking at their digital transformations and looking at how to improve their IT service management processes. We do consulting work, we do training, and focusing on ITIL but also project management and Agile and DevOps and these other areas as well, and we also have a team of folks who implement IT service management tools.

Ashley: Excellent. Perfect timing for our topic today. So let’s kind of jump into that. We’re talking about Agile and DevOps and ways that that’s introduced into companies’ best practices, learnings from adopting or not [laughs] those different practices. Maybe we can start with how we introduce or you’ve seen companies introduce either Agile or DevOps or both into organizations and kind of thinking probably larger organizations where there’s more change management involved. I imagine that’s a lot of work you get into, David. Is that correct?

Crouch: It is. You know, we see a lot of organizations who know a little bit about DevOps and a little bit about Agile but haven’t really adopted an Agile mindset and don’t really have the full understanding of what organizational structure can really support DevOps, and yet they need these things to really support a digital transformation. So typically we’ll start with doing some sort of assessment to see where they are now to see what pain points they have right now, and then try to figure out, okay, does it make sense to introduce Agile, where does it make sense to introduce DevOps, and how quickly can that be done or how gradually do we need to introduce these concepts?

Ashley: How about you, Akshay? I’m sure you worked with plenty of organizations that have introduced this and gone through that process.

Anand: Yeah. I’ve actually seen broadly two major patterns. The first being where the organization transformation is driven top-down, so it’s usually a board of directors or whatever governance structure says, “Look, you know, this is the vision of what we want the company to be,” and the senior-most leadership team says, “Well, in order to be able to do that we need to be able to iterate faster, we need to be able to have much more of a focus on pushing out digital products and services,” and that change then percolates through the rest of the organization, so very much a top-down thing. The other major pattern that I’ve seen and experienced is where you might have a small team who with the help of let’s just say a more enlightened manager is given the freedom to start to experiment and innovate and change ways of working while sort of at the same time remaining compliant with the rest of the organization’s policies and what have you, and they’re able to demonstrate improvements in either efficiency, productivity, experience, whatever it might be, to the point where the rest of the organization says, “Okay, so what are these guys doing and what can we learn from that and how can we start to pick up some of those changes ourselves?”

So in a way at that point, it’s a branch, that sort of new ways of working or new principles of working start to diffuse horizontally, so there are other sorts of teams, engineering teams, operational teams, et cetera, who start to think and work in those ways. Or it could be that the stories of that change percolate upwards, where the middle management or the senior management say, “This is interesting. Are other organizations doing something like this? Would it benefit us to roll this out a bit wider and give it the sort of support and evangelism and investment that we need in order to create a larger change?” So that’s the sort of branch, but broadly it’s two parts—top-down, bottom-up.

Ashley: You know, I think one of the biggest challenges with introducing any kind of fundamental change like Agile or DevOps is sort of crossing that chasm between saying we’re doing it and kind of really truly embracing the spirit or the concepts or the culture of it. Have you found that also to be true?

Anand: Well, yes there’s a difference. The way I reconcile this difference perhaps is in the following way and David probably has a completely different experience from his vantage point but for me one of the biggest challenges that organizations face or at least let’s say practitioners face, and then I’ll come to organizations—one of the things that I think practitioners are challenged by is in a way thinking that everybody understands things and just gets it. Everyone understands why we have to be Agile. Everyone understands why DevOps is important. And the truth of the matter is not a lot of people understand that and even if they do understand the words they don’t necessarily understand the implications to the rest of the organization.

So there is a little bit of this need to manage upwards, need to manage outwards to be able to champion the need for that change, the need for these new ways of working. The other thing which I think organizations and practitioners are challenged by is understanding where these new ways of working will succeed and where they would not succeed, and this is some of the things that we do actually talk about within the sort of ITIL 4 library of guidance that digital transformation or these new ways of working are really important, yes, but in a certain context they can be a hindrance rather than a boom, and organizations need to understand where these sorts of things can work. If the work that’s being done is highly predictable or has very long cycles of work and feedback then perhaps trying to break it down might only go so far, but if you try to overengineer or impose an Agile way of working you might actually end up doing more harm than good, even though you’re starting out with good intentions.

Certain things, to put it bluntly, don’t care how the work is being done. Once you start reaching the level of governance or supplier management or whatever it might be, in a way yes the CIOs today might say, “DevOps is really important, Agile is really important, et cetera,” but if you press them about what exactly is being done – look, I just say based on my conversations with other leaders I understand this is important, but the exact mechanics of how we’re actually going to execute on this I leave to the team who’s actually doing the work. So you’ve got to understand that change is difficult. The further up you go in an organization the harder it is going to be to try to convince somebody about the nitty-gritties that need to change, and you’ve got to be able to understand your audience, understand what they need to hear, understand how to convince them, and that aspect of communication is one of the critical components of organizational change management. It’s one of the places where I see the failure of organizational change management most commonly occur.

Ashley: Interesting. How about you, David? Share some of your experiences.

Crouch: You know, I think some of the more challenging but also more interesting from the consultant point of view situations are dealing with some companies that have been around for 80, 100, 150 years, and then I think folks pretty much around the globe would know some of these companies and they’re very mature in some respects. They’ve built their brand over time. But then when they start to suddenly – you know, some of them suddenly wake up and realize, “Oh, wait a second. We have gotten out of touch with what our customers really need, our external customers really need and what they want, and there are competitors that we never even dreamed of before that are entering into our space.”

They suddenly wake up and realize not only do we need new products and new services but we also need to work in a different way to produce those because customers change their mind a lot, customers are fickle, and I don’t mean that in a bad way. We want to understand what our customers need. And then the challenge becomes, okay, well if we haven’t been doing this right now it’s necessary but not sufficient just to provide training in these areas. Training goes so far. That’s very useful, but then also where are we going to have an area where doing something like Agile software development really makes sense?

I worked with an organization where any of what are often referred to as systems of record, so these are internal systems that keep the company running, their software team was actually doing a fairly good job because they worked in a relatively Agile way. It wasn’t 100 percent of what you would describe as Agile, but it was pretty darn good. And yet they would often run into roadblocks when they got into the more, for lack of a better term, traditional change management or as we call it these days change engagement processes where they were actually analyzing risk and managing risk all throughout the process because they were doing an Agile approach, and yet sometimes they would have this long delay at the end of the process when they got to their change control board in that company.

On the other hand, that company almost overnight experienced some significant financial losses and significant layoffs and they very quickly needed to develop some, what we call, systems of engagement, systems and tools that their third-party paying customers would use and would purchase, and in that case, the organization bypassed their internal IT entirely and just went to a third party because the third party really was already doing some version of DevOps in that case for years. Then the question becomes does their existing IT shop still have a reason to be? The answer, in that case, was yes, but it becomes very difficult because if you tried to apply that to the entire organization, particularly overnight, I don’t think it would’ve worked very well.

Ashley: Oftentimes in those situations, you also see people _____ project if it is an internal group just to try to isolate it and minimize the overall organizational reaction. Some people call them the corporate antibodies that tend to kick out and respond to change.

Anand: SIt’s interesting you say that, Mitch. What I’ve also seen though is that can also work but it has to be done very carefully because – who was it, which book was it? I think Geoffrey Moore – was it Geoffrey Moore? Yeah, I think Geoffrey Moore wrote an entire book about this phenomenon, a book called “Zone to Win,” and what he was talking about in that book with numerous examples, which I’m sure we’ve all experienced, is that skunkworks, that innovation lab does really well as the innovation lab, but the moment the organization says, “Okay, how do we now scale this new innovative feature, this new innovative product and industrialize it to the point where we can offer it to our thousands, millions of customers,” that’s when it falls down because you’re changing the constraints within which a product exists, if you will. It no longer exists as a small experiment measured in terms of success as an experiment.

It’s now got to be able to stand up to the measures of being like this industrialized product or service. So if you’re moving the yardsticks, is your product capable of actually bridging that—moving across—I don’t want to use the word bridging the chasm—is the product actually capable of moving across into that industrialized state? And what we’ve also seen through some of the research that went into ITIL 4 as well is a lot of organizations failed to make that bridge between that innovation lab and the industrialized operation.

Ashley: I appreciate you sharing that too. It could happen very well to the external group that gets formed as well. How do you reintegrate that, repatriate it back into the organization?

Crouch: And there’s a Harvard professor that famously kind of describes some digital transformation experiments as kind of like attaching a speedboat to an aircraft carrier. You know, they move at different speeds, and although the speed may go really fast, try to get that to translate into the aircraft carrier. It’s probably not going to happen. So it becomes—you know, the challenge is do we do a proof of concept, which sounds like an experiment to me, but if we do that can we really translate that into larger organizational success? And hard to say to come up with a definitive answer, but for larger organizations I think that what I’ve seen is that it’s been very difficult for them to do that successfully, so they have to find other ways of doing it.

Ashley: There’s a lot of things you can look at. You can look at sort of historical what’s worked, what’s failed in the past, you can look at—I call flow—what is the momentum of the organization? Are we a metrics, are we a finance, are we—what are decisions driven by? One of the things that can also help with that is also alignment. It’s why are you introducing Agile? Other than this being an IT fad, which it’s not just that, but it could be just for that reason.

Usually, it’s not a great reason to introduce it. You’ve got to have some real true business drivers like your example, Akshay, of we’ve got to respond to these things in market, right? The customers’ expectations have changed. That creates a sense of urgency but also purpose, like what are we trying to do differently and why and then how do we apply this?

Anand: There’s an additional wrinkle or complication, if you will, for publicly-listed companies as well where they’ve got to report certain metrics, and if you look at any company’s quarterly filings or annual filings where they talk about the year ahead or the quarter ahead, they are using certain types of metrics to communicate their direction and their results to their shareholders, to the market, and you might say, “Look, these measures are no longer relevant for what we’re trying to do or for where we’re trying to go,” but then what does that do to the company’s confidence as a shareholder? The example I cite is when the New York Times tried to move to the digital subscription. You can’t translate print subscribers into digital subscribers or engagement.

How do you measure the success of the digital engagement because you’re not delivering hard copy newspapers anymore? But the investors were used to seeing those sort of subscriber accounts and subscriber churn and all these sorts of things as forward-looking guidance. So there’s an additional complication from a governance and a reporting mechanism, especially if you’re a publicly listed company, and that’s why people like David have so much fun going into these companies trying to help them figure out, well, it’s not just about changing the ways we’re working; how do we educate our peers, how do we educate our managers, how do we educate our suppliers, how do we educate our consumers, how do we educate our shareholders? There’s all these different stakeholders. It’s not just about changing the way your software development is done. It has massive ripple effects across the ecosystem.

Crouch: Well, and what’s really interesting about like New York Times is that they were still successful with their print publication, one of the few, when they began their digital transformation. So you have a tremendous amount of courage to be able to say as the leader, “You know what? We’re successful now but this is not going to last. We can see it in the marketplace. So what we actually need to do is intentionally set up a parallel operating model and say we’re going to move in this new direction.”

And that means that that’s in their case going to siphon away, intentionally siphon away over time the way we do business now and it’s probably going to hurt in the meantime, and we’ll use any of the profits from our existing model to move over to this new model. But gosh, if you’re an investor you have to be pretty nervous about that unless you’re really in it for the long term and you say, “You know what? They’ve seen this and other companies have tried this; how do I know that New York Times is going to be successful when some of their peer publications have not been when they try to do this and for a variety of factors?” It seemed to work for them but it’s pretty daunting.

Ashley: That’s what I would call the disrupt yourself before you’re disrupted model, right? Because usually it’s much more painful when you’re reacting to someone else who’s coming in and taking market share or whatever. That’s a really good example too of in the print media going into digital, it’s not the same product, it’s not the same consumers, it’s not the same behavior. The market really has changed, or maybe you’re just really going after a different market who would never now buy print but they would just use that example.

So a lot of it can be driven by those things that we’ve answered about strategy or understanding of the market or shift’s that are occurring and tie those reasons as part of why we need to create software faster or why we need to create it in waves of some smaller increments to be able to respond to really rapid shifts or experiment in market. That’s another great reason to do that.

Anand: Absolutely.

Ashley: Well, talk a little bit about—you mentioned the speedboat. I can just imagine it tied to the aircraft carrier, kind of sort of like the fly tied to the string, right? How do you start to introduce speed into a larger organization that has a lot of momentum around the way they’ve been doing things that’s worked for them probably very successfully? How do you start introducing something like speed to say, “This is super-critical and here’s how we’ve got to operate now?”

Crouch: I think it starts with trying to understand what they’re primarily trying to do. Where does having more speed make the most sense? So it could be we’re in a consumer marketplace and the customers are changing their minds a lot and there may be a way to develop something more quickly to respond to that need or in the perfect world to actually kind of predict and shape that demand for the great digital masters. On the other hand, some companies may say, “Well, maybe we’re not in a strictly business-to-consumer marketplace but we need to increase operational efficiencies in some areas,” and so maybe speed is more important there. And then for a few companies out there it may be both, right?

It may be if we increase operational efficiencies on the inside of the company we can also drive the outside third party customer, and that’s no easy way to do that, to figure out where speed is going to be appropriate and where doing things quicker might actually get in the way in some cases. Akshay, I don’t know what your experiences have been there.

Anand: I mean, look, there’s a lot of great organizational change, organization design, literature out there for people who want to read up more about this sort of thing. The Satir change model or Kotter’s Seven Steps or whatever else it might be. In my experience, one of the first steps I’ve seen in any successful change is – to use Kotter’s language – creating a sense of urgency. I guess this is something I remember from my time living in the US. Wasn’t there this sort of tagline that the first step to recovery is admitting you have a problem or something along those lines, right? So it’s kind of like that.

The first step towards creating a change is to acknowledge that you need to change, because once everyone acknowledges that you need to change you can start to think about, well, what sort of change do we want to have? And this has to be a highly collaborative effort. It’s not just your CXOs locking themselves in a conference room at a resort for two days and whiteboarding this out. This has to be a truly collaborative exercise across the entire organization. There may need to be some constraints that are in place, and what I’ve typically seen is a board of directors might say, “Look, this is where we want to be five years from now,” not necessarily saying how that needs to be achieved but saying this is where we want to be.

That in combination with creating that sense of urgency says, “Look, if we need to hit this sort of a target we need to be able to develop software faster or close out outages quicker or have a more Agile procurement process or whatever else it might be,” and that’s when you start to identify these sort of strategic and tactical initiatives. Because you’re working collaboratively you’re dispersing that cognitive effort, if you will. So it’s not just somebody from one particular vantage point saying, “As a CFO I think we are giving away too much money so we’re going to be cost-cutting only.” That’s a singular perspective. But once you distribute perspective you can then say, “Right, if we are supposed to meet this we have to change here, we have to change there, we have to modify that,” and so on.

For me that is the essential first two steps; create that sense of urgency and then distribute the cognition of what needs to change. Create that collaborative series of committees, councils, call it what you will, that will help you identify in different areas what needs to change, and then you start investing to execute on that series of tactical initiatives or programs of change.

Ashley: When I first learned about change management—David, maybe you can comment on this—we used the phrase “the burning platform.” What’s the burning platform that we’re on that’s forcing us to change or really compelling us to make a change? It can be as dangerous as are we going to exist but also it could be here’s why a two- or three-year strategy makes sense. Let’s not just communicate this strategy; let’s communicate the why.

What’s changing? What evidence do we have of this? What do we want to get ahead of or prevent ourselves from experiencing? Have you seen that as a successful strategy for helping create that burning platform or at least the sense of it?

Crouch: I think so. I mean I think the top level of support from the leadership is absolutely critical, but when it comes to defining the problem getting down to as specific as you possibly can. It’s not just a matter of we’re not getting new products out to customers quickly enough or it’s not just a matter of we’re not implementing enough infrastructure changes within a certain period of time. It’s a matter of exactly what about that isn’t going well and why would improving that be made better? In some cases it’s obvious. In some cases, for example, it’s not so obvious, and when people think of Agile and DevOps one of the first things that comes to mind is speed, we’re going to get more speed.

That’s an important part of it. It’s not the only reason why you might use some of those techniques. To use a simple example, if I need to be at the theater for a show—not these days—but if I have to be there at 7:00 PM and I only live 15 minutes away, driving faster won’t necessarily improve my results. I get there—it still doesn’t start until 7:00 PM. If I get there at 6:00 PM I guess I get a good parking spot. So speed is just one element, but think about with Agile doing things in smaller iterations, controlling the risk, controlling the scope. All of these are considerations in addition to just speed.

Ashley: What –

Anand: And the other thing that I think the research shows us—sorry, I didn’t mean to –

Ashley: No, no. Go right ahead, Akshay.

Anand: I was going to say one of the other things that our research has shown us as we’ve been working on ITIL 4 and other bits and pieces, even frameworks like managing successful programs and so on, is organizations need to figure out the right duration of their strategy cycle. Now if your company is a two-person company then maybe your strategy cycle is measured in days or weeks, all the way up to if you’re the government of India and you’re trying to manage—not manage, but govern one-point-how-many-ever billion people then your strategy cycle is likely to be measured in years, if not decades. Well, hopefully not decades. So I think the other aspect that we’ve seen, at least in typical organizations, strategy cycles have gone from being sort of this thing that happened every five years to maybe things that are happening every three years because the world’s changing too fast for a five-year cycle to make sense.

We may see a point where three-year cycles are deemed insufficient and we need to move to two-year or one-year cycles. But that’s the other trend that we’re also seeing, that strategy cycles themselves are reducing.

Crouch: I’ve seen that a little with managed service providers, for some of the managed service providers. Even one year seems to be an awfully long time for some of them, you know? So there’s this kind of blend between are we talking about strategy or tactics here, but I agree; the timeline is becoming shorter and shorter it seems.

Ashley: It certainly has, and of course our current COVID situation, I’ve seen some resource. I know some of the sources of this, but some have said, “We’ve accelerated as much as six years in our digital transformation strategies in the last six months.” Probably not everybody has, I imagine. Well, this has been great talking with you both. I know you mentioned, Akshay, Geoffrey Moore’s book “Zone to Win” as a great resource. Any other resources on introducing Agile and DevOps or on change management that you guys can think of might suggest?

Anand: Well, I think I would be very remiss if I didn’t actually mention ITIL 4, which is the product for which I’m an ambassador.

Ashley: That was a setup question.

[Laughter]

Anand: Easy question, though. So look, there are a couple of really good books in ITIL 4 which talk about this. Two books in particular that I’d like to highlight. The first is “High Velocity IT” and the second is “Digital and IT Strategy.” “Digital and IT Strategy” actually does refer back to some of the content in “High Velocity IT.” “High Velocity IT” is more focused on the tactics and operations aspect of introducing these new ways of working and managing the changes and the implications therein to the rest of the organization. “Digital and IT Strategy” is more about the governance and strategy and the interface to tactics, so it’s about how do you determine what’s the appropriate business model, how do you create a change in your business model and from that create a change in your operating model, from that figure out where Agile and DevOps make sense and where it doesn’t make sense and so on.

So it’s very much the sort of top-down but the leader’s perspective of things, whereas “High Velocity IT” is the practitioner’s perspective of things. I think those two would definitely be really good. I’d also plug a couple of books like “Team of Teams” I think is really an interesting read, talking about how especially in an organization like the US Army, which you would typically think is very large and flexible and so on, how they were able to create that kind of a change, not necessarily with software development but around ways of working from across multiple teams, across multiple time zones, so that’s also a really good book to check out.

Ashley: Yeah, I’ve not read that book but I’ve heard it’s good. I think it’s by Stanley McChrystal, right? General McChrystal?

Anand: That’s right.

Ashley: Great author. I think he uses his whole military experiences, examples of that, so I’ve heard him speak about it. How about you, David? Any suggestions?

Crouch: I would just say that, you know, as one of the authors of the ITIL “Digital and IT Strategy” book I’m going to put in a plug for that. I’m just a little bit biased, even though it probably took several years off of my lifespan to help write that—I’m kidding. But no, that’s really talking more about the strategy side of things. I recall reading an article years ago as part of one of his classic books. Michael Porter talked about IT is not strategic, and I struggle with that. I agreed kind of at the time and now I don’t know, and I think if IT is now strategic in this era of digital transformation it really comes down to things like high velocity IT to DevOps to Agile to some of the techniques that we talk about in the “Digital and IT Strategy” book and “High Velocity IT.” You know, I would suggest reading that.

Anand: There’s probably a couple of other plugs to make just before we go, sorry.

Ashley: You bet.

Anand: For those who want to read a little bit deeper into some of the more cutting-edge, I would say, thought leaders, read up on Simon Wardley, Wardley mapping and his whole strategy cycle stuff. He publishes that on his blog. There’s tons and tons of material on his blog, which I think he started condensing to a series of medium articles. But there’s also YouTube talks that he does. Amazing stuff. And the second is Dave Snowden and the Cynefin framework. It’s getting a lot of attention in the Agile space especially, but it’s a decision-making framework. It’s a sense-making and a decision-making framework and it has applications from business strategy to project management and everything in between, and I think that’s another –

Ashley: Excellent.

Anand: – at the moment cutting edge but hopefully a soon mass-market approach.

Ashley: Oh, those are some fantastic resources. And maybe a parting thought for all of us is I don’t know if IT is strategic but I’m pretty sure software is strategic these days that’s driving – really fueling our digital transformation.

Anand: Absolutely.

Ashley: So a topic for another conversation. Well, thank you, gentlemen, Akshay Anand, who’s product ambassador of Axelos, and David Crouch, senior advisor Beyond20. Thank you so much for sharing your experience and your thoughts on this topic. I’m sure it’s been really helpful.

Anand: Thanks for having us, and to the audience, you can find me on Twitter @bloreboy if you care to follow me, and I’d love to hear some feedback either through Mitch or directly, however you’d like. I’d love to know what you thought about what we were talking about today.

Ashley: Wonderful. Happy to do that. And I’ll pass that along if we do. David, do you want to share any contact information?

Crouch: Yeah, same here. I’m on LinkedIn. A slightly younger, bow-tied version of myself is on LinkedIn. Feel free to connect with me. Certainly visit our blog at Beyond20. We’re always writing articles, trying to grapple with some of these issues, changing our mind some of the time, but you find a lot of what I write there.

Ashley: Excellent. Well, we’ll look forward to talking with you both again soon. Take care. Have a great day.

Anand: Thank you.

Ashley: You’ve listened to another DevOps Chat podcast. This is Mitch Ashley thanking everyone for joining us today. Be safe, be careful out there.

November 18, 2020
ITIL 4 in the Age of Agile and DevOps, With Axelos

ITIL is well-established as the process, certification and information resource library for service management across many IT organizations globally. With the recent updates to ITIL 4, influences from Agile and DevOps are helping ITIL to expand and adapt to changes in ways to create software and build operations into the delivery process.

In this DevOps Chat, Akshay Anand, product ambassador with AXELOS Global Best Practice, and Jon Stevens-Hall, principal product manager at BMC Software, join Accelerated Strategies Group CEO Mitch Ashley to discuss the new innovations in ITIL 4. As major contributors to ITIL 4, Akshay and Jon share the approach they took with ITIL 4, incorporating ideas from the world of Agile and DevOps.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · ITIL 4 in the Age of Agile and Devops, Axelos

Transcript

Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. I have the great pleasure of being joined by a couple of really cool gentlemen here with a great topic I’m excited to talk with you about.

The first is Akshay Anand, who is Product Ambassador to AXELOS. Also, we have with us Jon Stevens-Hall, a Principal Product Manager with BMC Software. Welcome, gentlemen.

Akshay Anand: Thanks for having us.

Ashley: Yeah, I’m excited to talk with you about this. We’re gonna jump into ITIL, ITIL 4, and some of the work that you’ve been contributing to that, but first, why don’t we start out—Jon, would you introduce yourself, tell us a little bit about what you do and a little bit about BMC Software? I’m sure many people know that, but just for the folks who don’t?

Jon Stevens-Hall: Sure. So, I’m the Principal Product Manager for BMC’s enterprise ITSM suite, which, you know, it comes from the Remedy heritage family of products, now titled BMC Helix ITSM, and I’ve been around service management for over 20 years now. I sort of walked out of university into my first job in the late ‘90s, implementing systems for ITIL 2 over at what became Yell Group.

And so, I’ve been around service management and ITSM for all that time, and obviously, my primary role at BMC is producing and creating software and tools, but also, we always try to be active members of the ITSM community in general, which is what led me on a personal basis to being one of the contributors or ITIL 4.

Ashley: Mm-hmm. Awesome, excellent. And Akshay, how about you?

Anand: Oh, so, I joined AXELOS about four years ago. AXELOS, for those who don’t know, is a joint venture between Her Majesty’s Government and a private sector company called Capita. We like to see ourselves as the custodians of the IP, of not only ITIL, but other best practice arrangements like PRINCE2, which is about project management or MSP which is about program management. I’m Product Ambassador, so like the product evangelist for ITSM and ITIL in general. My background is mostly around consulting in the IT Service Management, consulting and advisory. I’ve also been Head of Service Management for Macmillan Publishing for a couple of years. And yeah, like I said, I joined AXELOS four years ago and it’s been a blast.

Ashley: Excellent, excellent. Well, I’m sure that consulting, and also Jon, your experience with BMC gives you some real-world perspective on ITIL and ITIL 4.

Well, talk about the publications that you’ve contributed to the IP. I think the Create, Deliver, and Support around ITIL 4 is one of the areas that you both contributed. Do you wanna jump in first, Akshay?

Anand: Sure. So, Create, Deliver, and Support is one of four books in a learning stream that we call Managing Professional. All the books in that sort of learning stream are oriented toward managers or professionals who are either managing or designing systems, service management systems. Create, Deliver, and Support in particular talks about things like employee engagement and professionalism, a lot of the commonly used tools needed to create, deliver, and support services, things like value streams, value stream mapping, how to apply value streams within the context of ITIL 4, how to manage suppliers.

So, it’s a very wide-ranging book, but it goes into a lot of detail about very, very specific techniques. Two of those techniques were actually authored by Jon, and one was around tickets and the use of tickets or the misuse of tickets and what to avoid, and the other was actually around swarming, and how swarming can be a good model to use within service management organizations, a technique that can be used to foster collaboration between development and engineering teams and frontline support teams.

Ashley: Interesting. Jon, love to hear about that. I know, just to share you a bias about tickets, I think everybody’s impression of IT is, you can’t talk to IT unless you complete a ticket. Well, maybe that’s taking it a little bit far, right? [Laughter]

Stevens-Hall: No, that’s definitely a true impression. I mean, one of the things I’ve spent much of the last six years doing is really, I’m a bit of a method actor, I’ve been very immersed in the DevOps community. And almost, I joke that I went to my first DevOps conference by accident because I signed up for something called Configuration Management Camp thinking, you know, ITSM, CMDB, configuration management. I soon learned very quickly we were talking more Puppet and Chef and Ansible.

Anyway, and it was fantastic, because it’s opened up a door into a world that has evolved somewhat differently. And there were many aspects of culture that I think IT Service Management was not understanding very well, which was one of the reasons I was very keen to bring my kind of cross-domain perspective to ITIL 4, because I think a lot of us felt ITIL—bear in mind that version 3 originated before DevOps, it needed a big refresh. And that example of tickets absolutely is true. I mean, people sort of see this negative perception that, you know, to get infrastructure, we used to have to raise a ticket and wait three weeks—now, we can log onto a software-defined infrastructure tool and we can create it right away and it’s all delivered on cloud.

And absolutely, I mean, one of the—you know, we sometimes, I think the heritage of IT has created these impressions not in a vacuum. You know, they’re not false impressions sometimes. But I mean, ultimately, what is it? You know, a ticket is just a data record that represents a piece of work, and a lot of the work we’ve done around developing systems at BMC has been to try and sort of take away this old way of very sort of skeuomorphically presenting a form to somebody who did all the fields on that piece of work, you know, all the things about that.

And I wrote a blog on this a year or two ago where I likened it to an old taxi booking service I used to use in California if I flew to work, where you had to kind of fill in about three pages—box, box, box, box, box. All those things are important pieces, probably, for the taxi operator, but you know, this is the world where I can open up my smartphone and press one button and get a taxi, you know? I don’t have to care about all that stuff.

Likewise, I think where we’ve had to move on is to sort of—you know, what we’ve had to learn as a community on the service management side and maybe, you know, have to convey more to the DevOps world is that, you know, we all record units of work, we just don’t have to necessarily present it in such a complicated way. And we can, you know, we should focus on the actual flows and the people and not this sort of big-ticket data problem. You know, we probably still want to know that you’re deploying infrastructure, but we don’t have to make you fill out a great big form to do it.

Ashley: Well, and software engineers kinda think in terms of Kanban cards and stories and epics, you know, applying agile kind of things. Have some of those concepts, then, creeped into the idea around tickets within ITIL 4? Is there some intersection of those ideas at all?

Stevens-Hall: Yeah, I mean, [Cross talk]—go ahead, Akshay.

Anand: Oh, I was gonna say, in general, I think we definitely had a lot of inspiration across the entire ITIL 4 contributing team, whether architects, authors, reviewers, et cetera. There were definitely a lot of people who pulled on a lot of lessons learned from the world of agile software development, of DevOps, and of lean, and we tried to incorporate a lot of that thinking into ITIL 4.

It may have been there in ITIL version 3, but it possibly wasn’t at the forefront, it wasn’t embedded at the heart of the framework. But what we did with ITIL 4 was to say, “Look, these are important, you know? We need to be able to reinforce continual improvement, we need to be able to reinforce elimination of wasteful work. We need to reinforce, you know, that we’re working in complex environments.” Especially as we’re working in environments which are, at this level of service management, is a mix of human and non-human interactions, and that is inherently complex and we need to reinforce things like iterative progression and the role of feedback in such a system and so on.

So, we brought a lot of those lessons in. Whether that was sort of very foundational models that we used in subsequent publications to present and frame certain arguments or whether that was highlighting specific techniques like Kanban or—I’m drawing a black, sorry, I haven’t had enough coffee. But highlighting specific techniques like Kanban and others in other publications.

So, there’s another publication called High Velocity IT, and coincidentally, Jon was a contributor to that as well. And in that, we talk about how certain techniques can be used to meet certain objectives in high-velocity service organizations like fast development or creating faster feedback loops at the service level. Sure, we have it at a technical level, but we also need to be able to mirror that or replicate that in some shape or fashion at the service level. So, we definitely try to bring in as much of that foundational thinking from lean and agile and other best practices or emerging practices and bake that into ITIL 4.

But for the specifics on how we did that is, with queueing and swarming and so on, that’s a lot of the stuff that Jon helped author.

Stevens-Hall: Yeah, and I think one of the big—I mean, taking a step back from just the concept, you know, the rethinking about things like tickets, one of the things I’m very happy, one of the reasons I was happy to get involved with ITIL 4 was that it’s shifted a lot of thinking, and again, learning from DevOps and lean in particular and making us think much more about value than process and control. And, of course, that’s been a challenge for us to position that we’re thinking that way, but ultimately, I want to sort of talk about the positive things.

You know, I talked to developers in the DevOps world who see huge value in people taking some of the leg work off their workload, you know? So, we all know that those developers are delivering the most value if they’re innovating the developing. If we can bring service management techniques, better align it with DevOps so that any of the support tickets that are coming the developer’s way, you know, the issues that inevitably come up when the—and especially as DevOps in enterprises goes from sort of small little startup exercises to big and normal and widespread, suddenly, those developers often find themselves doing half of their work resolving issues that have come in, you know, come in from the monitoring or from people. And one thing that service management has done extremely well for a long time is help to kind of industrialize and produce high quality support channels.

So, what we are in a great position to do is actually, you know, with that focus on value, you know, in a lean culture, if it’s not valuable, why the hell are we doing it, by kind of moving on from some of the old concepts, but taking all the things we’ve done very well and working with the DevOps community with a much better understanding of the way they’ve learned, you know, drawing up their lessons, but at the same time, pushing the fact that there is huge value that we can deliver to help them do what they do, then, you know, suddenly, this IT service management and the ITIL framework, I’m in a much better position to help those things. And I’m seeing people who are very skeptical before now saying, “Actually, this is how we unlocked the organization’s confidence and give them that ability to go faster with DevOps.”

Ashley: You know, it’s really heartening to hear that’s the approach that you both have taken with this, because it seems, you know, there’s sort of the impression of process for process’ sake where, no matter what we’re talking about, and of course, you know, many folks that are in this highly iterative—right, there’s process in the way we create software that way.

But if the service management and the software creation processes can better mesh together, right, so that it’s not viewed as an impedance when someone gets a ticket, right, and has to conform to an old process—but it flows with how we develop software and release the change that might go through that. I think maybe that’s that continuity that we start to see between ITIL and DevOps and lean and agile to help everybody see how it can benefit what we’re doing.

Anand: I remember a conversation with a gentleman called Greg Sanka, who is the CIO of Oregon State Administrative Services. This is a conversation maybe last summer, and we were talking about the guiding principles that we introduced in ITIL 4. In particular, we talked about focus on value. As a principle, we need to be able to focus on value—Jon has just referred to that, as well.

But what we are talking about is, nobody—very few teams are consistently sure on what value means and how value changes from person to person. So, of course, there’s value for customers who are using the software and the applications that we’re deploying. But there’s also value for your risk officer, there’s value for your supplier, there’s value for your CFO.

Now, a lot of these people aren’t involved in the actual use of the software day to day, they’re not involved in the development of the software, et cetera, but we’ve got to be able to architect the solutions, the service management wraparound, et cetera, et cetera to be able to create that value.

Now, part of the reason why sometimes IT service management and ticketing that you were mentioning has a bad reputation is, that’s how that assurance was created at a certain point in time.

Ashley: Mm-hmm.

Anand: But we now have to go back and say—look, because technology has changed, we’ve removed certain risks that we were trying to mitigate 10 years ago, but we’ve introduced new risks that we didn’t have 10 years ago.

Ashley: Mm-hmm.

Anand: So, what does that assurance now need to look like? How do we re-architect our systems to accomplish that same assurance? How do we introduce more automation, remove the toil, et cetera, while providing—in order to provide that assurance?

Stevens-Hall: Yeah, it’s almost like the ticket was almost the kind of, the manifestation of the internal memo in a digital system, you know, the old paper memo. I mean, I’m old enough to remember those envelopes where you crossed out the old address and put the next one on and it went around the internal mail system.

But, you know, it is important to remember that these processes actually helped us to move that kind of customer support in the technical world from adhocracy and Post-it notes to a proper, robust, scalable solution. That moved us on to self-service, to knowledge management, to properly established professional ways of handling and resolving issues that are now extremely valuable when DevOps goes big in organizations and it hits the mainstream and it hits a large volume of users and starts having to deal with support issues.

The more staff we can use these established service management practices—albeit modernized, heavily rethought, you know, focused much more on value than process for process’ sake? The more we can do that, the better—and this is proving itself over and over again with our customers—the better it actually helps us to enable DevOps to go, you know, to accelerate, to deliver that huge value that we know it can create.

Ashley: Well, it seems like the, some of the process and the auditability, if you want to think about the benefits of why you have processes, right, so consistency and reaction to issues and resolving them—those are some things that can actually benefit people that are working in a philosophy environment, because sometimes that can be a bit chaotic, or it’s just extremely fast. Obviously, things are happening very quickly.

And then when you need to start interfacing with other parts of the organization, whether it’s, you know, do we do vulnerability scanning for the security group, you know, how are we handling resolution time for production issues? That’s where that intersection can really be helpful, and some of those well-defined processes and ways of measuring value from an operational standpoint, development teams don’t have to do that, because you’ve already done that through, or are in the process, right?

Stevens-Hall: Yeah, and also one of the good things in ITIL 4 that we’ve been able to do is actually learn very much hands-on from DevOps. So, one of the big subject areas that’s really growing in interest on both sides, as it were—and I kept on using the word “sides,” but you know where I’m coming from—is this idea of using a more swarming technique than kind of the traditional structures.

And so, this is a really good example because, you know, very traditionally, service management has kind of operated a three-tier support structure where you’ll kind of have a front line at tier one, which we’ll try and probably mostly successfully fix most minor things, you know, then if they can’t, they’ll escalate to a more expert level, tier two. You know, back in the day, that would’ve been the service desk agency who then did their Microsoft certificates, for example, and became a slightly more specialist team.

And then things that can’t be solved there, you know, 5, 10 percent or whatever would end up with tier three teams who are more likely to be developers, specialists. There’s nothing wrong with having those teams, but what is wrong is a couple of things. You know, the first is that issues can often take a long time to get to that team, because what we’re effectively doing is putting queues in the way, you know, so it goes into the tier two queue. Someone then has X hours or days to pick it up, so it sits in that queue. It then goes to tier three and sits in a queue, and by the time it’s got there, we’ve already got an angry customer, even though everyone might have met their operational agreements, the other thing that happens is the sort of ping pong effect where, you know, if it goes to a tier—these things that get, especially, to the tier-three level, they might need input from several development teams. They might need a database team to have input to it, they might need a network team or whatever.

And with these kind of traditional silos, although they’re, if the ticket’s not gonna leave that silo, it’s absolutely the right place for it to be if the issue, I should talk issues, but things ping around and you end up with problems like champions emerging who’s the one person everybody knows can fix it every time, and so they pay their mortgage off in overtime, but they always look a bit unhealthy, and then they leave the company and everybody’s in trouble.

So, swarming has helped us, actually, it really is taking much leaner techniques. It’s about sort of being more dynamic in the way things are brought together as a team, you know, tearing down some of these silo structures, and in particular, removing queues of unfulfilled work in progress.

Ashley: Describe for us—

Stevens-Hall: And that way, we’re really learning directly from lean, we’re really learning directly from the DevOps focus on having much better flow and reducing handoffs and, in particular, not letting things build up in queues.

Ashley: For someone who’s not familiar with swarming, describe how that would work in this context.

Stevens-Hall: Okay, well, I mean, at BMC, we’ve done this in our own customer service team for a while, and what it effectively means is a couple of things. You know, you’ll always have kinda, the most severe issues have always pretty much been swarmed everywhere. And that’s, you know, everything’s on fire, so we’ll get everybody we need into a room and we’ll sort it out. And so, that’s always kind of been the most basic form of swarming, even though we haven’t really called it that. And that’s not really where the novelty is.

For us, the novelty is, we’ve collapsed that tier one and tier two, so instead of having that kinda chain where somebody fairly qualified takes a look and then if they can’t fix it, somebody more qualified takes a look, we kind of put those two people together. And instead of waiting for things to trickle through queues, we look at the things as they’re coming in, but the support people will, maybe every hour, just look at what’s coming in that hour and be very reactive—okay, we can fix those three things, we’ll just get it done—will qualify the rest very well. And you get this lovely sort of information sharing between the two levels as well. So, they learn from each other. I think pair programming is an interesting analogy from the modern software development world.

So, that actually increases the flow very significantly through those first—you know, it gets things fixed quicker and it increases the throughput. Then when things do go to sort of the tier three product specialist groups, they’re not allowed to start assigning it around other tier-three groups. So, if they’ve got one of these more complicated issues, instead of doing that, they’ll pull together a group of people into a swarm and work it that way.

And it’s all—they’ve got a lot of leeway to be very self-organizing which, again, probably doesn’t sound like the impression that service management have always given. So, it’s not that rigid, you know? They will figure out what works best for their team. So, we have some teams hold three sessions a day at fixed times and people can come in with issues. We have others that spin things up on a more ad hoc basis, but the interesting point is there, again, things are not going from bucket to bucket, you know, queue to queue, they’re being owned by the person who takes command of them and we’ve found there’s really great engagement, people coming together in a Microsoft Team session or on a call or face to face way back when. And again, it looks a lot more like the kind of practices that have evolved in the DevOps community. So, again, we’re learning to sort of focus on delivering the value rather than focus on hearing sort of a pre-defined, rigid process.

Ashley: Mm-hmm. I’ve been there, actually. I know you were trying to—I think I may have stepped on what you were gonna say, so jump in.

Anand: Oh, no. I think it works. As Jon was saying, you know, back in the day or probably even still to this day, you know, every time there’s a priority one incident or a severity one incident or one of those really big things, you know, everything’s on fire type of thing, you know, we used to call it a war room back in the day, we used to have conference breaches back in the day.

You know, so that technique was perhaps limited in its application, but we’re now starting to see how that same technique is being, if you will, scaled-down or right scaled-down to the appropriate size and being used across the support organization and not just limited for use to, you know, the building’s falling down type of issues.

Stevens-Hall: And one of the great things that’s happened as we’ve sort of distributed this messaging and talked more about it is, actually, it’s got huge engagement in DevOps community. I’ve presented on this at a number of DevOps events, you know, right up to DevOps Enterprise Summit.

Because actually, what I believe it’s doing is, it’s sort of showing the DevOps community that there is, not only is the support, the world of kind of technical support and service management, you know, that sort of structured technical customer support and service management, we’re looking to try and offer value to the DevOps community, but we’re also doing it in a way that is much better aligned with the way the DevOps community has learned to work. And, you know, so rather than those developers ending up just being treated as a third line support team and having things thrown over the fence to them, it enables us to kind of bring a much more collaborative system together and reduce those kind of pockets of those silos where knowledge doesn’t escape.

So, the value—again, thinking about the value—the value, again, to those teams working in the DevOps world is that we can actually be embedding support people much closer to what they do and those support people learn how to fix the issues. And then when there’s more of those issues, those support are there as professional support, you know, as support professionals who are good at this kind of thing can be figuring out ways to proactively resolve those things, automate those processes, move towards customer self-service as an ultimate goal, perhaps, or self-healing and get those developers developing.

Ashley: Yeah, it also gets them more—I’d say more closely aligned to knowledge about what the application is, how it’s structured, who to contact, you know, help them maybe even diagnose more of the issues themselves.

Stevens-Hall: Yeah, so again, it perhaps creates some parallels with what, again, companies like Google have innovated with site reliability engineering. It’s not quite the same, you know, these are not necessarily developers and I often caution people from kind of just saying you can just do SRE, you can get service management kind of spaces like the service desk and do SRE. You’re not really doing SRE in the strict sense the way it’s known in the DevOps community where it is kind of developers doing proactive things with infrastructure.

You know, if you look at an SRE job spec, it’s gonna be a bunch of programming languages and related experience, but we can still take, again, those learning principles, you know, the idea, for example, of thinking in terms of ERA budgets, you know, so rather than every failure being a major—you know, every time we lose a bit of our remaining availability budget against that target, you know, that could be, that’s always been seen as negative, I think.

But what SRE has introduced is the concept of actually using some of that spare availability capacity to be proactive and make things work better. I like—an analogy I do is, “Why don’t we take somebody off the service desk calls for an hour?” It means our call pickup percentage is 98 percent instead of 99 percent, but they could spend that time doing something that really, really drives improvement.

So, again, these techniques that have evolved in DevOps really sort of cross-pollinate well in the service management space and enable us to better connect to the way DevOps works. And, again, help them develop.

Ashley: Mm-hmm. Well, excellent. This has been fascinating. I’ve really enjoyed talking, and I’m sure the audience does, too, that’s listening in. It’s great to talk to the contributors, to the authors of this, because you get the benefit of both, you’re writing a knowledge that’s shared in that medium, but also—what was the thinking behind it? What were the influences and how did you get to those conclusions and sorta that context is also super helpful. So, this has been really great. I’ve enjoyed talking with both of you.

Anand: Same here.

Ashley: Great. Well, my thanks to Akshay Anand who is Product Ambassador with AXELOS and Jon Stevens-Hall, Principal Product Manager at BMC Software. Thank you, gentlemen.

Stevens-Hall: Thank you.

Anand: Thanks, Mitch, and thank you for listening to us today.

November 9, 2020
Mainframe and DevOps in Traditional Enterprise, With ASG Technologies

The assumption that large, established enterprises—from insurance companies to government agencies—can’t adopt Agile processes or DevOps is based on the falsehood that legacy technology stacks won’t allow for it; that existing traditional mainframe applications or legacy applications that large enterprises are built on are incapable of adapting to these approaches.

Accelerated Strategies Group recently released the new research report, “5 Crucial DevOps Strategies For Cloud and Mainframe 2020,” sponsored by ASG Technologies. In this episode of DevOps Chats, Jeff Cherrington and Anna Murray with ASG Technologies joins Mitch Ashley, CEO of Accelerated Strategies Group, to explore how mainframe app teams embrace DevOps, its processes and tools to equip software teams so mainframe apps continue to provide businesses with vital systems and capabilities far into the future.

The audio file of the conversation is below, followed by a transcript. Enjoy!

devopsy.kinsta.cloud · DevOps For Cloud and Mainframes, ASG Technologies

Transcript

Mitch Ashley: Hi. I’m joined by some special people, some folks that I really enjoy working with from ASG Technologies—different from the ASG that I work with. [Laughter] So, I’m joined today by Jeff Cherrington and Anna Murray. Thank you, both, for being here.

Jeff Cherrington: Well, thank you very much, Mitch. I’m Jeff Cherrington, I’m Vice President of Product Management for Systems with ASG Technologies. Many of you may know ASG. We’ve been in enterprise infrastructure management software for over 40 years, and certainly hold a prominent position as well in enterprise content management. We’re very keen to have the conversation today around how traditional infrastructure—meaning the mainframe—aligns with new DevOps initiatives in the enterprise.

Anna, if you would introduce yourself.

Anna Murray: Sure. Hi, my name is Anna Murray, and I’m a Senior Product Manager with ASG Technologies, and I work with Jeff Cherrington. And I have extensive experience with automation across platforms and data centers, as well as agile transformation for teams.

Ashley: Excellent. Jeff was saying before we started that he used to work in radio—you can tell. [Laughter]

Murray: [Laughter]

Cherrington: [Laughter]

Ashley: You’re very comfortable behind a microphone—no doubt, no doubt. We were talking about everybody’s on video these days, so that’s awesome.

Murray: Right. [Laughter]

Ashley: Well, great. You know, we’ve been doing some work together and we do have a report coming out to kind of pre-announce that. We’ll be talking about that a little bit later. But there’s a lot of myth about DevOps and mainframes. I know even some analysts—I won’t name any names—have said they’re two different paths, you shouldn’t try to do both. I think the jury has started to change their mind on that.

Why do you think some of those myths have existed of, “No, we can’t do DevOps on mainframe environments?” Do you wanna start, Jeff?

Cherrington: I think I will, and then I’m sure Anna’s got some thoughts that she’ll want to contribute. You know, it’s certainly a reality within the industry that we’re going through a generational shift around our leadership or IT, whether it’s infrastructure or application development. There are those who are still working daily, like myself, who represent the traditions of IT from the very beginnings back in the 1960s, and then there are others who are certainly much younger and certainly have much different experiences, which may not include any exposure to the mainframe. And, as a consequence, there might be some resistance, there might be a little bit of anxiety about the technology, and it can be formidable to approach if you don’t have the appropriate background.

The things that we’d love to talk to, though, is that the mainframe as traditional technology still performs incredibly important roles within the enterprise. And at the end of the day, DevOps is much more about technique than technology, and it can apply as easily to mainframe and should as it does to any other part of the IT infrastructure.

Anna, do you have some thoughts to build on that?

Murray: Sure. You know, as I think about the generation gap that you’re talking about, I kind of come on the other end, but I’m Gen X. And so, we were the generation that said, “Oh, the mainframe’s dying,” right? [Laughter] So, that—obviously, I’ve learned that’s totally wrong, and the generation coming after us is coming in to learn the mainframe and realize how powerful it is, right?

And so, I think a lot of the leaders that are coming in are coming from this generation that didn’t even think about mainframe for a while, right? And so, they did all their planning and their agile transformation and their DevOps transformations thinking about the cloud and all of their Windows and Linux and Unix servers and didn’t even think about the mainframe.

And so, I think that’s the other side of the gap that happens. As the younger leaders are coming up, you know, especially, I would say blame my generation the most, right? [Laughter] Because there’s this gap, and—learn more and make sure you’re talking to both ends of the spectrum and learn about crossing the gap.

Cherrington: And actually, the way I like to phrase it now is far less to use jargon like “generational gap,” but instead talk about generational bridge, because that’s what I’m seeing.

Murray: That’s so much better, yeah.

Cherrington: We’re seeing that the younger IT professionals are identifying that there’s great opportunity to work with mainframe in the coming years. And so, we see Millennials, or is it Gen Y—the generation after yours, Anna—who are stepping forward and saying, “This is really interesting. The mainframe does all of the technologies, it supports all of the technologies that I learned in uni, university. I can do Java, I can do TCP/IP connections, I’ve got great sources for strong cryptography, it supports Unix, I can put Linux onto a mainframe LPAR—this is a good space to be in.”

And so, more and more, we’re seeing that the people we engage with are a mix of people that are my age with the white beard or the gray beard and a mix of young, fresh faces that are really eager and really excited to get involved, and who come predisposed to new techniques such as DevOps.

Murray: Mm-hmm.

Ashley: You know, there’s so much important things that both of you said. One is that in DevOps, there is no technology definition of what it applies to, and it’s very easy to associate it with Cloud Native and maybe newer applications, because that’s where it sort of grew up initially.

But DevOps is really about how we create software, not what technology we use to create software. And it’s about how teams collaborate, it’s about how you share information, it’s about how you get different functions from the business together in a collaborative team to kinda do things earlier in the process, do automation. All of that applies to the mainframe, of course, and there’s tools to do much of what we’ve talked about. Maybe you can say a little bit about how people approach DevOps in the mainframe environment.

You wanna go, Anna?

Murray: Right? Well, you know, when you approach DevOps in the mainframe environment, it’s not so much just about the mainframe environment, but the company. The whole organization has to be behind DevOps, and there has to be leadership saying, “Hey, this is something we need across silos,” right? And then you have to look at the tools available to you. DevOps is a lot about the toolchain itself. There’s hundreds of tools in that toolchain, and so, you have to start looking for solutions that are gonna meet your needs and help you cross those silos.

Cherrington: You know, it’s certainly true that everybody resists change. I think that’s an innate part of human nature, but both Anna and I have seen that things of this nature can come forward, can be used with teams that are mainframe-centric, perhaps have been doing things the way they’ve been doing them for 10 years or 20 years or 30 years.

And there’s natural resistance. “Gosh, you know, I’ve done things the way I’ve done them successfully for so long, why should I change?” Certainly, I’ve seen agile adopted by mainframe development teams, sometimes kicking and screaming, but once the resistance curve is overcome, it becomes very productive and becomes very natural.

And I think we’re at that stage now in terms of adoption of DevOps for the entire enterprise infrastructure, from Windows all the way to the mainframe and onto the cloud and even onto mobile, even as there are initial reactions of going, you know, “How can this apply? This is not something I learned when I went to my classes to learn more about the mainframe at SHARE in 1995 or 1985.” But we have proof points.

We have large international enterprises, we have small regional enterprises that are coming forward and saying, “I must have mainframe. It plays a critical role for things that I need to do, particularly around payments processing, anything that needs highly available, real-time online absolute reliable performance. And it is only part of my infrastructure, and I need to treat how I develop there the same way I treat developing anywhere else.”

Ashley: You were talking about, also—so many apps are not just a mobile app, right? There’s a whole back end to it, oftentimes sharing data, even talking transactions between multiple systems, one of those or multiple may be mainframe applications. You know, and if I step back for a minute and think about our current environment and how much things have accelerated in doing sort of these digital transformation, digital experiences for customers, organizations are looking to both strategically move quicker, but also be able to react opportunistically and sometimes based on conditions. And it seems like some of the flexibility with DevOps makes it easier to coordinate some of those activities across multiple applications. So, if you do have to do three different release to make up one new capability, that comes together much easier.

Cherrington: It does. You know, the thing that I always look to as I engage with anything around business is, to use an old phrase, “why is the juice worth the squeeze?” And while we talk about DevOps a lot because of its elegance, because of its collaboration, because of the ways in which it makes development easier, the real juice of the squeeze is time to market. The whole reason to consider DevOps is how can we get something we need to get in terms of new technology enablement to market quickly, more quickly than we did before, but not sacrifice quality.

And that’s what we see time and time again is, we have something we need to get to market. I want to present new capabilities to my customers through an app on the phone because that’s where people live their digital lives. But at the back end, it’s dependent upon the mainframe for things such as account balances, customer statuses—an unending list of capabilities that still remain on the platform as the best place for that type of activity to occur.

Ashley: Mm-hmm. You know, I’m thinking about just the recent experiences with the reactions to COVID and contactless delivery, inventory, product inventories are often something that’s still on the mainframe, has been for a long time, and now, you know, retail stores, as well as a lot of others, have to be able to maintain a really accurate enough inventory and also present that to the customers so they know, what store can I go at to pick up whatever I’m looking at buying.

I’m curious, too—I know that ASG Technologies has some of your own products, your own technology around this idea of orchestration across platforms because you work both mainframe and non-mainframe environments. Talk to us a little bit about how you approached coming up with that product and maybe a little bit about how it works and what it does.

Murray: Sure, I’ll jump in for a little bit here. You know, you talk about orchestration—that’s combining your toolchain, right? You’ve got all the little pieces of your DevOps toolchain, and you need to figure out how to connect all the dots and bring it together and, you know, ASG has been doing automation and orchestration for a long time, but we’ve changed our focus into bringing in the development part of that toolchain, right?

Operations has been kind of a focus of automation for a long time, and now we have to pull in all of the development pieces that happen and the configuration management that happens, and all of those—there’s lots of little tools there, right?

So, we haven’t tried to come at the market as trying to provide all the tools, but we’re trying to provide some of them, right, and we definitely want to orchestrate as many as possible, right, and cover the entire environment for the customer. On the mainframe, the most popular thing we’ve been working with recently is JCL Management. Every mainframe’s running JCL, right? Nothing happens on the mainframe without it, and so making sure that there’s a DevOps interface to your JCL Management solution is really important. And so, we’ve made an investment in making sure that ours has both an Eclipse plug-in that makes it easier for the developers to interface with that JCL as well as a RESTful web service API so that it can be integrated with building of the products and crossing across the silos to other products.

Ashley: Mm-hmm.

Cherrington: And certainly, in the approach that we’ve taken, we look to be a good citizen of the DevOps enterprise community, and the work that Anna and her team have done, we ensure that we support the most popular integrated development environments for doing this sort of work. So, the JCL quality assurance and management offerings that we have for the mainframe are also certified for the Compuware Topaz integrated development environment and for the IBM—what’s the name of it again, Anna? It’s—

Murray: IDZ.

Cherrington: IDZ. What was the rational development environment that’s now rebranded?

Murray: Yes. [Laughter]

Cherrington: As well as any other Eclipse compatible IDE that a customer may want to use.

Ashley: You know, it’s interesting, just thinking about all the, a number of the terms that you both used in just those last two comments, you know, mainframe 10 years ago, you wouldn’t have been talking about, I don’t think, RESTful IDE—all the tools that we kinda think of as sort of in cloud applications, much of it is the same toolset, a lot of the same ideas, just working with integrating some other different tools that are specific to the mainframe environment.

Cherrington: It is, and you know, I certainly want to encourage those who are listening and watching—and particularly, those who may be ASG customers now or are considering becoming ASG customers—to join us at our worldwide customer conference, a virtual conference this year, EVOLVE, that will be occurring on October 6th and 7th, because we will be making some significant announcements about extending support in this area, including opportunities for creating interfaces to mainframe applications that can extend all the way to mobile, if that’s of use to a customer.

We’ve had a lot of excitement coming into this, we have a lot of partners and customers who are going to be presenting, and there’s a great deal of energy that we’ll be putting forth around our DevOps support and DevOps enablement.

Murray: And can folks sign up? How do they register to attend the virtual conference? Is that on your website?

Cherrington: It’s on our website if you come to www.asg.com, I’m sure you’ll find something right on the home page that says EVOLVE 2020 and it’ll give you the opportunities to get, well, involved.

Ashley: [Laughter] EVOLVE and involved at the same time.

Cherrington: Exactly. [Laughter]

Murray: [Laughter]

Ashley: You know, the fact that you get to work with so many organizations that are adopting DevOps, I’m kinda curious about two things. How does the mainframe teams approach wanting to learn about DevOps and coming up to speed and trying it, and then how do the existing practitioners maybe outside of the mainframe group that are also using DevOps—how do they see what’s happening in the organization and how do they…do they want to participate, do they support it, are they kinda not sure? What do you see happening, there?

Murray: So, yeah, you know, there’s a mixed feeling. You know, there’s definitely differences between, you know, if it’s led from the top down and people are being told they have to change, right, it depends on how you’ve adjusted the expectations in your team, right? Helping them learn what’s coming and why instead of just telling people what to do makes a huge difference, right?

Ashley: Mm-hmm.

Murray: We’re all much more interested in solving problems and learning new things together. So, it’s really important conversation is held properly, right?

So, we have some that are really excited that they want to learn and they want to jump in from the mainframe side and grow, and then there’s others that are really just struggling and pulling their mainframe teams along, right? So, one customer I think of, you know, is standardized on Compuware Topaz Workbench, but the developers are less interested in switching over. They have some of the older generation who’s very comfortable with the green screen and they think, “Why bother switching to Topaz?” You know? They just don’t even get it.

Ashley: Mm-hmm.

Murray: And so, you know, the truth is, we really need to have solutions that meet the needs of all of the people that are part of the DevOps environment, right? So, it isn’t—you know, a very experienced mainframe programmer doesn’t have to use Eclipse, right? They can be quite happy on the green screen and we should let them stay there, right? [Laughter] And we do, our JCL Management solutions have a very robust green screen interface, and then we bridged the gap, as Jeff was talking about earlier, with having those APIs, right?

And so—yes, so the DevOps toolchain is still brought together with something like our ASG Enterprise Orchestrator pulling in the code and grabbing with the API the JCL and making sure that the standards are applied and then bringing them across for compiles and distribution into another environment, right? Not that you compile JCL, but there’s other parts that are related.

Ashley: Mm-hmm.

Murray: So, you know, you asked—it’s kind of a mixed bag. And we see that, too, right? And as the conversation becomes more common, right, I think we’ll have more people who are more comfortable having that conversation and learning together.

Ashley: Excellent. Well, Jeff has been bitten by the Zoom bug, so he had to call in from his call dropping, so glad you’re still with us, Jeff.

Cherrington: Mm-hmm.

Ashley: You know, we were just talking about the adoption process, and Anna, you were talking about how mainframe teams kind of approach this. I’d like the other side of it. DevOps teams that maybe aren’t in the mainframe group that have been practicing this for a while, maybe a few months, a few years—how do they see this happening, and is there collaboration? Do they pitch in, do they tend to work together or not? How does it go?

Cherrington: Well, some of the things I’ve seen actually goes to either end of the spectrum. For the teams working with the more modern technologies and have to adopt DevOps very frequently, we find evangelists, those who have gotten to the point where they believe in the techniques and the approaches so passionately that they’re out there actually promoting them everywhere they can. It’s much like what we saw with the adoption of agile in the last decade. We’re seeing that same sort of passion surround this approach to development in this decade.

You know, it’s one of those things, we have to keep in mind—DevOps was not even a term within the industry until 2009. I mean, it’s barely a decade old, and it’s in these last five years that we have seen the acceleration for adoption.

Now, having said that, you know there certainly are always going to be pockets within any enterprise where, again, there’s resistance. There are those who are not looking for change and those that, perhaps, while they have embraced the DevOps approaches for their distributed systems or cloud development, look at the ideas of what they have to change or adapt to on the mainframe side and really don’t want to go there. The idea that there might be a long compile that has to be done on the mainframe before the next step in the DevOps process can occur will cause some—a little bit of agita.

And that’s why it’s so important we need to take a look at the strategies that are necessary for DevOps success. I think that’s something that you speak to very eloquently, Mitch. And out of those steps, the one that I think is so critically important is culture shift. Just like with agile adoption, DevOps adoption needs support from the top, and it needs to be constantly vocal support to help people pull through these resistance curves. Resistance curves are natural and the quicker an enterprise gets through them, the quicker they get to a point that they’re delivering new capabilities to market much more quickly.

Murray: Right.

Ashley: Thanks for your kind words about the culture, too, and I want to get your thoughts on this, Anna. Culture is a lot of things, but I think we’re all human at the end of the day and none of us want to look dumb, right? We don’t want to tackle something we don’t know if we can learn or maybe not kinda look so good in front of our peers if we’re the ones behind the curve.

And I think something that can help combat that is, one of the principles of DevOps is sharing, is really—it’s collaborating, but it’s also sharing. Sharing scripts, process, tools, content, methods—all of those kinds of things which, if you truly adopt DevOps, as you said, Jeff, you can become an advocate and then also help with that transition and very quickly, you know, they kinda get over that curve of, “Okay, alright, I’m not—I’m familiar with this,” as you mentioned, Anna, I can still use my green screen or many of the tools that I’m already using and I’m just adding to kinda what I’ve been doing.

So, your thoughts, Anna?

Murray: Right, well, I’ve recently been having other conversations with partners about this culture shift and it’s become really clear with other companies that are supporting DevOps and those initiatives that you really have to have not just buy-in from your senior management, you’ve got to have active support. You know, they have to sponsor the change.

Because we’ve also seen companies who don’t go through the change, they fail. If it’s from the bottom up only and the senior leadership says, “Okay, yeah, sure, that’s a great idea,” but they’re not actually investing in it themselves, the team, when they hit road bumps—because they will. It’s not, you know, switching to DevOps doesn’t happen overnight. I think we all know that. And over time, you’re gonna hit roadblocks and you’re gonna get discouraged. And who is it that’s gonna lift you up?

Now, hopefully, there’s evangelists that’ll help keep pulling you through and encouraging you, but at the end of the day, if your senior management isn’t coming back in to say, “Hey, guys, we believe in this process, it’s worth fixing, we’re gonna invest in whatever it takes to solve this problem,” then they’re encouraged to keep moving forward, right?

But, you know, there is the difference happening out there where the leadership isn’t always invested in it. And so, that’s what we’re really encouraging when it comes to that culture shift that has to happen, make sure that you get not just buy-in but investment from your senior leadership.

Ashley: Mm-hmm. Hugely important and it goes back to the, “Why are we doing this question?” that you talked about also, Jeff. You talked about really responding quickly and getting software out to market or quickly in today’s situation with COVID and uncertain as well as very quickly changing conditions, you know, something could very easily come down from Product Management or whoever to the development teams and say, “Okay, we need to add this capability or change how we’re doing something.” And the team’s ability to react quickly—I mean, they already do today, but even more quickly under these circumstances, I think, demonstrates the value not only of DevOps, but also those teams.

Cherrington: Absolutely. Absolutely. I mean, it’s always a virtue to be able to get to market quickly. And in the current period of the pandemic, it’s a virtue that actually can impact lives on a broad scale.

As the different national governments are taking the steps that they need to take to provide stimulus and secure the safety of their populations during all of this disruption, one of the things we’ve seen is that there have to be changes to critical traditional mainframe systems for all of this to happen. Certainly, the unemployment compensation that was distributed here in the U.S. touched legacy traditional systems at the state level that perhaps have not been actively developed for some period of years.

And certainly, those government enterprises or commercial enterprises that were pre-prepared to apply their DevOps techniques to making those changes to their traditional offerings, traditional applications were better prepared to deal with this and to deal with the ongoing change as our government’s tried to figure out how to stabilize economies and get us through this challenging time.

Murray: Mm-hmm.

Ashley: You’re absolutely right, and that’s one example of many. I mean, there’s insurance claims processing to get your request fulfilled quickly, you know, new medicines—all of that kind of thing. There’s so many areas where mainframe technology is involved today.

Well, I wish we could keep going. Maybe I have to come to the conference to continue the conversation. [Laughter]

Cherrington: [Laughter]

Murray: Yeah, we would love that.

Cherrington: You would always be welcome.

Ashley: Well, I appreciate that very much. And so, just a reminder for our audience, the EVOLVE conference is on October 6th and 7th. Go to the ASG.com website to find out how to register; I absolutely recommend doing that. And as I mentioned earlier, we have a research report coming out and the working title of that report, I think, was “Five Critical Strategies for DevOps and Mainframe.” So, we’ll see, maybe that title will stick or something close to that. I’m excited to get that out because that’s been a great effort working with you.

Well, Anna Murray, thank you very much; Jeff Cherrington, also—thank you for joining us today.

Cherrington: Thank you so much.

Murray: Thank you, Mitch.

Cherrington: And folks—stay safe.

Murray: Yeah.

Ashley: Alright.

Murray: Alright, thank you.

Ashley: You bet.

October 9, 2020
Bringing DevOps to SAP, With Basis Technologies

DevOps has not only reached mainframe groups in enterprise but also to large applications such as SAP. Organizations are moving away from waterfall methods and mega releases that take many months to deliver. What’s needed are many more rapid release cycles and deployments that support the accelerating pace necessary to do business.

In this conversation on TechStrong TV, David Lees, CTO of Basis Technologies, joins MediaOps CEO Alan Shimel to explore how organizations implement DevOps into their SAP integration and deployment cycles. Having lived through this transition, David shares his unique perspectives on the necessity to break through bottlenecks and make changes in supply chains, finance and many other business processes needed to support the business.

The audio file of our conversation is below, followed by the transcript. Enjoy!

devopsy.kinsta.cloud · The Era of SAP and DevOps

Transcript

Alan Shimel: Hey, everyone. Thanks for joining us on another segment here for TechStrong TV. In this segment, we are joined by David Lees. David is the CTO at Basis Technologies. David, welcome to TechStrong TV.

David Lees: Thanks, Alan. Great to be here.

Shimel: Great to have you here. So, David, I don’t think we’ve done an interview here with Basis Technologies before, so I think we should start right there.

Lees: Okay. So –

Shimel: Go ahead.

Lees: Basis is a company that’s been around for about 20 years. We are a global organization that works with hundreds of customers around the world, and the thing that they all have in common is that they run SAP software, as I’m sure many of your audience do.

Shimel: Yep.

Lees: We specialize in solutions around the application life cycle management space. We kind of started up the whole trend in terms of the DevOps for SAP by really helping people to manage their change in a much more Agile way than SAP is traditionally known for.

Shimel: Excellent. And of course, you know, David we were talking off-camera before we got started, I’m doing devopsy.kinsta.cloud seven years, right? And when I first started everyone said, “Oh, DevOps is something for startups; I don’t know about large organizations.” And then sure enough every large – not every, but most large organizations in the world started recognizing the benefits of doing things in a DevOps fashion, and we fought this battle with DevOps in the mainframe, DevOps on things like SAP. How could something like SAP benefit from DevOps?

But of course they can, of course they can, and I think SAP themselves has recognized it and they’ve come out with a lot of DevOps-related solutions, products, services, but also companies like Basis are recognizing that, hey, my customers are asking me about DevOps but they’re not going to throw away tens of millions of dollars and years and years of tribal knowledge that they’ve developed in doing things on SAP. It’s just impractical. And so, you know, they have to put a little chocolate in the peanut butter and it’s got to work together, right? I would imagine, you know, Basis has – this is a real specialty that the market’s calling for and Basis has a real role to fulfill here.

Lees: Yeah. I think it’s as relevant in the SAP world as it is elsewhere for exactly the same reasons; customers are looking to become more Agile, they want to be able to deploy in kind of just in time, moving away from the whole annual or six-monthly mega release delivered in a very waterfall way in order to respond to market changes, customer needs, in order to drive more efficiency within their application development and application management space and to deliver that with quality that a business-critical system like SAP mandates, to be honest.

Shimel: Sure. So David, I always like to ask our guests a little bit about their own personal background because people out here are wondering, right? So they look at David Lees, the CTO of Basis Technologies, they’ve been around 20 years in the SAP space, they deal a lot. David, what’s your personal background like?

Lees: So I actually joined Basis only about 18 months ago, and prior to that I spent the majority of my career on the other side of the fence. I was with Proctor & Gamble, a large global consumer goods company, and pretty much most of that time was connected to SAP in some shape or form from implementations through support, upgrades, getting ready for transformation to things like S/4HANA, and it was in that role as a customer that I first came across Basis a few years ago and actually brought in one of their products into Proctor & Gamble. So I kind of first had that experience as a customer of Basis before deciding to kind of make the step in to working here as CTO.

Shimel: Excellent. So you literally have a career in SAP that you bring to Basis, and as you said, from the other side of the fence; not as a vendor but as a user, a consumer, a customer of SAP.

Lees: And like you were saying before, I think many of the customers of SAP that have been running with SAP software for now 10 if not 20-plus years have developed the knowledge, they’ve developed their solutions and their processes exactly how they like them, but that’s come with massive investment, massive investment in custom code, custom solutions, investment in the way they’re managing those developments, those projects and maintaining them on a going basis, and so I lived through firsthand this whole lifecycle, let’s say, plus the last few years where the old way of managing things was simply not going to be the right way to continue to manage in the future because at the end of the day, while the rest of the architecture around SAP is evolving at a much faster rate you can’t kind of retain the bottleneck image that SAP has and you have to find a way of breaking that bottleneck and being able to move at a similar pace to the other elements in the architecture. It’s not as easy as saying, okay, well let’s just not touch the back end and keep that totally frozen. It’s simply not possible. You need to make as many changes in your supply chain and finance and legal entity structure, et cetera, as you do in your ecommerce platform.

Shimel: Fair enough. Excellent. Again, the parallels to what we saw in the mainframe space is also – but I think there’s something else you gotta remember. People don’t use SAP just because of their prior investment or just because it’s what they’ve done before, right? Organizations of a certain size use SAP because it offers real advantages and allows you to do things in such a way that you can’t have or you can’t get with just about any other solution out there. So it’s not just because this is what my grandpa did or this is what we’ve done for 10 years, 20 years; it’s because we are an organization of a certain scale that we require this.

Lees: Yeah. I think they’re a market leader for a reason.

Shimel: A reason, right.

Lees: They have the products that, like you say, run some of the largest enterprises in the world; many of the Fortune 500 or FTSE 100 or what have you. And it’s in spite of that that we need to find a way of being able to manage that in a much more modern way. There’s certain elements of SAP that I’m sure some of your kind of more pure DevOps listeners or audience would struggle to understand in terms of, for example, the way version management is handled in SAP inside like a single database, hard to manage branches in terms of parallel developments, the way changes are deployed through the use of things like transports, create to some extent an ecosystem in SAP that is different than a lot of the cloud native and more modern applications, but at the same time we want to be able to help customers to manage the risk, to manage the agility, and to be able to move things through with confidence and with speed in keeping their changes across their architecture orchestrated in a controlled way.

Shimel: Absolutely. So David, if you don’t mind, I think we’ve laid the groundwork here well, let’s look at, if you will, the anatomy of an SAP-DevOps engagement, right? We spoke about maybe it’s an existing SAP customer who – right? – doing that big yearly release or twice-a-year release is not going to cut it anymore. They need to be more agile – nimble agile, not necessarily Agile software development, though that too, but they need to be more nimble, they need to be more responsive, they need to – they want to utilize a modern CI/CD pipeline type of delivery system.

Lees: Yeah. I think as with anything here you’ve got the three normal components. It’s about the people, the process, and the tools. So there’s no kind of silver bullet that’s going to say, yeah, I’m suddenly DevOps in my SAP space. You need to have similar best practices around automating as much as possible within that pipeline, and some of that’s available natively inside SAP to do things like automated unit testing, automated code inspection, but the piece of the jigsaw, let’s say, where we come in is to create effectively the pipeline portion for SAP using one of our products called ActiveControl, and that’s about being able to deploy in an automated way within the landscape to the point where the customer is comfortable and being able to kind of highlight and manage all of the interdependencies or identify where it is safe or isn’t safe to move changes in a more accelerated way.

So I think some of the best practices I would say are common across the SAP and the cloud native world, and when it comes down to some of the tooling you need to start looking at SAP-specific tooling where it’s not possible to leverage some of the kind of off-the-shelf open source best practice tools like best-of-breed ones such as Jenkins or Git, but equally this is where we can integrate and we can help a customer in managing their SAP side of their estate, their architecture, in a coordinated or orchestrated way with the non-SAP world that they’re managing using some of these more traditional DevOps-based pipeline tools or CI/CD tools.

Shimel: Yep. Agreed. So David, when Basis comes in – let’s talk about the engagement now, right? Is it more of like a classic consulting where we come in with bodies or is it more of an architectural and here’s the processes and kind of maybe software we’re going to introduce or both?

Lees: Yeah. So we are primarily a software company in terms of providing the solutions, although we do recognize and we do work with some of our customers that they also need help on what are the process changes or architectural changes that they should make in order to go further, in order to become more Agile, what are some of the, again, best practices that they should be doing without switching on or without investing in? They won’t be able to go as far as they want to or need to. So whilst we are today primarily a software company and we will come in to help our customers activate those solutions and deploy them, we are starting to kind of branch out a little bit more into the consulting side to help customers on that journey, to define what that journey looks like for them based on where they are today and based on where they want to get to.

Shimel: Fair enough. So I’ve got to kind of ask it only because you have to in these days – how’s COVID affected all of this?

Lees: I think we’re affected to some extent like many companies; however, we are to a certain extent well insulated. We have a subscription-based model, so the companies that tend to deploy our solutions continue with those solutions. We have an incredibly high renewal rate which we’re very proud of, and that gives us a very strong cashflow and a very strong platform in which we can continue to invest in new products and solutions as well as to continue to invest in identifying and adding new customers. I think to some extent there is – some of the pursuits, some of our prospects have been impacted by budget restrictions, but I think at the same time COVID is accelerating significantly the pace at which companies realize they need to transform. So I think it’s probably as much as one side kind of slowdown and budget restrictions as it is kind of companies coming in saying we have to modernize, we have to change the way we’re doing things and we need our SAP application development to be as flexible as we have elsewhere in our organization.

Shimel: Agreed. And, you know, I kind of suspected that but I wanted to kind of confirm it with you, is yeah, you know, on the one hand it definitely – everyone working remote and everything that went on you could see it slowing down, but on the other hand it becomes very much a catalyst for transformation, right? There’s no waiting for tomorrow; we’ve got to do this now, and so it happens in there. What about working remote though, David? I mean you’re obviously in your home office right now.

Lees: I am and I [laughs] was always set up in a home office kind of gig here at Basis, so I’m based in Spain whereas the headquarters is in London. So even pre-COVID I was kind of used to working a few weeks from home and then going into the office for a week or so every month. Now it’s just all at home for the foreseeable future. We’ve had to adapt. Development teams that used to be very – used to kind of working together, whiteboards and daily standups and that sort of thing have found ways of doing that remotely like everyone else has had to do, and yeah, I think we’re all getting used to a very interesting new world, and I would be very surprised if we go back to exactly how it was previously.

Shimel: I don’t disagree with you. But the good news is, you know what, you’re still able to do your work, stuff gets done, and it could be worse, as they say. Hey, we’re about out of time but I wanted to mention one other subject. You guys are doing a webinar here on devopsy.kinsta.cloud. It’s probably about a month from now, maybe even a little more than a month from now. It’s on SAP and DevOps.

Lees: Yeah.

Shimel: I’m not going to put you on the spot here and spill the whole beans, but who should be – you know, talk to us about it.

Lees: I think the intended audience for that is people who are traditionally on the DevOps side of the fence who’ve grown up outside of SAP who need to or are realizing that SAP should become part of what they’re including in their plans and in their strategies. Now I would still say SAP kind of long-timers would get some value out of that webinar, but it’s more about helping people understand how SAP is relevant, why it’s relevant, and how we can help customers bringing the SAP world together with the more modern side of the application house for customers, and so I think it’s primarily tailored towards that audience.

Shimel: Cool. More information on this will be available on devopsy.kinsta.cloud under our webinar section. David, I look forward to that webinar. I want to thank you for joining us on TechStrong TV today. Where in Spain are you based, by the way?

Lees: Near Málaga on the South Coast, so a nice little town.

Shimel: Oh, it’s terrible, terrible, terrible.

Lees: Like yourself in Florida.

Shimel: Yeah, I was gonna say, in Boca Raton I really can’t complain either. But anyway, hey, thanks for joining us, look forward to the webinar in October, and keep up the great work.

Lees: Great. Well, thanks a lot, Alan. I look forward to coming back on, talking to you again in the future.

Shimel: Absolutely. David Lees, Basis Technologies, SAP and DevOps. It’s real. It’s something you need to be thinking about, especially if your organization is already an SAP shop. This is Alan Shimel. We’ll be right back with our next guest here on TechStrong TV.

October 9, 2020
DevOps Chat: ASG State of Software Delivery Management Report

Accelerated Strategies Group has just delivered its “State of Software Delivery Management Report,” commissioned by CloudBees. In this DevOps Chat, we speak with Mitchell Ashley, CEO, founder of ASG, about the report and why it is important for everyone managing software delivery today.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · State of Software Delivery Management Report, Accelerated Strategies Group

Transcript

Alan Shimel: Hey, everyone. This is Alan Shimel, and you’re listening to another DevOps Chat. I have a really great chat lined up for us today because I’m joined by my partner, Mitchell Ashley, founder, CEO of Accelerated Strategies Group. Mitchell, welcome to another DevOps Chat.

Mitchell Ashley: Well, very nice to be here. It’s great to be on this side of the microphone for a change. [Laughs]

Shimel: It is kind of. I mean, Mitchell, before we jump into the report out of Accelerated Strategies Group we want to talk about, just as little history for our audience. Mitchell and I have been doing podcasts together now –

Ashley: Oh my.

Shimel: Fifteen years?

Ashley: At least. 2004 or ’05, something like that. Yeah.

Shimel: So it’s still secure after all these years.

Ashley: I was waiting for the,”This is Alan Shimel and this is Mitchell Ashley.” [Laughs]

Shimel: Exactly. Do you remember those days? Oh my goodness. You know what’s old’s new. It’s good to have you on with me, Mitchell. You know, as you said you’re often on this side. You and I kind of split up our hosting duties for DevOps Chat. But we’re here today because Accelerated Strategies Group just dropped a report on the state of software delivery management, SDM.

Ashley: We did.

Shimel: And the report was commissioned by our friends at CloudBees but it really is the independent analysis and research of you, Sanjeev Sharma, principal analyst at Accelerated Strategies Group, and the rest of the Accelerated Strategies team. So, you know, we’ve done a little video on this, Mitchell, but I’m going to assume our audience listening here on DevOps Chat maybe didn’t see the video.

Ashley: Okay.

Shimel: Why don’t we start off – when we talk about SDM, what are we talking about here?

Ashley: You know, we used to – we’ve had all kinds of names for methodologies, you know, software development lifecycle management, blah, blah, blah. You know, what I think it’s really about, software delivery management is about the whole delivery, the end-to-end process of how do you manage the software process from here’s money, we’re going to invest in something that we think is going to be created through software; how do you know through the whole machinations it goes through to actually create the software that you know where you are and what you think you’re going to be getting? And then when it’s all done how do you know that you got what you thought you paid for? To think about is sort of as a business view into managing the software process.

So not just IT and product teams but also the executives, senior leaders, can find out what the heck is going on and how well – it’s really about how well do we develop software and how well – our ability to manage it.

Shimel: Yeah. I agree. You know, we had this discussion earlier with Sanjeev as well, correct, and, you know, in my mind it’s about how do we manage the factory rather than how do we work on the assembly line? A lot of software today, especially in the DevOps world, is about how do we work on the assembly line? And that’s a noble, worthy thing to do.

Ashley: It’s important, yeah.

Shimel: Right. That software delivery pipeline, that factory, you know, assembly line as we move software left to right. But, you know, someone needs to be managing the controls, right? And are we doing it just in time? Are we using lean? And if so, how? You know, even lean you always need to be turning a dial and checking things out.

Ashley: Exactly.

Shimel: I’d like to talk a little bit, Mitchell – well, let me – let’s first start with this.

Ashley: Sure.

Shimel: Of course the mantra at Accelerated Strategies is information wants to be free, and in that vein this report is free and open to anyone – anyone – who’d like to download it, right?

Ashley: It is. That’s our belief. I mean that’s really what we founded and you were part of founding Accelerated Strategies group two, is let’s do something disruptive in the analyst industry. You and I have paid an awful lot of money to analysts for sometimes questionable [laughs] – what are we getting for it? – but we have to do it, right?

Shimel: Well we paid for access.

Ashley: We paid for access even though that’s – you know, everyone says it’s not true –

Shimel: [Inaudible comment]

Ashley: – but it is. I mean let’s be honest about it. I think it is anyway. With Accelerated we said, “Look, we’re not going to pay –” you know, every time you touch an analyst you had to pay him. Every time you said something to him you’re like dropping in another coin. And let’s do this the right way. Let’s do this – when you’re working with us, engaging us to do something for you, you know, do some research, assess the market, advise you, do a strategic project, do some competitive analysis, all of those things for a research report, that’s when we’ll make our money. You are welcome to distribute that as freely as you like.

We’re not going to hold you behind a paywall and subscription fees and licensing. The customer’s give us all that information. Why don’t we give it back to them in some meaningful way [laughs] instead of making them pay for it? That’s –

Shimel: You know what, Mitchell? I think back to the days where we would pay, you know, a certain large analyst company to send an analyst out to spend the day with us, and we’d pick them up at the airport and get them breakfast and lunch and, you know, keep – wine and dine them all day while trying to get him to understand our point of view, and when I drop him back off at the airport, I’ll be honest with you, I felt a little dirty.

[Laughter]

Ashley: And it kind of felt like, why do I feel like we know more about this space than the analyst?

Shimel: Yeah, there was no doubt that I felt like I knew more about that space, but, you know – and I’m not – look, everybody needs to make a living and there’s the oldest professions in the world, but I really felt like I – I didn’t like paying for it. You know what I mean? And there was definitely some of that involved. But enough about the analysts. _____.

Ashley: We could do, like, three podcast episodes on that or more.

Shimel: Yeah. We can go off on that. What I want you to talk about though, Mitchell, is would you share with our audience a little bit of insight? How was the research done here, the analysis? I know Sanjeev Sharma, principle analyst, was lead author on this report, but give us an idea of, you know, the ASG methodology, if you will.

Ashley: Well really any research has to start out with some hypothesis; what do we believe about the market or what do you think we believe about the market? And really the hypothesis here was around what’s the maturity level of our ability to manage the entire software delivery process? Connecting it to the business, not just inside of IT. So we started with that and we have a target audience who we’re trying to talk with, both individual contributors, leaders in the software development part of this but also executives, product people, CIOs. So we really tried to cast a big enough net but not so broad that it all got watered down and you couldn’t tell who said what.

We really spent some time focusing on who we wanted to talk to. And it wasn’t a short survey but it wasn’t a long one. There were really some insightful questions around do you know what your backlog looks like and what it costs you to delay a release or to trade something off one feature for another? Do you really know when you’re going to get the release or the functionality that you’re paying for so you can move the business forward based on those plans, or are you kind of shooting in the dark and you’re just hoping that it comes out sometime in the next quarter and we’re good and then we’ll kind of get everything running from there? So we did a survey, but we did a lot of kind of research going into it, talking to different people in those roles before we ever built the questionnaire.

So it’s not just a research firm that says, “Okay, what do you want us to ask? Let’s build you a survey.” You know, Sanjeev and the other analysts with Accelerated Strategies Group are all practitioners. They’ve done this, they’ve worked in this field, they’ve led software teams, projects, companies, they’ve consulted with big enterprises, small startups, medium-size companies. So all that to say it was really, you know, our best attempt at let’s get the best information we can when we go out and ask people for where they think they are with their maturity curve and where they really see the challenges, and we got some fantastic results. It was super, super insightful and kind of exciting to see, you know, what things we thought were true and what maybe some things were, hm, that’s a little bit of a surprise.

Shimel: Yeah. Okay. I guess you kind of opened that box now.

Ashley: Did I set it up well enough?

Shimel: Yeah. I think you got it. So let’s start with the surprises.

Ashley: You know, so one of the biggest things that everyone – I don’t want to say everyone – one of the biggest outcomes of this research was around everyone’s ability to understand the value they’re going to get from their investment, right? Spending how much money on this software IT organization, product team whatever, and what am I really going to get at the end? So it’s very clear it’s very unclear to the people funding the work, that they essentially understand what they’re going to get. You just can’t get to that information or get a straight answer.

We aren’t connected well enough into it to really understand it, which kind of goes to the second key finding was the communications around the whole software creation process is broken. It may work within a development team that’s really functioning tightly together or an Agile team with a product leader that they’re working with day to day, but outside of that, both kind of horizontally but also vertically in the organization, the perception at senior leader levels versus the individual and the team levels that are building software can be much, much different. So can you imagine making – well, we’ve done this right, Alan? – making multimillion, maybe much, much, much larger decisions based on what you think is going on and that’s not really true.

So that’s a huge issue. If we really believe in software is leading the world, that all businesses are software companies, you have to be – you’ve got to fix that. That’s got to be taken care of. And then the third area is basically all the way through the delivery pipeline and understanding the value flow. Where are you creating value and where are you actually spending energy and not getting value? Maybe getting the wrong output out of the software process. Because an example I like to use is software teams like to measure how many releases we get out per day, sometimes per hour. I mean that’s a great thing. It sounds like a really awesome thing to accomplish. But if it’s the wrong thing, wrong software, it doesn’t matter if we’re releasing it a million times an hour. I’ll take one release a month if it’s the right thing instead of a million releases every day and all of them aren’t hitting the mark.

Shimel: Yeah, I agree.

Ashley: That’s an extreme, but that’s really what it is, is understanding through that whole – and again, we’re talking about not one pipeline of work, one value stream of work; it’s across multiple, because almost every app touches all kinds of systems, data, you know, especially in a large enterprise – mainframe, stuff in the cloud, stuff that’s maybe kind of the older client server but still around, whatever it might be. So those are the three key areas that we identified that if you can assess where you are and how well you do that part of the software development, that will make the biggest difference in sort of upping your game and your ability to deliver software.

Shimel: Agreed. Agreed. You know, I guess I’m not surprised but I am surprised in that, you know, the first thing I learned about DevOps was it’s about breaking down silos, bringing dev and ops together. We’re going to break those silos. Kind of like the Macintosh 1984 commercial, remember?

Ashley: [Laughs] The girl and the hammer, yeah.

July 23, 2020
DevOps Chat: Software-Defined Storage, With StorPool

The whole Data/DataOps space is becoming very hot. For StorPool, it is more of a case of the rest of the world catching up to what the company has been doing for a while now. It is the leading distributed block storage provider globally.

In this DevOps Chat, we speak with Boyan Krosnov, co-founder and chief of product at StorPool. Boyan gives us the background on StorPool as well as a good look at the state of the distributed storage/data market.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · Storpool software defined storage

Transcript

Alan Shimel: Hey, everyone, this is Alan Shimel. You’re listening to a DevOps Chat here on devopsy.kinsta.cloud, and my guest in this DevOps Chat is Boyan Krosnov from StorPool.

Boyan Krosnov: Hi, Alan.

Shimel: Boyan, I know it’s not perfect, but it’s the best I could do with your name, I apologize. But why don’t you say it for our audience?

Krosnov: Sorry—repeat, please? I did not hear.

Shimel: Why don’t you say your name for our audience?

Krosnov: Yeah, so, my name is Boyan—Boyan Krosnov, but in, kind of for English speakers, most people say Boyan Krosnov, like, with the stresses at the wrong places, but it’s perfectly okay, you know, I understand.

Shimel: As long as they don’t call you late for dinner, as we say here, right?

Krosnov: Yeah, okay.

Shimel: So, Boyan, your company is StorPool, yes?

Krosnov: Yeah.

Shimel: And what’s your position with StorPool?

Krosnov: In StorPool, I am one of the Co-founders, one of the three Founders in the company, and my role as a Co-founder from the very beginning has been kind of the glue between technology and business and the product person in the company, the Chief of Product of StorPool.

Shimel: Sure.

Krosnov: And the other two Co-founders, you know, respectively take, are focused on technology development and the other Co-founder on strictly business, who is our CEO, right.

Shimel: Someone has to do that. Okay.

Krosnov: Someone has to do the business stuff, yes.

Shimel: Someone has to. Before we jump in, Boyan, to what StorPool is about and what you guys do, why don’t we talk a little bit about your own personal journey? How did you come to found StorPool? What’s your background?

Krosnov: Yeah, right. So, back in the ‘90s, I used to do competitive programming, so like, from a fairly early age, I got very interested in informatics or computer science, right? And from that, later on, I went into networking and ISPs, later on, I had a startup around something called packet processing and nowadays software-defined networking.

And from that, at the later stages of that startup before we folded that, we found this gem of an idea of software-defined storage before it was called software-defined storage, right? So, we didn’t know it was called software-defined storage; the term wasn’t coined yet. That’s, like, in 2011.

Shimel: Mm-hmm.

Krosnov: And, from that, we founded StorPool. So, I got with the other founders and did, like, a whiteboard exercise of what an ideal storage system would look like. And that became the architecture of our product afterwards and we’ve been building on that for the last years, right? It’s eight years now.

Shimel: Yeah.

Krosnov: And along the way, we got—yeah, so, I’ve lived in a few places, not just in Bulgaria. I’ve lived in Iceland and the U.K. and Malaysia and a few others. And so, in StorPool, you know, we started with the idea, implemented it, got it to first production use some five, six years ago, right, and since then, we’ve been expanding it in a very kind of real business organic way, meaning pretty high growth, but at the same time, very customer-oriented. So, it’s very—the things we build into the product are things that our customers demand, right? It’s not like a completely greenfield.

Shimel: Yeah, everyone already has some data.

Krosnov: We do stuff that matters for our customers, right?

Shimel: So, Boyan, listening to your story, I’m reminded of my own. You know, I got into technology in the mid-‘90s when the web first started coming in, it was just starting to get commercial, and we were storing websites. It wasn’t called hosting. I thought I was a virtual real estate person, [Laughter] because as I needed more land, I put another hard drive in the machine, right?

Krosnov: Yeah.

Shimel: And by about 1997, people started calling that web hosting.

Krosnov: Yeah.

Shimel: And we sold the company in 1998, we ended up doing a whole IPO and that whole thing. But, you know, at the end of the day, what we were doing is, we were just, we were storing people’s websites. I was selling virtual real estate, renting virtual real estate out. And it sounds like a similar thing you, before there was a thing called software-defined storage, you recognized that there was a need in the market for people to do, to be able to store stuff without the expensive, I mean, you know, back—I remember in those days buying EMC boxes, right?

Krosnov: Yeah, yeah.

Shimel: And some of the Sun and IBM—was it IBM Sharp? I forget. But all of these huge SAN—you remember the days.

Krosnov: Yeah.

Shimel: Millions—millions of dollars in SANs and all of that. And then, [Snaps fingers] it was like a flip—like a switch flipped. People started saying, “Wait a second, we could do this in software, for a lot less money with a lot more advantages.”

Krosnov: Yeah, yeah.

Shimel: And it sounds like StorPool happened to be right there at the right time when this was coming together.

Krosnov: Yep, so, kind of the reason we started it was a few conversations with, actually, hosting companies.

Shimel: Really?

Krosnov: Actually hosting companies and some banks, but it started with hosting companies, and at that time, there was this big movement in hosting—everyone wanted to be the next DigitalOcean, right?

Shimel: Right.

Krosnov: Everyone wanted to have, like, a public cloud service with virtual machines and be like Amazon and DigitalOcean. And there were architects in these companies that were trying to figure out how to do it and they couldn’t and the one piece that was missing was software-defined storage. It was, like—they couldn’t make the business model work with standard SAN from HP or IBM or EMC, right? And we had to find a solution that worked for them which runs on standard servers—like, it’s not a proprietary box.

Shimel: Understood, understood. So—I mean, but that was 2012. Now, here we are, 2020. Software-defined storage is a much better-understood term.

Krosnov: Mm-hmm.

Shimel: You know, I think it’s gone mainstream, if you will, right? People understand it and use that.

Krosnov: Yeah.

July 23, 2020
DevOps Chats: Easing WFH with strongDM

strongDM wasn’t founded to help with remote workers forced out of the office by COVID-19. They have been around for five years now. But, the company does excel at allowing you to manage and audit remote access to all of your assets including DBs, servers and clusters (as well as apps and services) anywhere from anywhere.

In this DevOps Chat we speak with strongDM Justin McCarthy, CTO and co-founder about how the company’s technology works and how it is helping companies move to remote access given current conditions.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · Make Work-From-Home Easy as Pie w/ StrongDM

Transcript

Alan Shimel: Hey, everyone, this is Alan Shimel, and you’re listening to another DevOps Chat.

Really happy to be joined on this chat by Justin McCarthy of strongDM. Hey, Justin, welcome to DevOps Chat.

Justin McCarthy: Hey, Alan — thanks.

Shimel: Pleasure to have you on here, Justin. You know, as we were talking a little bit off mic, I don’t know if we’ve introduced our MediaOps community, meaning DevOps and Security Boulevard and Container Journal, we haven’t introduced strongDM to them before. So, why don’t we start with that, Justin, and if you wouldn’t mind, in telling the story, talk about a little bit about your own personal journey.

McCarthy: Yeah, sure thing. Alright, so, first, I guess I’ll just briefly introduce myself. So, I’m the co-founder and CTO of strongDM. And the product is actually, strongDM itself is the best way to manage and audit remote access to your servers and databases and really even Kubernetes clusters. So, that’s what we focus on. We are a remote access product.

And the way we came to it is basically just a sort of typical startup story. We’ve been around for five years now, and at the beginning, it was scratching an itch just like so many other infrastructure and DevOps products out there. So, in my career, I’d always been involved in growing the teams that built the product and, inevitably, when you build a product and when you ship and when you have production data, you need to grant access to it. To analyze it, you need to grant access to it to administer it, to debug it.

And that process always felt a little bit somewhere between inconvenient and scary, right? [Laughter] And so, basically, strongDM — yeah, is the response to all those feelings of, that it wasn’t quite as smooth as it could be, it wasn’t quite as safe as it could be.

Shimel: Excellent, excellent. And you mentioned the company’s around now about five years.

McCarthy: Mm-hmm.

Shimel: That’s cool. Alright, let’s talk about — and you’re right, a lot of companies do grow out of one particular scratch to itch, and I’ve done my share of startups over the last 25 years. And what generally happens is, you find out that that particular itch may have associated itches, right, and there’s ancillary things — well, once I scratch that itch, the next itch pops up, right? To paraphrase “The Phoenix Project” or something and bottlenecks and the goal.

Talk to us—what’s the itch, and then what have you guys found over the five years about kinda getting to that itch and associated itches?

McCarthy: Yeah, yeah, definitely. So, at the core, the technical approach that it probably takes is that we are an identity-ware proxy, okay? And the first application of that was for database access. So, that’s where we started, right?

Shimel: Mm-hmm.

McCarthy: And in fact, at the beginning of time, we thought maybe that was all there was to it. But as we —

Shimel: Hold on a second, though.

McCarthy: Yeah, sure.

Shimel: So, an identity-ware proxy, primarily for databases. For some of our audiences — our security … actually, our DevOps audience probably gets that, some of our security folks do. But break it down for me, Justin — what exactly do you mean by that?

McCarthy: Sure thing. So, this is an architecture that I think a lot of folks might know as Zero Trust, a lot of folks might know as BeyondCorp, and there were a lot of examples of it out there in sort of an HTTP only case. When we originally conceived of and built the product, it was kind of even prior to a lot of that nomenclature existing.

So, what an identity-ware proxy is, it is a proxy for a given type of service. Let’s continue to use databases as the example. So, if somebody needs to interact with a Postgres database or a Microsoft SQL Server database — so, let’s say Alan needs to connect your local copy of Tableau to one of those systems, right? So, Alan would log into strongDM and then strongDM would then conduct all of the traffic, essentially, forward it to the target systems. And the identity-ware aspect is that, essentially, we know it’s Alan the whole time and we’re proxying that traffic and we’re handling, essentially, all of the routing of that traffic.

Shimel: Got it.

McCarthy: And what’s interesting about that is that you kind of get a lot of the sort of — you get a separation of sort of Alan’s identity from, you know, the credentialing of the underlying system. So, you can actually credential that separately, which means you can rotate the underlying credentials without bothering Alan.

Shimel: Now, in and of itself, can that be a security kinda setting up kinda almost a man in the middle type of situation?

McCarthy: Yeah, so, in a lot of enterprises and environments, you at some point, you have to answer the question, how are we gonna audit this particular traffic stream, right? And so, there are also a lot of products out there that are dedicated to, for example, breaking TLS, right? Being the official man in the middle, right?

Shimel: Yep.

McCarthy: So, our product has an element of that built in, although it’s not a generic TLS breaker. What it is, is it’s a protocol specific way to answer the question, you know, given MySQL database selection, what would you want to know about what Alan did yesterday? And so, our product is focused on extracting that kind of rich information about what Alan did yesterday with respect to this MySQL connection.

Shimel: Sure — great, great. Now, what made databases sort of, you know, the prime example of where to use this or as the first use case?

McCarthy: Yeah, it was the first use case, largely because, again, we were scratching our own itch. [Laughter] So, that was the one that I most often encountered.

Shimel: Okay.

McCarthy: You know, and the appeal is, it’s phrased as, you know, “Can I please have access to this because I need to debug X?” Right? And that always, whoever is saying yes or maybe or no to that request, you know, there’s a lot of hope and trust that when you say yes it’s gonna be okay. So, what our product does is, it takes all that, the sort of emotions around that event [Laughter] and tries to give you an answer for how you make that convenient and how you make that safe for everyone.

Shimel: Excellent, man — good. Alright. So, first ditch is the database and we figure that out and go from there, Justin.

McCarthy: Sure. So, as I’m sure, as you found with many products, you know, why adopt 10 different products when you can get your existing vendor to do one more thing for you and then maybe reduce and concentrate more of your attention on one tool and so, that’s where our customers pushed us. And so, the next very strong demand that we saw was, now that all of our data systems are granted and revoked access through strongDM, could you also begin to do some of the interactive session and shell-based protocols? So, the first two there were obviously SSH and Windows Remote Desktop. So, that’s where we went next.

And the theme, if you can sort of imagine it is, you know, everyone in my organization that maybe has engineer in their title or even analyst or scientist — essentially, all of those folks, they need more than just webpages to do their job, right?

Shimel: They do.

McCarthy: And so, if it were just webpages, then existing single sign-on would work great, right? But since it’s more than that, it’s deeper than that, it’s really that whole collection of use cases that our customers began asking us to take on.

Shimel: Excellent. Good stuff. And so, let’s talk a little bit about — so, how, is this sort of distributed as a SaaS kind of thing or a web-based kinda interface? How does that work?

McCarthy: Sure, yeah. I would say we are neither traditional SaaS, nor traditional on prem. So, in terms of how the product deploys, our customers end up running a bunch of it, but not all of it. So, with any system that involves credentials, any system that involves cryptography, operating it successfully and carefully is actually a huge part of getting it right, okay?

Shimel: Mm-hmm.

McCarthy: So, what we’ve tried to do is, we’ve tried to unify the sort of operation configuration. So, if you think of it like centralizing the policies, centralizing the key management.

Shimel: Yeah.

McCarthy: So, that’s the part that we host. But the part that actually runs the proxies and therefore essentially the actual conduits for all the data, that runs entirely in customer environments.

Shimel: And what kind of environment are you talking about?

McCarthy: Yeah, so, I would say our average customer, the answer is, like, several. [Laughter] So, there are very few environments where you have just one cloud, where you have just one prem data center. So, it ends up actually being several. And so, that’s another strength of our architecture and our approach is that our product, from day zero, was designed with that in mind, so you can run our proxies in Azure and in AWS and in your existing legacy data center. They all unify into one sort of access plane, and it doesn’t matter the product. The same grant access gesture applies to all of those environments.

Shimel: Oh, okay. Very cool. Very cool. And, you know, from what you’re describing, to me, it doesn’t really make a difference whether I’m a cloud native company, let’s call it, right, or maybe an old line company that had my database running in the closet, right? This kind of identity by proxy is still something I can utilize to make my life easier.

McCarthy: Yeah, absolutely. And of course, we would hope that it’s especially suited to a hybrid environment like that, because the ability to, from an end user point of view, from one of your data scientists, they just know the three logical things they need to access to do their job. They definitely don’t care what cloud it’s hosted in. They don’t care what data center it’s hosted in, but from the point of view of that end user, it just looks like one thing.

Shimel: Okay. Now, let’s look at it from the lens of COVID, which we kinda always have to look at everything today through this lens — it seems like this would be a help, right, if I just had to move my whole workforce home, you know, remote. What have you guys been seeing on that?

McCarthy: Yeah, I think our story there is pretty similar to what a lot of companies that are part of the sort of next generation of IT and — we’re sort of seeing the same trend that everybody else, more people moving remove, therefore any remote access products are, there’s a lot more interest at the moment.

So, we were always about granting access remotely. It was always a workforce that was going to be distributed. That was our typical customer, anyway. So, it’s definitely the same theme, but just more than we were seeing pre-COVID.

Shimel: Excellent, man. Now, one thing — it’s funny, I just had a conversation with another company within the IDM space, kind of in like an ED directory service, let’s call it, and this popped up. With the people working from home, with the explosion of how many apps and SaaS services, you know, we’re all accessing right now, it’s great to be able to have just a single proxy, if you will. So, I only have to worry about really going once and then on the back end, it connects to all of these services, let’s call them, or apps.

And so, from my point of view, that’s a great thing. From your point of view, Justin, right, now you’ve gotta hook into all of these different, new apps and services. How do you do that? Is that via API? Is it a one-off for every one you’ve gotta go into? You know, what’s involved there if I bring you — you know, some app you guys haven’t encountered before?

McCarthy: Yep, sure. So, I do, there is an important distinction here. There’s a generation and a category of products that you might call them cloud brokers, right? So, cloud access security brokers, that category where you have a workforce that needs to access Salesforce, needs to access another SaaS application. We consider that sort of part of the market to be something that’s necessary but not our specialty.

Shimel: Not your place.

McCarthy: Yeah. So, our specialty is, again, it’s that staff where there’s probably an engineer or somehow technical, there’s a technical name in their role somewhere, and they need access to things that aren’t webpages. And so, for that, the procedure is — hey, I’ve got this maybe let’s say even legacy database or I’ve got this type of terminal access that we do that, let’s say we’ve got a lot of machines that are connected via VNC or something. So, and let’s say that’s not on our official supportive protocols list yet. It’s as simple as, we do an intake, we understand the protocol, we add it to the product — that’s it.

Shimel: Okay. So, you guys do that. I don’t do that myself. I don’t have to kinda write to an API or something and make —

McCarthy: Yeah, no, exactly. Any system that feels like any sort of client server access paradigm, we can model it in our, essentially in our platform, and then begin granting access to it.

Shimel: Okay. Almost out of time, Justin. One more area I wanted to hit on this one, though, and that is — talk to me about what to set up here, right? Whether I’m doing it on the cloud, prem, a little of both — how big a job is it to get this thing up and running?

McCarthy: Yeah. So, we also, of course, have the advantage of — like I said, we’re five years old, but that means we’re only five years old. [Laughter] So, we knew it had to be easy, right? Yeah.

So, yeah, the act of deploying our proxies is essentially roughly turning it on. Because what then the proxies do is, they take over, for example, topics like discovery. So, they discover what host names they can access and they begin exposing it back to it in the administrative console. So, that’s the one aspect that, you know, deploying it is pretty much turning on the software.

Additionally, because so many of our customers rely heavily on automation for their DevOps, another way to think of it is, if you already have, if you already have a great Terraform setup that you’re happy with, you have a great cloud formation setup that you’re happy with, we are gonna integrate natively with that setup as well. So, it’s going to be, you’re essentially the overlay, your proxy overlay on your existing infrastructure is gonna go in and it’s gonna feel exactly like anything else that you’re familiar with deploying via Terraform or inside your Kubernetes cluster, for example.

Shimel: Perfect, man. All good stuff. Justin, I promised you we were gonna do 15 minutes, but I blew it — but not too bad. We’re not too bad. Well, we’re gonna have you back on. It’s gonna be a little bit of a continuing series, right? So, look forward to our next conversation.

You know what I realized? We didn’t even mention the website, though. So, for people who want more information, it’s strongDM, S-T-R-O-N-G-D-M-dot com, right?

McCarthy: Yep.

Shimel: And then can get, if they wanna go check stuff out there. And we’ll have you back on real soon and continue this, man. Sounds great.

McCarthy: Great. Alright, thanks a lot, Alan.

Shimel: Alright. Justin McCarthy, CTO and co-founder of strongDM here on DevOps Chat. Hey, this is Alan Shimel, and you’ve just listened to another DevOps Chat.

June 19, 2020