devopsy.kinsta.cloud

Tag: change management

  • Change and Order

    Change and Order

  • Change Management in a Fast-Paced DevOps World

    Change Management in a Fast-Paced DevOps World

    While DevOps speeds up software release cycles, change management often slows them down. So, how do you do change management in a fast-paced DevOps environment? Change control enables organizations to meet compliance and governance while managing changes at the speed of business.

    In this interview for TechStrong TV, Greg Sanker, former CIO, IT Operations specialist, author, speaker and contributor to the “ITL4 Change Enablement Guide,” joins us to share his views on the tremendous impact of Agile, DevOps and CI/CD on traditional change control teams. Greg talks about the new role of change control and his contributions to the “ITL4 Change Enablement Guide.”

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript: Change Management in DevOps

    Mitch Ashley: Well, I have the pleasure of being joined today by Greg Sanker who is former CIO, operations specialist, he’s a speaker/author, a bit of a futurist in leadership and digital transformation. He’s also a contributor to the “ITIL4 Change Enablement Guide” and a reviewer of a lot of other content—so, long introduction, there. Welcome, Greg, to [Cross talk].

    Greg Sanker: Yeah, wow—thank you. That’s kind of awesome. Thanks for having me. I appreciate being on the show. I think we’re gonna have—

    Ashley: It’s always—always good to have a fellow musician. Anybody with a Telecaster in their background can be on this any time you want.

    Sanker: Yeah.

    Ashley: So, tell us, [Laughter] in addition to your wonderful guitar sitting behind you, tell us a little bit about yourself.

    Sanker: Well, you mentioned, I am—I specialize in IT Operations. That’s what I’ve done for more decades than I’d maybe like to admit. But service management has been a core part of that, and it’s become really clear to me that my view of service management is a lot more streamlined and agile than a lot of people perceive it as. And so, I’ve begun speaking at conferences and whatnot. I have a book of my own that’s published—I’ll let you guys go find it if you’re interested—about change management.

    But most recently, I was asked to work on the ITIL project on a number of ways, but most notably, the change, what we now call “Enablement Guide.” And one of my prerequisites to get engaged with the project was, if you’re gonna ask me to write it, I’m gonna write it the way I see it, which is very different than what we’ve been doing in the past, and we’re gonna be pushing it forward, so. So, that’s a bit about me.

    Ashley: That’s wonderful. That’s definitely a consistent theme with ITIL4 and other folks, Mark Smalley and others that we’ve talked with is really recognizing—I think ITIL’s had its sort of process moniker, right?

    Sanker: Yeah, pretty much.

    Ashley: But there’s a huge emphasis on, you know, how do you fit ITIL and all of the aspects of operations into something that is more of a dynamic DevOps-y agile kind of world, if that’s a way to describe it. And not to say that it didn’t fit in before, but I think it’s making it more prescriptive in that kind of setting is what a lot of the good work that you and others have done.

    Sanker: You know, I was an early embracer of DevOps, and part of the reason for it is the mindset that explores possibility that ignores the boundaries in an organization to achieve outcomes. That’s, like, music to my ears—I’m all in. So, it’s a match made in heaven, but I can mention, it’s like, there’s a lot of organizations that have adopted service management, they have used ITIL in ways that are very prescriptive, very heavy weighted, very bureaucratic and slowed down. And it was never intended to be that way.

    Ashley: Mm-hmm.

    Sanker: It just is, it got adopted that way, right?

    Ashley: Well, and I think a lot of the work that’s gone into ITIL4 will help make some of that shift.

    Sanker: Yeah.

    Ashley: Certainly, it’s positioned that way, and I know from other authors, that was the mindset of how the contributions were made. Now, you specialize around change management and we were chatting when we first got introduced about, you know, how do you do change management in a rapid development, agile, DevOps kinda world? If you were gonna be ask that at a conference by somebody, how would you—what guidance would you give them?

    Sanker: Wow. So, I’ve got an hour and a half platform, right, for that?

    Ashley: [Laughter] At least an hour and a half compressed into 20 minutes, yes.

    Sanker: Twenty minutes, right? Yeah, absolutely. Well, see—well, let me put it this way. I think it really comes down to one fundamental paradigm that we need to change is, traditional change management, which is what I call your CAB-based, you know, Razor request for change, blah blah blah, is based on the idea that we inspect every single change. And as you probably know, Edwards Deming’s said many, many decades ago, “We’ve got to cease reliance on mass inspection to get quality products.” Well, that’s exactly what we’re doing when we say, “Hey, I need to make a change. Well, let’s just take a look at it,” you know, so on Thursday, we’re gonna get together and look at that. But you know full well that, in a DevOps environment or a continuous integration, I mean, we are moving all the time. We don’t slow down and stop.

    And so, that mindset, just the mindset of stop and let’s inspect is completely incompatible with a flow-based, whether it’s agile or DevOps or CI/CD or any of the others that are out there that are more flow based—you know, rapid feedback loops, short cycles, et cetera—it’s just incompatible.

    And so, what we have to do is elevate out of the inspect mindset into the expectation mindset. And that is—what is it that this organization needs from change management? And some of it’s governance and compliance, some of it’s operational stability and recoverability and some of those kinds of things. But let’s state what that is, we’ll state what those things are for the organization so that those that are working in the pipelines, the value streams can actually optimize how well we achieve those expectations and don’t dictate how they do it, let’s just dictate what the outcomes that are required by the organization. That’s the fundamental shift, and it’s big. I mean, it’s more than a 180-degree shift. It’s very significant.

    Ashley: Definitely a different mindset for sure, you know, the inspection versus not. It’s not unfamiliar, though—that’s what security is doing about shifting left and moving ______.

    Sanker: Yeah.

    Ashley: Iterating the process, DataOps is also—you know, everyone wants to move early in the process, but it’s more than that, because you’re talking about a pretty different mind shift change. So, talk about compliance. Talk about governance from a change management standpoint in this new paradigm.

    Sanker: Yeah. So, you jumped right to the jugular. That is the million dollar question.

    Ashley: [Laughter] No, but it needs to be done and, you know, we all sort of pooh-pooh it.

    Sanker: Right.

    Ashley: But you know what? If you don’t do it, it’s really not fun doing it at the end, right?

    Sanker: So, maybe you remember, because it certainly rattled my world—Dr. Forsgren said on stage at DevOps Enterprise Summit 2018, “CAB is useless.” And everybody in the audience laughed and cheered and duh duh duh duh duh.

    Ashley: You’re not talking about Cabernet, you mean change advisory board.

    Sanker: No. [Laughter] I bet you probably would enjoy a good Cabernet, and I’d—

    Ashley: CABs, yeah. Those others are still good, but anyway.

    Sanker: Merlot, et cetera, they’re all good. But the thing is, she’s not wrong. But she was looking at it from a very specific lens, and that lens was about failed changes—in other words, the success of changes and the recoverability of changes, two things that are really important to the stability of the business. And what she found in the data, she’s a data expert, she has a Ph.D. in this, so there’s no mistake, here.

    She’s absolutely right—however, CABs frequently are part of the compliance equation. In other words, it’s useless for those things, but it has a use elsewhere in the organization, and for many organizations, that’s a very scary thought. Because that’s where we’re able to document and demonstrate for internal and external auditors and validators—are we doing the things that we’re required to do? PCI DSS, HIPAA, GDPR—you know, all of those other compliance framework, NIST 800-53, which hopefully we’ll get to in a minute, but they all have requirements around managing changes within your organization. So, if we don’t do it in the CAB, how do we do it? And that’s precisely the point.

    So, what I’ve sought to do is help organizations build those compliance points into the pipeline itself. In other words, we can point directly to where that’s being done in the pipeline and don’t require a “let’s slow down and actually check the box, here.”

    You know, the governance is—well, can I just say this? There’s a difference between governance and compliance. They’re two very different topics, right?

    Ashley: Yeah.

    Sanker: So, governance is about how organizations make decisions, and making sure that those decisions that are made throughout the organization align with or help fulfill the purpose of that organization, whereas compliance really has to do with the conformance. Are we conforming to applicable standards or expectations, either that the organization has or we have externally?

    So, but when we talk about governance and compliance, we think about performance and conformance. I’m sure you’ve heard that—COBIT and lots of other frameworks have talked about that for years. But performance is about, you know, your strategy and are you utilizing your resources in pursuit, or are you producing value or value creation? And I think that’s fascinating.

    I’ll bet you’ve read or heard of Mark Schwartz’ new book, “The Art of Business Value.” It’s a fascinating read.

    Ashley: I actually haven’t read that one. I’ll have to check it out.

    Sanker: I would put it on your reading list, and I know that sometimes he rubs people the wrong way. I found out that he rubs me exactly the right way, because he asks some really challenging questions, like, “What is business value?” You’d think that’s an easy question to answer, right? It’s like, you know, for a for-profit corporation, it’s like, you know, making your market windows, making your profitability, adding features that attract and retain customers, those kinds of things.

    But what if you’re in—as I was as a CIO—what if you’re in a government agency? That’s not a for-profit organization, so what is business value? Delivery of services to citizens, upholding environmental standards? There’s a lot of things that governments do, but they’re not profit motive. In fact, in some cases, it’s not even financial, so what is business value?

    And so, when we’re running our backlog, you know, we’re scoring our user stories, like, how do we score that in that kinda context? And then, just when he, when I thought that he had confused me enough, he asked, “Well, what if your business strategy”—and I don’t wanna give away his book. Go buy his book. But—

    Ashley: No, just tell me the last chapter, that’s all I need.

    Sanker: Exactly. [Laughter] I actually sent him an e-mail. He’s a great guy and he thinks very, very big. But one of the things that he said was, “Well, what if your strategy is, we want to move customers off of this platform and onto one that’s more profitable to us, or one that’s in alignment with our roadmap and our strategy?”

    So, if we’re down in the value streams or in the pipelines, scoring our user stories against customer satisfaction, customer value, things that customers really, really demand and want, we’re actually creating negative value—these are my words, not his. We’re creating negative value because we’re making our customers like the platform that we want to get them off of.

    Ashley: Mm-hmm.

    Sanker: So, business value would actually be—no, do things that make them less likely to like this product. Make them want to migrate. Make it easy for them to say, “You know, this is really getting old. I’m gonna try your news service.” And so—

    Ashley: Right, that behavior change.

    Sanker: Yeah, exactly. And so, when we really start thinking about, we’re getting, you know, your governance, especially your governance and your compliance, we have to have adaptive, rapidly adaptive systems that allow us to, at any point in time, understand what the current strategy is and how it affects the decision making that we’re doing at any point in time—all without, of course, getting your board of directors involved with every single decision throughout the organization.

    Ashley: Well, let me ask you this. I’m really interested, I’m really curious about how you take this kinda shift in mindset and how you’ve woven that into the “Change Enablement Guide“ that you were the author of. So, you know, it isn’t a process discussion.

    Sanker: No.

    Ashley: You’re talking about viewing things a different way, valuing some things maybe we didn’t value before, maybe some other things less, and maybe delivering a different set of things. Let me just share, briefly. I remember a day, probably not too long ago, where CABs saw their role as saving us from developers and all the bad decisions and lousy code they were gonna create, so that’s what—

    Sanker: [Laughter] Oh, yeah! Absolutely.

    Ashley: – that’s what they say in those CAB meetings.

    Sanker: Yes. Oh, absolutely.

    Ashley: But, you know, that’s not what we’re talking about. Tell me how—so, how do you build that into, in a way that’s gonna help people make that shift through ITIL4?

    Sanker: So, thank you for saying that, because there is some unspoken or lightly spoken or spoken only in factions kind of frustration, there. It’s like—let’s be honest. I used to be a network engineer, I did network security, I did all things network. So, I used to be a change manager at one point in time, and who the heck are you, Greg, to cast judgment on this piece of code and decide whether that’s gonna work appropriately? Everybody knows that I can’t add value to that, and everybody knows that this external body who’s not familiar with it, certainly not at the pace—you can’t add value, and yet you act like you do. And that just—that doesn’t sit well with anybody.

    So, we really need to, if we shift our focus to, “What is it that we’re trying to achieve?”—so, I talk about putting the right measures on the pipeline. How well is this pipeline producing outcomes, those outcome expectations? Is it producing consistently high quality changes? Is it consistently not delivering failed changes—or, for the failed changes that do go through, how quickly and easily can we recover from that with minimizing impact to the customers?

    Those are the things that your CAB or whatever your body is should care about, not the individual changes. You’ve got to get away from the individual changes. You can’t add value to that.

    And so, I get asked a lot of the times, it’s like, “Well, what do we do with our CAB?” since, you know, they’re very unpopular. And in some cases, the best answer is—now I’m gonna say it publicly, so I’m gonna be quoted on this, but—“Blow it up. Just get rid of it. And don’t ever use the C-A-B word again, because it has such a bad name.”

    But it isn’t without value. So, if you have a CAB and the CAB starts saying, “Look, developers, we can’t add value to what you’re doing, but what we really care about is some of these things. So, let’s talk about those things.” And if you’re talking to, particularly DevOps, agile, automated pipeline folks—they were gonna welcome that conversation because they’ve already got it covered. They just do. You know, like you know, I’m the change manager—“Well, have you tested that code before you released it?” Well, dude, that’s the only way it gets in production, if it passed tests. There’s no way for it to make it into production. So, not only is it insulting, but it’s a dumb question, and undermines your credibility.

    Ashley: Well, let me ask you this, then. I think where you’re going—and tell me if this is right—is, “We have so much automation in this pipeline process, right? That’s the whole idea of being able to produce software more reliably, more rapidly.”

    Sanker: Oh, yeah.

    Ashley: There is so much data that’s generated and captured, but not leveraged.

    Sanker: Yep.

    Ashley: We treat it as data exhaust, right? That’s sort of this fancy term for it.

    Sanker: Yep.

    Ashley: In that is a lot of compliance, is a lot of governance information—

    Sanker: Yeah.

    Ashley: – that you can then elevate and connect, and basically save developers time and not having to produce reports at the end. “I’ve already got three-fourths of what I need or what you need, and let me help you put the finishing touches on it so you’ll sail through the next whatever NIST whatever it is.”

    Sanker: Yeah.  So, there, you get to write a chapter in my next book, because that’s exactly, exactly what we want to focus on is, we want to be—you know, alright, this is potentially controversial, but change management is a feedback loop. It helps us understand the quality of changes that are coming through our pipeline. Sitting there and passing judgment and saying, “Nothing passes until I say so”—that’s not adding value. That’s absolutely antithetical—you know this—to the DevOps continuous flow kinda mindset.

    Ashley: So, they’ll go every way around you you can think possible, you know?

    Sanker: Yeah, and the other thing, as we well know, is like, develop is most frequently used in the flagship products. “This is the core business. Get out of our way. We have to deliver these changes to maintain our profitability, maintain our market windows—all of those things that are core to the business, and you think I’m gonna stop for three days when I went from, you know, a user story to a value in under 24 hours in some cases? There is no way I’m gonna stop. I’m just not going to. I will take the risk of it failing and you saying, ‘You shouldn’t have done that.’” And that’s—

    Ashley: You can talk to the chief product officer about—

    Sanker: Exactly.

    Ashley: – the stock’s direction. [Laughter]

    Sanker: And I helped an organization who was, you know, they had agile coaches and they were doing all that. It’s a large company, but I’d rather not name them. And I was asked to come in and look at their change management.

    Well, what they had done was, rather than having one CAB a week, we were having daily CABs. And we were having daily pre-CABs and then the CABs. And one of the things that I tried to get them to understand is, these two are entirely incompatible. If you’re going towards agile DevOps as a development methodology, then you must move away from CAB. CAB has got to go.

    And what was interesting is, their flagship products, the ones that really made money for the organization, they could get away with murder. Why? Because it was so critical to massive revenue in the case of this organization.

    Ashley: Mm-hmm.

    Sanker: And so, we have a big outage, we recover, we move on, that’s okay, it’s an acceptable risk. And change management will still know, we can’t have any defects or whatever in production.

    And so, we’ve got to get ourselves wrapped around the idea of managing business risk. You know, you mentioned something about the compliance, and just this last week—like I said, I’m working on a new book, but I was looking at the NIST 800-53. Everybody’s familiar with it, but they finally released version 5. And so, I’m reading through and the author’s made a very fascinating statement, and I encourage everybody to go look at this. Version 5 is phenomenal, because what they said was, “We have eliminated or reduced the specification of who actually does the activity, and we’ve instead focused on the outcomes that need to be achieved.” In other words, some of the compliance requirements or the controls said, “IT will review” or, “The change manager will review.” And so, if you’re gonna comply with NIST 800-53 previous versions, there’s not a lot of wiggle room around that.

    But I’ve been saying for over 10 years and others have been saying, it’s like, if we focus on the outcomes, then who’s doing it, how they’re doing it is open for us to do it in the most effective way. And that gets us into the pipeline space. And it’s a major step forward, because we struggle with that. Like you said, we have to meet our compliance, you know? If you’re dealing with sensitive information, you know, pharmacy has HIPAA and credit cards and all that sort of stuff, you have to. It’s just not optional. But you don’t have to do it the way we’ve always done it, and that’s the piece that I like to bring to organizations. It’s like—how are you doing it, and can we demonstrate that we’re doing it? Those are basic audit business controls minimums.

    Ashley: I’m curious about, we’re sort of talking also about the whole issue of agility and speed, and on the other end of it of the belief of the best way for something to be stable is don’t change it.

    Sanker: Oh, yeah, absolutely.

    Ashley: Which is antithetical to the environment we’re in, for sure. And so, it’s kinda like you have to embrace, you just have to say, “We love change, and how do we be super effective at it?” instead of, “How do we not change so we don’t mess it up?”

    Sanker: So, there’s two places, two things that I’m gonna mention briefly, but we won’t have time to explore them. There’s the field of study around complex, you know, and Cynefin is one of the most notable frameworks. And the idea that there’s simplex, complex—or complicated, complex, and chaotic, and we treat changes frequently like they’re either simple or complex. Meaning, we need to get some eyeballs on this thing.

    But the fact of the matter is, most systems, especially systems that we’re DevOps-ing, are more like a complex adaptive system. There’s a level of complexity that we’ve not seen in days of old, like back in the ‘80s and ‘90s and early 2000s where these systems were, we could actually try to understand them. Modern system—

    Ashley: They’re not linear. They’re more, you know, dynamic and self-creating, if you will, in run time.

    Sanker: Yeah, exactly. So, that hit me a number of years back. It’s like, this whole mindset, it’s around the idea of, it either is simple or it should be simple, and we can understand it, and we can predict the outcomes, and you can’t. You cannot do that.

    And so, we need to build adaptive systems that say, “Hey, look, this is complex.” And you’re not gonna send it to a board of examiners, you know, a CAB who are gonna say, “Let’s take a look at all the risk,” because it would take you years to do that in a complex system. That’s just—that’s not gonna happen.

    So, we need to adopt practices that are more adaptive. And one of the things in that complex area within the Cynefin framework says that we need to run some experiments to better understand the mechanism. And how that applies to change management—see, this hit me between the eyes because it was like, “No failures in production. No failures will be allowed”—that’s antithetical to learning how the system works. If you don’t make some changes to see how the thing works in operation, you’re denying yourself learning and you’re probably deluding yourself that you’re actually actively controlling it, right?

    The other piece of study that I’ve brought to the table is—and you’ve probably heard of it—this study of anti-fragile. There’s a number of authors whose understanding is astronomically higher than my IQ, you know, Ph.D.s who actively debate such things. But I take complex things and make ‘em simple. Here’s the thing—some things, like a tree, when the wind is blowing, the tree is waving, but there’s more than that going on. It’s the actually fibers, the plant itself becomes more resilient to wind if it’s been exposed to wind.

    Here in Oregon, often there’s logging operations that have a lot of controls for the environment—trust me on that. It’s changed a lot since the good, ol’ days. But one of the things that we do hear is, we leave a segment of trees at the edge of a piece of property that’s being logged, and we do that for the animals, for the environment, we protect the riparian areas. But one thing that you’ll notice is, within one year of leaving that stand of trees that used to be next to a large strand of trees—they break. A storm comes, and they get hit. Why? Because they’ve relied on the strength of their neighbors up to this point, and they’re not suited to stand the wind alone, and so those trees break.

    Here’s the thing—if we don’t inject some failure into the system, for a system that is truly anti-fragile, we’re actually making our systems more fragile. And so, a mindset of change management that says, “No errors, no problems, no failures ever, ever, ever”—you are making your system more fragile, and you’re treating a complex system like it’s simple. And so, we’ve got to change our mindset.

    Now, you know full well—and let me just blast into this—you know full well that, as we take these mammoth changes that we used to make in the old days, you know, it took 6, 8, 12 months to produce, and we’ve turned it into these microscopic things that can go through your pipeline and ours and produce values is your blast radius. What bad thing could happen in production has materially changed. The risk has become very, very small. If that—

    Ashley: And your ability to fix it—

    Sanker: And your ability to fix it skyrockets.

    Ashley: – your responsiveness, it isn’t six months to fix it or three, it’s three minutes.

    Sanker: Yeah. So, one of the change outcome expectations that I encourage people to establish is, what are your expectations for recovery from any given change, and can we realistically do that?

    So, for instance, if I put something in my flagship product that doesn’t work as desired, if I can recover within two minutes, no harm, no foul, is that okay? In a lot of cases, it is. If it’s a defibrillator keeping somebody alive—probably not, that’s probably not okay. But in a financial transaction or a video streaming service or whatever, you know, modern digital services, it’s probably okay, especially if you’ve engineered the release in such a way that you do it like that. You know, blue/red switches, on/off—all of that kind of stuff that we’re engineering in become, you start seeing why we’re able to do that and what that actually does in production. It’s wonderful.

    Sorry, you got me excited about that.

    Ashley: Yeah, boy, I could take you a lot of places with that. [Laughter]

    Sanker: Yeah.

    Ashley: So, let’s take it back to someone who’s gonna pick up a digital version or a printed version of the “Change Enablement Guide” author.

    Sanker: Yeah.

    Ashley: How is that approachable for folks? Let me be honest. I’m probably not gonna go download that to get my heart pumping to go work out, get a better workout—or maybe I will.

    Sanker: [Laughter]

    Ashley: Maybe after listening to this, I will—but how do you make that engaging for people?

    Sanker: Yeah. Well, so, one of the things—well, I’ll put it this way. It’s like, we’re not selling a product, we’re selling an opportunity to solve some problems. That’s why we call it best practice, right? And there’s a lot of best practices, and I don’t feel like they’re nearly at odds as maybe some of the industry might feel like.

    But change enablement is—and I’ve been saying for years that this day has come and it’s now here is, change management is in the crosshairs of modern digital organizations. It’s a pesky remnant of days past. And what the “Change Enablement Guide” is—and there are was more. I mean, for production reasons, I had to kind of limit it. But what I wanted to do was point in this direction of what I’m talking about. It’s like—let’s get people moving towards that. Because like you said, we’re not gonna change overnight. I’m not gonna read the “Change Enablement Guide” and go back to work the next day and say, “Alright, I can save all the world’s problems.”

    And so, what I’ve subsequently started doing is writing guidance around, “But what do I do today? You know, I went to a DevOps conference, I’m excited, but what do I do when I go back to work? How do I start moving in that direction?” And blowing up the CAB, while we might all celebrate that, that’s not a good first step. Instead, what we need to do is start moving ourselves in a better direction. It’s not more of same, it’s—what do we actually need to be doing here, and what’s the best way to accomplish that?

    And it’s difficult, culturally, because it becomes more of a culture. Like you said, there are CABs galore who despise developers probably as much as developers despise CAB. It’s a match made in—

    Ashley: Cats and dogs, living together.

    Sanker: – yeah, exactly. [Laughter] Good reference. And so, that group of people who are widely known for having that kind of mindset are not gonna be welcome when they show up to your spring and say, “Hey, we’d really like to be involved earlier in your change management so that we can help you.” It’s like—yeah, sorry, bud. Let’s start somewhere else.

    So, if change management starts with, “We’ve gotta get out of your way. We’re gonna start delegating more and more of your changes into your value stream, and instead, we’re gonna be focusing on, we’re gonna partner with you on, let’s look at the results of what you’re doing. Because we believe that you are optimizing your delivery and we believe that you have the right tools and controls in place.” So, we are moving more towards, “Are we achieving all the outcomes that the organization has? Is the organization even clear on what those outcomes really, really are?”

    You know, the one that always—I love this one—“All changes must be tested before going into production.” It’s like—well, how many shops have you been in where that’s not true, at least in modern times?

    Ashley: Mm-hmm, yeah. I call that the “meh” policy. “We’re gonna test it? Meh.” No, of course we’re gonna test it.

    Sanker: Yeah, we call it blow testing, right? You know, it’s like, “Eh, okay, I think we’re alright.” That is true. In modern terms, though? For flagship products, for things that are really, really core to the business, most organizations have some form of automated testing, or that’s just part of the process. So, rather than make everybody say, “Did ya test it?” at a CAB, just, like, “Hey”—

    Ashley: “Of course you did.”

    Sanker: Yeah, exactly. Is that happening in the value stream? If it is, I’m not—don’t worry about it. We’ll just move on. Is somebody with the appropriate authority approving that? And that’s—I am gonna take a minute to talk about this one, Mitch, is that everybody talks about change approval in terms of who’s gonna approve this idea going into production, this change going into production? Because if something goes bad, we wanna know who to blame, right? In fact, we used to say, “Who has enough—who is sufficiently authority that they’ll get fired if something goes bad?” Which is, of course, the wrong question.

    Ashley: Yeah, [Cross talk].

    Sanker: Because the right question is, “Who has enough authority that, if it goes bad, they don’t get fired, because they have the authority to put on that level of business risk?” Right?

    But if we move—and we could talk for hours, but the idea of product ownership or taking a product view of services or modern systems is, “Isn’t it true that the product owner is accountable to the organization to decide what things we’re going to move into production?” So, to me, that’s the change approval. We’re approving that we want this change to happen.

    So, nobody’s adding value by making approval at the end of the chain. We’ve already decided that. We already know that we’re gonna make this change.

    So, those are two different approvals. One of them is about a product decision or a governance decision, the other is about a business risk decision of, “Is it actually going to achieve the results that we set out to do?” I believe that most of the latter can be automated. If it’s passed its test, if the testing systems are appropriate, if we’ve done—in some cases, I love peer reviews. It’s like, you know, the code needs to be reviewed by a peer, stamp it, and we ship it out. It happens in a minute or two, you know, not hours or days or whatnot like that.

    So, I think as we kind of retool or thinking around it, I think that’s where we can start really solving actual problems that organizations have.

    I am reminded, though, I saw this—you’ve seen these before, these overhead views of an Indy car or a Formula One car coming in for a pit stop and all this stuff happens and off they go. I saw one this week that was 1.8 seconds. It was awesome, right? And people like thus always share those on social media of, like, “That’s an agile organization, doing the things” and blah blah blah.

    And so, you can’t really argue with 1.8 seconds—four tires, top off the gas, and out you go.

    Ashley: Impressive.

    Sanker: But the question, to me, is—like, I’m a bit irreverent. Why isn’t it zero? Why can’t we make it zero? If faster is better, let’s make it zero. And the answer is, we won’t make it to the end of the race unless we have fuel. We won’t make it, because [Laughter] when you’re racing at 200 miles an hour around corners, your tires literally don’t last that long. It’s not a matter of preference, it’s a matter of life and death, right? So, we have to change tires.

    So, the question isn’t, “Are we balancing speed and agility against risk mitigation?” It’s what it is that we’re trying to accomplish here. And in the case of Formula One, we’re trying to win the race. And to do that, we have to take on certain activities that cause delay—that’s a requirement.

    So, the question isn’t, “Do we have to take a pit stop?” We do. We need tires and we need fuel and sometimes minor adjustments. So, the question then becomes, “How quickly can we achieve those outcomes?” And putting four tires on in under two seconds—that is phenomenal. Hats off to those folks that are doing that. And how do you get however many gallons of fuel we put in a Formula One car in two seconds, I don’t know, but that’s amazing, right?

    And I feel like that’s the mindset that we need to adopt. We need to quit asking, “Why do we have to do change management?” We have to do change management because part of it is to be compliant. That keeps us in business. That keeps us out of trouble.

    Ashley: But it’s a really good example, because it’s not an absolute, it’s not, “Do we need to fuel?” but, “What’s just enough fuel for us to win?” right?

    Sanker: Exactly. Oh, and trust me, you’ve watched it. I know, I can see it in your eye, you watch Formula One or Indy and there’s like a thousand computers over there and stopwatches and gauges and dials and they are calculating exactly how much fuel based on the game strategy or the race strategy, the conditions, who they’re up against, what they think their strategy is—that’s how much fuel we need to take on, right? So, it’s—

    Ashley: Great model for us to think about of, you know, it’s not absolute quality or absolute whatever.

    Sanker: Right.

    Ashley: It’s what’s appropriate for the organization. We’re gonna have to leave it at there.

    Sanker: Okay.

    Ashley: And I want you to come back some time, because the next topic is Stevie Ray Vaughan or Eric Clapton. But I’m gonna—

    Sanker: Oh!

    Ashley: You can’t answer it. You have to come back and answer that, so we’ll have you here another time. It’s been a real pleasure talking to you, Greg Sanker, who is the author of the “Change Enablement Guide” of ITIL4. So, I think you really gave us some compelling reasons to go check it out. So, thanks a lot—it was great talking with you.

    Sanker: Thanks for having me, Mitch.

    Ashley: You bet.

  • Low Code and Change Management with Max Rudman

    Low Code and Change Management with Max Rudman

    Many organizations trying to accelerate their digital transformation are turning to low-code technologies to respond quickly to the constant market changes. Low-code technologies facilitate application development by offering drag-and-drop components that require little to no hand-coding. Low code creates a seamless integration between cloud platforms, tools and utilities.

    As low-code applications increasingly become a shared responsibility between IT and business units, it’s incumbent upon IT to ensure changes are delivered consistently, reliably and without disrupting end users — no matter who makes the change.

    In this Q&A session, Prodly CEO Max Rudman answers a few questions about low-code applications and change management.

    Max is one of our distinguished speakers presenting at Low Code Today Virtual Summit. During his session, Max will discuss how to implement an agile change management process to low-code applications and accelerate time to value for low-code apps.

    How do low-code applications boost productivity?

    The simplest answer is: It’s just faster to configure and make changes to low-code applications. Low-code apps leverage declarative programming, meaning you assemble a solution by dragging and dropping predefined components together like Lego blocks instead of writing code line by line. Everyone knows how to use Legos, which brings us to the far greater productivity benefit of low-code apps — they expand the number of people on your development team.

    Low-code applications have given rise to the citizen developer — someone who deeply understands the business problem and how to design the desired solution but previously lacked the programming skills to make it a reality. With low-code applications, business analysts, project managers, operations teams and other business users are empowered to implement solutions for themselves. Consequently, technical developers have more time to focus on projects that require specialized skills. Because developers are now able to focus on tasks that really do require programming expertise, they become more productive, too. It’s a win-win for both IT and business.

    How does low code drive change management? How can you carry out an effective change management process?

    Low-code applications highlight the need for change management within an organization, especially as application configuration and maintenance becomes a shared responsibility between IT and lines of business. This should not be a free-for-all approach to application development where anyone can make changes to applications at any time. More and more businesses rely on low-code apps to manage critical and often complex business processes, like revenue and customer service. Changes must be made in a predictable way that mitigates the risk of errors, downtime and other disruption to users. At the end of the day, users don’t care if an application is built with code or clicks, but they do expect it to work reliably and securely for them to do their jobs. 

    Change management processes address these issues and foster greater collaboration between IT and the business. The low-code revolution has accelerated the pace of change, and it’s causing organizations to rethink their change management processes to accommodate non-technical developers to participate. It’s an opportunity and a responsibility of IT to establish the guardrails and guidelines to empower citizen developers to move fast without breaking things. 

    What can we expect from your session?

    We’ll be discussing the implications of low-code applications on existing change management practices and why that’s causing IT leaders to rethink the people, processes and tools for managing change. Attendees will get practical tips for change management strategies that decrease application time, accelerate time to value and mitigate risk. We’ll also dive into how to give CIOs and IT managers the visibility they expect into the change process.

    To learn more low-code adoption and change management, attend Max’s session at Low Code Today Virtual Summit on Nov. 19. To check out the full agenda or to register for free, visit the Low Code Today website.

  • Why DevOps and Federal Agencies Need Each Other

    Why DevOps and Federal Agencies Need Each Other

    In times of crisis, the U.S. government needs to bring in tech tools fast to help solve the problem.

    First, now is a vulnerable time and weaknesses are exposed in telework infrastructure as the government rapidly shifted to remote work. Cyberattacks are up as adversaries try to exploit the weaknesses. Second, federal agencies are also overloaded with traffic, to the point that their technology is reaching a breaking point.

    DevOps and DevSecOps may be the key to solving these issues for government agencies. Both, DevOps and DevSecOps, ensure delivery of a product is fast, secure and constantly evolving, which is vital to helping the U.S. government maintain continuity during the ongoing pandemic and set up future stability.

    The Air Force experienced these benefits firsthand when its internal DevOps team pushed out at least 10 updates a day, sometimes up to 30, and sustained that agile standard for some time. This agility, security and speed allows the Air Force to focus on the end-users and mission owners.

    If the government doesn’t have DevOps, it will lack the foundation needed to build a strong tech stack and work with other emerging tech solutions.

    DevOps Use Cases in Government

    With the government workforce spread out geographically, government networks are experiencing an increase in users plugging into virtual environments. Continuous patches and updates keep government systems and networks secure, functional and able to handle the load that comes with a surge of users. DevOps ensures the government has the tools and processes in place to support growth and prevent network failure under the additional stress of onboarding thousands of users each day.

    The government also needs tools that can help the distributed workforce maintain continuity, especially when it comes to security, operations and maintenance. Employees need correct access to do their jobs, but agencies must maintain control over what data is shared and how to confirm users are who they claim to be. Access management is vital in remote environments to ensure tighter control over who has privileged access.

    A modernized approach to privileged access tools means developers can hit targets of continuous delivery to improve systems and security. Otherwise, exploitable vulnerabilities are exposed to bad actors. Solutions for secure privileged access, especially across a distributed workforce, are key to scaling tech across government.

    With a hasty shift to remote work also comes change management, which is already difficult, not to mention the additional strain of a pandemic. In a crisis, federal agencies can’t wait for in-house solutions that take a long time to develop. The government needs commercial tech that can help build remote infrastructure.

    Federal Market Opportunities

    As the government responds to COVID-19, federal agencies are in search of technologies and tools that can support their missions. Many agencies are feeling immediate strain on their IT systems as part of the shift to telework, and have received reallocated and additional budget — with broad latitude on how they spend — and procurement flexibility to modernize their systems. This opens up opportunities for tech companies, like those in the DevOps and DevSecOps space.

    Tech companies that already work in the federal market know that while the government procurement process can be lengthy and complex, it can be well worth the effort for stable revenue. In times of economic uncertainty, working with the federal market can help companies build recession resilience.

    Another part of the opportunity now is that the government needs flexible and scalable technologies that can help them respond to the COVID-19 crisis, but first, they need DevOps tools for a strong foundation and infrastructure.

    The government needs DevOps and DevSecOps now more than ever, and there are commercially successful tech companies that can help with exactly that today. In return, the government can provide a sustainable source of revenue for emerging DevOps companies. Working together can be a win-win for these tech companies and federal agencies, and can help move us toward a more innovative, safer and healthier future.

  • Seven Effective Tips to Get the Most Out of your DevOps

    Seven Effective Tips to Get the Most Out of your DevOps

    It seems that every firm is trying to include DevOps in their software delivery cycle these days. This is understandable. According to the 2019 Accelerate State of DevOps Report, companies using DevOps are more likely to achieve elite performance in software development and delivery.

    Companies such as Google and Amazon can be deploying thousands of updates a day. These rapid updates improve company performance and result in the provision of better software solutions for the end-user. 

    In this article, we will look at seven effective tips to get the most out of your DevOps so you can maximize success. Before we look at some of these tips, let’s briefly define DevOps.

    What is DevOps?

    DevOps is a term for a group of management practices that aim to quicken the deployment of changes to a system while ensuring high quality delivery. It incorporates management theories such as agile infrastructure and agile development. One of the most influential books on the topic, which resonated with a lot of influential business leaders in Silicon Valley, is “The Lean Startup” by Eric Ries.

    At its heart, DevOps boils down to the idea that you should be able to implement changes quickly, so you can release a superior product to your customers faster. This ability to bring a superior product to market fast, gives companies that can achieve this edge an advantage over their competitors.

    Review Your Organizational Structure

    Collaboration is the bond that allows software companies to deploy and execute changes fast. Companies that are experts at DevOps classically reduce the obstacles to collaboration.

    In traditional IT organizations, departments are siloed. They interact with each other only when necessary. Hence, they have limited knowledge of each other’s work. This model presents a linear process of developing, testing and deployment. 

    To reduce these silos, you need to first analyze your organizational structure, and identify obstacles to collaboration. This starts by ensuring management is on board with your vision. You need to:

    • Review the job description of managers and create KPI that support collaboration.
    • Create remuneration packages that foster closer collaboration between departments.

    Addressing structural issues that impede collaboration between departments will help. You also need to put in place a system of communication between departments.

    Fortunately, there are useful tools to smoothen continuous collaboration between different lines of business. Channels of communications should not be limited to sending emails or conference calls. Remember, DevOps requires continuous and fast collaborations to ensure fast deployment.

    Using unified communications (UC) is an effective way to foster collaboration in a company. Unified communications integrates phone calls, email, chat, document sharing, conferencing and other platforms necessary to exchange information within the organization. Importantly, you can also access much of this information in one place.

    Reduce Operational Hurdles for Deployment

    The way an update is deployed will differ by company. There is usually a system in place to discuss targets and a series of checks in place before deployment. For example, department heads will come up with an idea. They will be developed, then reviewed by quality assurance before operations deploy it.

    This can be a cumbersome and time-consuming process, which slows down the speed of development. The problem for many companies is that changes, both large and small, need to go through the same process of quality assurance before deployment.

    Source: Tech Beacon.

    While it makes sense to have this process in place for major updates, it should be possible to push smaller updates faster. Two things need to happen to achieve this:

    • Empower staff to make decisions independently while giving them the opportunity to learn from mistakes without risk.
    • Reduce the administrative hurdles to deployment by creating a ranking system for reviewing updates. This will allow developers to push small updates independently, or with minimal oversight.

    Empowering staff to push changes enables you to speed up DevOps.

    Plan in Small Batches

    Planning in small batches is important in promoting DevOps in an organization. With small batch testing, the cycles of testing hypotheses, acquiring feedback and going at it again can be done within a very minimal time frame. It is fast and efficient—simple. 

    This feedback might feel obvious. Perhaps the better question to consider when planning in small batches is: How small is small? Let the INVEST concept in agile development help you out.

    • Independent: Planned small batches should be independent of other parts.
    • Negotiable: Every batch should be iterable and negotiable upon receipt of feedback from deployment.
    • Valuable: Each one should add value to the project and the end-users.
    • Estimable: Batches should contain estimable information for scope determination.
    • Small: Small should be small enough to be processed within a few hours up to a few days.
    • Testable: A planned batch should be testable and can be monitored continuously.

    Results of deployment, testing and monitoring of each batch should then be deployed at least once a day. Also, in planning small batches, different departments should be kept in the loop. This will greatly benefit DevOps efforts in the organization.

    Create Space for Collaboration

    Even without DevOps, fostering collaboration between departments is imperative. You can formalize collaboration through regular meetings. However, departments are usually situated in separate office areas, floors or even different buildings. Think about having to walk to a conference room on a different side of the facility just for a meeting.

    This kind of setup is an example of a bottleneck for collaboration in an enterprise. And with collaboration being the heart of DevOps, creating a company culture and office space conducive to teamwork is of utmost importance.

    SpaceX is an example of a company that promotes collaboration throughout the organization through company culture and physical space management. Offices are open, and each person can see what everyone else is working on. This promotes motivation for employees to work passionately. Also, everyone has access to camera feeds from different parts of the factory, which inspires curiosity about what others are doing. Because of this culture, employees become dedicated and excited to accomplish results.

    Take Advantage of Microservices

    In processing complex IT systems, it is more beneficial to break bulks to smaller, more digestible pieces. This is where microservices come in.

    Microservices or microservice architecture is an architectural style wherein a complex system is broken down into smaller services. Rather than treating a system as a whole, it is perceived as a collection of manageable pieces.

    Teams simultaneously working on parts of a system as a whole makes it more prone to breakdown. Utilizing microservices makes monitoring, maintenance and testing easier. They are also loosely connected to each other which means fixing wouldn’t much affect the other parts. Moreover, each microservice is releasable independently.

    As an example, Wix started out with a monolith which was useful at first when they were only handling 1 million sites. However, interdependencies and poor quality coding resulted in downtime which is ultimately bad for business. Now that they shifted to using microservices architecture, they quickly scaled up reaching 70 million sites.

    Maintain Continuous Monitoring

    DevOps promotes fast and continuous integration and deployment. A fast-paced environment is more susceptible to problems. Something at any point can fail within the software development life cycle. Continuous monitoring helps you identify mistakes fast. It ensures the optimal performance, reliability and health of the software.

    Setting monitoring targets, like development milestones, can improve this process. A development milestone is an overarching category that can give an insight into your team’s actual performance. Monitoring tells you the performance of your DevOps implementation.

    A method to consider is synthetic monitoring wherein your application undergoes simulated customer interaction. This way, you can monitor the exact action and performance of your software before they get released to actual users.

    Practice Change Management

    DevOps employs continuous integration, continuous deployment and continuous monitoring. It is a cycle of fast-paced changes. Change management is essential to keep the system run like clockwork.

    It might be easier said than done because changes have effects on various stakeholders. This includes your customers as the end-users, security, regulatory compliance and company policies. With this, changes within the development, testing, deployment and monitoring should be cohesively managed.

    Change management is intrinsically reactive. It usually happens because of feedback received after deployment. But with DevOps, change management should be proactive. Instead of managing large-scale changes, processes are broken down into smaller parts with clearly defined scopes. Furthermore, anticipated changes are scheduled, scaled and communicated across the board. Possible risks and problems are efficiently managed because of this.

    Summary

    No system is perfect nor exactly the same. The key to a successful DevOps implementation is assessing what works best for your organization. DevOps is not a standardized process. It is not a system that will work for every company. Rather, DevOps is a theory of management.

    Improving DevOps at your firm will involve a system of continuous review and improvement. You need to understand what is working, the problems and what you can improve. This can all be done through continuous processes with the help of automation and collaboration. No matter the size of your software development projects, these simple tips and tricks will help you make the most out of your DevOps.

    — Sam O’Brien

  • These Three Approaches Will Help Your Enterprise Be More Agile

    These Three Approaches Will Help Your Enterprise Be More Agile

    Nearly every organization that tries to change its culture to be more agile and better adapt to changing environments discovers that it’s harder than it looks. Agile transformation can’t be superficial or only embraced by the IT department–it needs to be completely pervasive throughout the business.

    There is no one-size-fits-all approach or playbook that can be used to fit any organization’s unique situation. Yet, there are some common takeaways and best practices that can be gleaned from organizations that have successfully undergone agile transformation. Here are three common themes I’ve come away with from talking with organizations at various stages of their agile journey.

    Creating an Agile Enterprise Relies on Successfully Orchestrating Change in Culture, Organizational Structure and Technical Capabilities at the Same Time

    Changing enterprise organizational structure without changing culture and technology will lead to factors that drag down any potential transformation. It’s equally true when addressing any one of the elements in a vacuum. Instead, enterprises must address all three at once, which makes for a tricky prioritization exercise. 

    In many cases, new solutions will lead to new problems that organizations must address as they arise. Agile teams enabled to self-organize and pursue customer problems with greater freedom may find themselves hamstrung by inflexible legacy technology. Changing technology to enable agility may uncover additional organizational difficulties, and so on. Agile transformation is a long journey, and enterprises must adjust on the fly to their own unique circumstances.

    When Making Changes to Drive Agility, Think About What Scarf Everyone Wears

    Missy Lawrence-Johnston, a principal consultant from ISG’s Organizational Change Management practice, suggests that leaders should remember a warm and fuzzy acronym when working toward change: status, certainty, autonomy, relatedness and fairness (SCARF). The SCARF model was developed by neuroscientist David Rock, and explains how individuals react to change based on perceived threats and rewards. 

    If a change negatively impacts someone on one of the dimensions they consider important, they’re more likely to push back on it. For example, a manager who cares a great deal about their status will probably have difficulty embracing an organizational shift that works to cut down on organizational hierarchy. But that same change could be highly valued by a rank-and-file employee who prefers greater autonomy. How people react is individual, which is why the SCARF everyone wears is unique to them, as Lawrence-Johnston points out.

    As enterprises make the changes necessary to embrace agility, keeping this concept in mind will make it easier to navigate the threat responses employees inevitably have.

    Measure Culture by the Behaviors People Exhibit at Work Every Day

    ISG research shows that culture and team enablement are the most important factors when transforming into an agile enterprise. While culture can seem like something nebulous and difficult to pin down, it’s best evaluated by noticing what people do every day. Odds are, any employee of a firm has at least one story that illustrates what they see as the culture of the organization where they work. An enterprise’s culture is the sum of these stories.

    Agile transformation requires some fairly radical changes for businesses that are used to working in a waterfall mindset. This often looks like a shift from a hierarchical, rule-driven culture that focuses on command and control to a collaborative, self-organizing culture with servant leadership. Implementing this degree of change takes significant work. 

    When changing culture, it’s not enough to put up a fresh set of posters with new values. Living those values and building organizational structures to support them is the key to success.

    — Blair Hanley Frank

  • DevOps Versus ITIL: How to Win the Battle Over Change Management

    DevOps Versus ITIL: How to Win the Battle Over Change Management

    Ever since DevOps came on the scene a decade ago, ITIL has been under siege.

    ITIL lays out a number of IT service management (ITSM) best practices, including release management, change management, incident management, problem management and many other aspects of running an IT shop so that its priorities align with the business’s. For many enterprises, ITIL is essential for governance and regulatory compliance–especially in heavily regulated industries.

    The basic idea of DevOps is that by leveraging better automation technology across the software lifecycle, it’s possible to rework the culture and organization of all the teams involved in software production and deployment. By breaking down the numerous silos and fostering greater collaboration, it should be possible to dramatically accelerate the ability to deploy quality software at scale.

    From the DevOps perspective, ITIL is nothing but a set of speed bumps and roadblocks, getting in the way of its continuous integration/continuous delivery (CI/CD) priorities.

    DevOps wants to speed up software release cycles, while change management often slows them down. Does this dichotomy mean that enterprises have to choose one or the other? Or perhaps we have to water down one of these approaches sufficiently so it’s marginally compatible with the other one?

    Is ITIL Part of the Problem?

    ITIL skeptics abound. “Frameworks like ITIL create the illusion of control that results in [the] organizational delusion that IT is efficient and manageable,” said Greg Ferro, long-time consultant and co-founder at Packet Pushers Interactive. “The single biggest problem in ITIL [is that] the creation of silos creates ‘not my problem’ attitudes.”

    One such silo is the change advisory board (CAB), a team that has the responsibility for making thumbs-up or thumbs-down decisions on numerous different activities across the IT organization. “Having the CAB review every single change request isn’t efficient,” said Kaimar Karu, head of ITSM at AXELOS, “and it’s definitely not common sense, especially when their costs can run to tens of thousands of deployments per hour in some organizations.”

    One organization that has struggled to transform their ITIL process as it moved to a DevOps model is financial services firm ING. In fact, its CABs were a point of contention for it. “We were just like an insurance company, always rejecting your first claim,” said Mark Heistek, IT specialist at ING. “And then come back if you have good arguments.”

    ING found it was able to modify ITIL to work within its new DevOps approach. “Don’t do everything the ITIL book says,” advised Jan-Joost Bouwman, ITSM process owner at ING. And yet, following ITIL for practices such as incident management are “still the best way to do it, because everybody knows what to do and you don’t get confused about the rules.”

    Or Is ITIL Part of the Solution?

    In spite of the skepticism, there are plenty of proponents of using ITIL with DevOps. “The DevOps Movement fits perfectly with ITSM,” according to Gene Kim, DevOps thought leader, author of The Unicorn Project and coauthor of The Phoenix Project. “ITIL and ITSM still are best codifications of the business processes that underpin IT operations, and actually describe many of the capabilities needed into order for IT operations to support a DevOps-style work stream.”

    Kim, however, focuses more on human capabilities than on the ITIL processes and procedures themselves. “ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business,” said Kim. “ITSM skill sets are ever more important in a world where there is an ever-quickening business tempo.”

    Phil Tee, CEO and co-founder of Moogsoft, agrees with Kim–and also echoes the experience of Heistek and Bouwman at ING. “ITIL is not in conflict with DevOps,” said Tee, “but it must be adapted to DevOps practices in order to define clearly where issues arise and how to solve problems efficiently.”

    Adapting ITIL to work within the context of DevOps–without slowing it down–has become the crux of the discussion. “ITIL is not explicitly opposed to Agile and DevOps,” explained Charles Betz, principal analyst at Forrester Research. And yet, he found that “the overall ITIL narrative is still sequential, plan-centric and deterministic.”

    Rock and a Hard Place

    Part of the DevOps way of thinking is to reevaluate how the organization makes the decision to deploy software into production. “By combining developers and operations into smaller, more agile DevOps teams, organizations can build software more quickly than ever, enabling them to respond faster to changes in the market,” said RJ Jainendra, general manager and vice president, IT business management and DevOps business unit at ServiceNow. “But, that’s a difficult challenge for larger companies, however, that haven’t been able to realize the full benefits of DevOps for a variety of reasons, including the complexity of manual processes they manage, and a shortage of DevOps expertise.” 

    There are many business contexts where internal process or regulatory compliance concerns are the issue, introducing requirements beyond what current DevOps approaches can satisfy.

    Jumping to the opposite extreme and requiring rigid change management procedures, however, can easily be overkill. After all, even for the most heavily regulated, quality-conscious enterprise, some of the changes they put into production don’t have the same stringent requirements as the rest. Not all software changes carry the same level of risk.

    The challenge, therefore, is telling the difference–and putting into place proactive, automated ways of handling different change scenarios that are subject to different levels of rigor.

    Judicious Use of Automation

    In spite of what many DevOps zealots may say, the approach is inherently flexible and human-driven. People still create software, after all–and DevOps is more about encouraging new ways for people to cooperate to achieve a common goal than it is about offloading human tasks to automated processes.

    As a result, DevOps is not nearly as black and white as those zealots might have you believe. For example, the “continuous” in CI/CD doesn’t mean “all the time” or even “as fast as possible.” In practice, continuous means “as fast as practical given the particular business requirements that apply in this situation.”

    Sure, Amazon may deploy several times a minute and be able to easily integrate compliance and governance into their technologies, but that doesn’t mean you can, or even that you must. After all, enterprises have a very different business and technology context from web-scale, born in the cloud companies such as Amazon.

    You may simply have different requirements–and even more importantly, different software will likely have different deployment cadences, even within the same organization.

    These principles of flexibility and human-centeredness apply beyond deployment to all aspects of change–and thus, they apply to the change management and release management practices of ITIL more broadly. 

    Sometimes you need a CAB, and sometimes you don’t. Sometimes you need to change windows, and sometimes you don’t. Sometimes fully automated quality checks are sufficient for giving the green light for deployment, and sometimes they’re not–and so on.

    And perhaps most importantly, sometimes humans should make approval decisions, and sometimes those decisions should be automated. 

    The more you can automate these approvals, the faster your deployment will be. But if you are able to identify those changes that require human approval and route those accordingly, then you’ll have optimized how you handle change in a way that pulls together DevOps and ITIL practices.

    Bringing ITIL and DevOps Together in Practice

    Traditionally, ITSM products are ticketing systems. When some incident occurs or someone calls for a change, they must create a ticket that then kicks off a set of manual tasks, often by different people.

    DevOps can bring automation to this traditional ITSM context. “One of the modern miracles of DevOps principles and practices is that many parts of ITIL processes can now be automated, solving significant challenges, especially in the configuration, release and deployment management processes,” Kim explained.

    Such manual workflows are typically well-suited to supporting ITIL practices, but fall short of the speed that DevOps requires. “ServiceNow DevOps leverages the data and metadata it already has on its platform, combined with new information from the DevOps pipeline to create, automate, and manage ITSM changes from within DevOps workflows on an enterprise-wide scale,” said Jainendra.

    In fact, ServiceNow can oversee the full automation of the deployment, integrating with other DevOps tools as necessary to effect the change, eliminating the need for any additional action from a developer. On the flip side, when the policies in place require a human approval of a change, then ServiceNow routes the change to the appropriate person. 

    The Intellyx Take

    Automation, for all its benefits, has never been about taking humans out of the decision-making loop. On the contrary, automation takes low-value tasks off of people’s plates, allowing them to spend more time and effort on more valuable activities. Decision-making is often among those high-value activities.

    That being said, automation is getting better at making decisions, both because of the breadth of machine-understandable policy representations and other configuration metadata, as well as the increasing prevalence and sophistication of machine learning.

    For DevOps professionals, it’s essential to understand this increasing level of sophistication for the automation available in today’s tools. The choice between automated or manual is no longer a black-and-white affair. Instead, there are different levels of capability for automated decision-making depending upon the situation at hand.

    — Jason Bloomberg

  • Untapping the Potential of DevOps, Part 3: Keys to Success

    Untapping the Potential of DevOps, Part 3: Keys to Success

    Over the course of this series, we’ve talked about some of the common mistakes we have seen organizations make as they either launch or continue their journey into the world of DevOps. But just as it is important to understand the pitfalls that may happen during a DevOps transformation, it is perhaps even more important to know what the key indicators are that drive success. With that in mind, here are a few tried-and-true tactics for making the most out of your DevOps initiatives.

    Start With Automation

    One of the most powerful areas of impact for DevOps is in driving automation. It accomplishes several things: it increases the velocity of the development pipeline, it can reduce the number of errors or potential errors in code and it often frees up time for developers, allowing them to focus more on creating value and less on repeatable and mundane tasks. By ensuring that DevOps automation goals, including CI/CD, test automation, monitoring, Infrastructure as Code and GitOps are included at the outset of projects, you can better set up your organization for successful software development and delivery—both in the short term and for the long haul.

    Strong Communication

    When it’s all boiled down, DevOps is like any other advanced business tactic as it relies on strong communication to deliver the most success. As the name implies, DevOps engineers must bridge the worlds of development and operations, so to be truly effective they need to possess fluency in both worlds. Can you have success if you have engineers who are only strong on one side of the equation? Technically, yes. But you will not maximize the amount of value from your DevOps initiatives without stakeholders who can adeptly manage both sides. Additionally, communication with the business and other non-technical sides of the organization is critical. The entire organization should be on board with DevOps, with clear visibility into the transformation—your successes and challenges will come from frequent, effective communication.

    Adhere to Processes

    DevOps is process-driven, particularly as organizations scale. To work effectively, and to serve real enterprise environments, creating and adhering to processes is key. While automation is important for the rapid delivery of value, effective change management is important for sustainable development and system operations. Process and compliance are an important part of sustainability for large environments. It is also extremely important for organizations where compliance is vital—think industries such as finance, medical and government. By implementing and adhering to well-defined processes, you can avoid future headaches or rework that will slow down the pipeline.

    Leadership Buy-in

    The most impactful changes have one thing in common: strong leadership. Leadership dedicated to delivering customer value and understanding the software’s prominent role in delivering that value is key. Organizations that cling to outdated methods of development and delivery (i.e. waterfall) lead to slower delivery of value, which is the ticket to extinction. DevOps also benefits greatly from having leaders within the organization who serve as champions for change. By keeping a finger on the pulse of your organization from within, you can better practice change management, identify potential weaknesses earlier on and make your DevOps initiatives work for you.

    DevOps can be an extremely effective way to deliver the most customer value from your software pipeline. By keeping these four key indicators in mind, you can better position your team for success and enjoy the benefits of your DevOps journey.

    — Jonathan Fries

  • Best Practices for Software Change Assessment

    Best Practices for Software Change Assessment

    Business spending on enterprise software has been on a constant rise over the past decade with 64% of businesses spending more on IT operations in 2018. It is estimated that in 2019, the number will reach $462 billion worldwide. This not only includes the procurement or development of new software and digital innovations, but also investments in modifications and upgrades.

    However, implementing software changes is no easy feat. It involves serious financial investments and staffing resources, which is why it is critical to get it right. A well-implemented change assessment is a key component of every software change project. This gives decision-makers an accurate and complete understanding of the impact of the software changes and identifies potential disruptions to specific departments, functions and processes.

    There are many ways to approach and implement software change assessment. These best practices can ensure a glitch-free software change rollout.

    Use a Comprehensive Discovery and Dependency Mapping Technology

     One of the disadvantages of the modern workplace across all industries is the emergence of information silos. They can hamper growth and efficiency and cause other problems, including redundancy of effort, stalled collaboration and other missed opportunities.

    In order to break these silos, efficient application discovery and dependency mapping is a crucial step in every software change project. Unfortunately, most businesses are failing miserably in this department. A Forrester survey revealed 56% of IT managers “do not have a complete view of dependencies between applications or between applications and infrastructure.”

    The same survey revealed 30% of the IT managers think that having a complete inventory of all enterprise hardware and software in use at their organizations is critical for IT efficiency. Ironically, 42% do not collect the necessary software data, while 39% are maintaining their inventory manually.

    The disadvantages of inadequate discovery and inefficient dependency mapping include low productivity, project delays, increased overhead costs and poor team morale, among others. A key step in solving this predicament is investing in the right discovery and dependency mapping technology, which can support a solid foundation for a software change initiative or any IT project for that matter.

    A reliable, agile software solution should provide both macro and micro views. The more granular, the better. Additionally, it should be able to give IT decision-makers a consolidated view of their application stack across multiple message queues, APIs, databases, unifying codes and languages.

    Use the Seven R’s of Change Management

    One thing IT managers should realize when assessing software change is, they’re not pioneering the process. Many organizations have done it and made mistakes along the way. Experts have used these mistakes and learnings to create roadmaps for others.

    One of the most well-established resources for IT change management is the Seven R’s of Change Management conceptualized by Information Technology Infrastructure Library–a set of detailed practices for IT service management. The seven Rs represent the following questions designed to help businesses make educated decisions on how to proceed with change requests.

    1. Who raised the change?
    2. What is the reason for the change?
    3. What return will the change deliver?
    4. What risks are there if we do or do not carry out the change?
    5. What resources will be required to perform this change?
    6. Who is responsible for this change being performed?
    7. What relationships are there between this and other changes?

    While these concepts are not exclusive to software change assessment, they provide a solid framework for businesses to identify noteworthy software change projects. This is especially helpful for organizations creating their software change assessment protocols from scratch.

    Never Skip Impact Analysis

    This is especially important for software vendors who are operating on tight budgets and strict deadlines. Software change impact analysis encompasses five major areas:

    • Identifying the impact of the change request on the software development project or on a business’ IT infrastructure.
    • Determining all software resources that need to be modified to implement the requested change.
    • Calculating the cost and manpower capital needed to perform the change request.
    • Ensuring the requested change complies with internal and external regulations.
    • Eliminating or minimizing any security risks associated with the change.

    To make sure businesses covers all the bases for any software change initiative, it’s best to use a checklist or template sourced either from the technology vendor or one their IT team put together, tailored to their needs.

    Not All Changes Are Created Equal

    Today’s ever-changing business landscape dictates business technology must evolve to keep up with an organization’s shifting needs. Software changes, when implemented strategically, can help businesses achieve new heights in productivity, efficiency and profitability.

    To ensure software changes serve this purpose, IT project managers need to implement an airtight software change assessment system. With the help of technology, checklists and well-established industry best practices, organizations can quickly outline a process that yields beneficial results in the end.

    — Aditya Sharma

  • Rigidity or Agility During Change Processes: You Do Have a Choice

    Rigidity or Agility During Change Processes: You Do Have a Choice

    As most who work in service management, on an IT team or as a member of the service desk understand that change management can be a rather rigid, shall we say, still process. Do you want to make your change implementations more agile? There are different ways to go about this. In this piece, I plan to discuss how to implement a single change in an agile way, and how to make all your department’s future changes more agile. Let’s first begin with how to make the implementation of a single change more agile.

    Describe Your Goal and Preconditions

    Ideally, when necessary changes are required, you shouldn’t need to complete a full change request form when submitting the request. The description should only contain basic information regarding the change. Most importantly, what must be included are your goal and the required preconditions.

    Here’s an example: You receive multiple calls about a coffee machine breaking down, or an email server running slowly. As a service desk representative, you’d likely prefer not to receive and handle a bunch of calls about the same problem, but you do want your customers to be able to know whether or not a problem has already been reported and is being dealt with. Your team’s goal, then, is to show your customers that a ticket already has been submitted for the problem and that you are working on it, but you also want to make sure your customers don’t get to see the private information of other customers—that would be one of your preconditions.

    Apart from your goal and preconditions, there’s not much more you need to know when you get started with a change.

    Check Regularly if Your Change is Still Meeting the Pre-Set Goal and Preconditions

    Implementing changes according to the waterfall method can mean there’s a chance that, when done, the solution doesn’t meet the customer’s needs. The waterfall method likely means you want to execute your plan without alterations along the way. Under this model, there’s no room to adjust to new situations even if you need to make changes. You may find new information about what your customer really wants, or there could be new technologies on the market providing a better solution to your perceived problems.

    So, while you’re designing and implementing a change, regularly check to see if what you’re doing right now still contribute to the original goal, and whether you’re still meeting the pre-conditions. As you know, agile processes lets you make adjustments along the way. But perhaps you’re already past the point where you could have made a change. If that’s the case, in an agile workflow, you can change course and simply work the change.

    Involving Others in Your Change

    Once you’ve got an idea of how you want to implement a change, make sure to include your team’s experts so they are able to take a detailed look at your plans and determine the impact of the change on other applications and hardware. Additional points to consider include analyzing any change that may lead to security risks.

    When following the agile philosophy, it’s better to let your team come up with its own solution, but if the team figures everything out for themselves, you want outside members to perform the quality check. As the saying goes, freedom is not free. For IT teams, the freedom to come up with a solution means they also must be responsible for determining whether the solution will work as planned.

    Run As Few Changes As Possible at the Same Time

    IT departments almost never work on more than one change at a time, even those that are small. Unfortunately, there can be too many changes to the handle. To keep the number of changes in check, limit the number of changes that need to be undertaken at any given time.

    Doing so makes it easier to predict the duration of changes. Working on fewer changes at once means you’re working with fewer variables, so you can better predict when you’ll finish a change.

    Also, the fewer tasks in operation, the more likelihood of the service being higher. If you’re able to focus more on the change you’re currently working on, you don’t make as many mistakes. Finally, with fewer tasks you’re able to focus on your work and quickly generate results. Visible progress is one of the most important factors that determine happiness at work and getting things done in a timely manner is more motivating than constantly toiling on a number of different things with nothing ever getting finished.

    Managing Changes vs. Incidents

    When there’s a constant flow of incidents coming in, your service desk employees must make the decision about your team’s priorities and what they are going to be. For example, do you want to guarantee a maximum time for required changes? To meet outcomes and objectives that are set by this team, you must dedicate a set amount of time that each team has to spend on said changes. This means you must be able to accept that some of your reported incidents won’t be addressed immediately.

    Alternatively, if it’s more important to solve incidents quickly, you need to accept the time required to implement these changes, and an understanding that your team won’t be able to handle new changes as quickly as you might hope to. Change requires time, even if time to solve incidents is your biggest priority.

    — Nancy Van Elsacker Louisnord