devopsy.kinsta.cloud

Author: Charlene O’Hanlon

  • A New Language for Digital Transformation

    Charlene O’Hanlon and Rich Nanda discuss a new Deloitte study, “A New Language for Digital Transformation,” which explores why so many transformations fail to deliver concrete impact. The video is below followed by a complete transcript of the conversation.

     

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Welcome back to Techstrong TV. I’m Charlene O’Hanlon and I’m here now with Rich Nanda who is the US monitor practice leader at Deloitte Consulting. Rich, thank you so much for being back on Techstrong TV. It’s great to see you.

    Rich Nanda: Good to be here, Charlene.

    O’Hanlon: Well, I know you spoke with Alan a couple months ago about another report that you guys had out, but I want to talk to you a little bit about the new study that you have called, I believe it’s A New Language for Digital Transformation. Is that the right title?

    Nanda: That’s right, Charlene. Yep.

    O’Hanlon: Excellent. All right, great. So tell me a little bit about this one and what its focus is.

    Nanda: Yeah, so we remain very committed to this idea that digital transformation is in service of business transformation, and in fact, the earlier conversation I had with Alan talked about how it’s even impossible to separate the two in a digital economy that we’re in. So it really is all about how technology is applied to advance the strategies and interests of a company and how a company thinks more broadly about their winning strategies in light of technological innovation.

    And we’re getting a lot of market resonance with that type of thinking and work as companies look to make themselves more sustainable in growing enterprises in an increasingly digital world.

    One of the challenges to making that happen though is technology keeps moving very quickly. Right? And today’s very innovative new technology is tomorrow’s technology death. And how do we give leadership teams a way to have a coordinated and consistent conversation about digital transformation. So that was the impetus of this work and in a world where technology is so essential to how businesses grow and compete, digital transformation as a term in and of itself and all of the underlying technologies within digital transformation, they kind of mean anything to everybody and in that context, how do we help put everyone on the same page?

    O’Hanlon: Well, it’s a very, very interesting question because we have been talking about digital transformation for many, many years, but it’s really only been over the past 18 to 20 months or so that we really have seen it spike and I know that you’re well familiar with the concept and what’s been happening in the market. But, now I feel as though we are not kind of seeing the hangover effects, if you will, of rapid digital transformation among organizations and it’s because maybe what they thought was critical for their business before, maybe turned out not to be so critical for them. Maybe they had to pivot quickly or maybe they just ended up making the wrong decisions about where they wanted to put their priorities in their digital transformation efforts.

    So what are some of the things that you guys have seen then in speaking with clients and folks out in the field about their digital transformation efforts and what was kind of the Achilles heel, if you will, for digital transformation, you know, for those that maybe didn’t go as well.

    Nanda: Yeah. Well, my view is it’s – all of these digital transformations are a work in process and what was a very common refrain throughout 2020 and even the early part of this year was, you know, “We’ve done a decade’s worth of digital transformation in months.” And we do our own survey with Fortune Magazine of CEOs, but there’s many similar surveys that were coming back with this data point that CEOs were saying, 90 percent of CEOs were saying, “We’re doing more digital transformation than ever before.”

    And you know, through the lens of the pandemic and its disruption, virtualization of work for knowledge workers, adding automations for safety purposes into plants and distribution centers, creating more virtual customer interactions like telehealth or like click and collect in retail. I mean, all of those were very real changes that companies were making, some of which were in motion before the pandemic, but clearly, that 90 percent step was the acceleration that happened.

    And now that those projects and investments are a year plus in the making, a new question is arising, which is, well outside of the immediate response, what did we get out of those? What did we learn from them and how do we scale to create the next level of business benefit. And so I think that’s where we are is just a new inflection point. And it’s a work in process. Right? We’re not done with these transformations by any means.

    O’Hanlon: Yeah, I don’t think we’re ever going to be done. It’s kind of like doing DevOps. We talk about DevOps a lot as one of our sites and DevOps is not a one and done thing. You can’t just add a bunch of tools and technologies and say, “That’s it. We’re doing DevOps now.” And I think digital transformation, to your point, is very similar to that and you know, but it also becomes a moving target when it’s kind of always in process.

    So how can an organization understand that it is on the right track and you know, is there a way that business leaders and IT leaders can both kind of, I don’t know, use the same nomenclature or speak the same language, so to speak, and understand what business outcomes they collectively are trying to achieve. I mean, I feel like there’s some sort of disconnect between IT and business a lot of times when we’re talking about digital transformation.

    Nanda: Yeah, absolutely. So I would – I’m going to answer that question but I want to just go back for a second. I’d be remiss if I didn’t talk about the transformation is never done idea, Charlene, that you brought up.

    We actually just published a book which launched last week called the transformation myth and it’s a collaboration between Deloitte, Boston College, and Northwestern and builds on five years of research. But the premise of the book is what we’ve learned through the highly disruptive times that we’re in is that transformation isn’t a one and done event. In fact, it’s in a constant state of adapting to an ever more complex and changing environment and so absolutely, right, transformation is a capability and a muscle, not a finite project or event.

    But in a world where companies are constantly transforming themselves, you’re right, and technology is a key ingredient in that transformation more than ever before, how do business leaders, who are responsible for different units or different functions and they have their own set of priorities, communicate with technology leaders in a way that there’s a shared agenda. And what our research has shown is there’s just a fundamental disconnect in how management teams are able to coordinate and communicate with one another. And it’s very easy to get pulled into a specific disruptive technology and to say, “What’s my cloud strategy? What’s my AI strategy?” Well, actually you probably need to think through what’s our overall strategy and what’s the role of technology in stretching, improving or enhancing in that.

    So what we’re coaching clients on is to think of five digital imperatives, and none of those five actually name a specific technology because the five imperatives allow for multiple technologies individually or collectively to make those imperatives come to life. And I’ll just rattle them off real quickly and then we can talk about them.

    But first imperative is experiences, whether that’s workforce, colleagues, end users and customers. The second is an insights imperative. The third is a platforms imperative and aware and how does computing gets done. The fourth is a connectivity imperative, how do we connect to more players and entities and data in the ecosystem. And the fifth is an integrity imperative, how do we make sure that whatever we’re trying to achieve sustains under stress.

    O’Hanlon: I like that lineup because it does provide a framework, but it does not kind of pigeonhole organizations into using a particular technology, as you said, or even thinking the same way because each organization, their digital transformation efforts are vastly different between different organizations and sometimes even to business units within the organization. It seems like – and we want to make sure that anything that’s happening within an organization as far as improving or enhancing digital transformation efforts isn’t at locker heads with other business units in the organization.

    So you know, I feel like there’s a healthy amount of communication that still needs to happen, even within the organization, not just IT leaders and business leaders, but also kind of that one level down line of business managers or even practitioners to understand that everybody understands what the – I don’t want to say the end state or the end result, because we just said that’s never going to happen, but at least the desired state.

    Nanda: The next interim state.

    O’Hanlon: Exactly. Exactly.

    Nanda: You elocuted on one of our very common fatal flaw or area of inefficiency, which is, look, enterprises are complicated units and what one business unit or function may be trying to optimize for is going to be different than what another business unit may be working on. But at the end of the day, technology is being procured and applied to the organization in a way that should be shared across.

    So how do you build a shared foundation with a common understanding of what that shared foundation can do and then let distinct parts of the businesses get the benefit and the customization they need out of that shared foundation. It’s certainly much easier said than done, but that’s the task at hand and you know, missing on that task, that’s where we’re going to get , well 90 percent of the CEOs said they accelerated, but only half of that would say, “We got the ROI we wanted or some suboptimal outcome.” So that’s the opportunity at hand.

    O’Hanlon: Yeah, well I think that it’s – I think the next 12 months are going to be very telling from an ROI perspective on many of these digital transformation initiatives that are organization that started previous to the pandemic and accelerated or just decided to launch during the pandemic. But I think that there have been a lot of lessons learned along the way and I think we’re nowhere near the point where an organization just kind of can just either take a digital transformation effort and come out unscathed. So with that, I think there’s going to be a lot of bumps and bruises along the way.

    But Rich, thank you so much. We could talk about this forever I feel like, but I do want to thank you for the time that you have spent with me and we’ll definitely circle back another time and continue this discussion. I really do appreciate your time today though.

    Nanda: Thank you for having me Charlene.

    O’Hanlon: All right, great. All right everybody, please stick around. We’ve got lots more tech strong TV coming up, so stay tuned.

    [End of Audio]

  • Site Reliability Engineers to the DevOps Fore

    Site Reliability Engineers to the DevOps Fore

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/02/site-reliability-engineers-to-the-devops-fore.pdf”]

  • What is Continuous Delivery?

    What is Continuous Delivery?

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/02/what-is-continuous-delivery.pdf”]

  • Where Do SREs Go From Here?

    Where Do SREs Go From Here?

    Charlene O’Hanlon talks with Leo Vasiliou, director of product marketing at Catchpoint, about the results of a study the company fielded with VMWare Tanzu and DevOps Institute of nearly 300 site reliability engineers (SREs). This year’s report underscores the challenges of multi-cloud, calls out the underutilization of AIOps and shows a systemic shift in core baselining data. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Hey, everybody. Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I’m here now with Leo Vasiliou who is the Director of Product Marketing over at Catchpoint. Leo, thanks so much for joining me today. Really appreciate it.

    Leo Vasiliou: Oh, of course, Charlene. Thank you very much for allowing us to have the conversation today.

    O’Hanlon: Absolutely, absolutely. I want to talk to you about a recent survey study that you guys put out in conjunction with VMware Tanzu and DevOps Institute. What were you guys looking at?

    Vasiliou: Well, from an existential perspective, we hope that the survey that we do leads into the annual report and we’d like for it to be the most data-backed set of insights in its community. There are sort of three underlying constructional essences of the report. One is to provide a core baselining data for the key SRE tenants. So DevOps, who had an amount of time, would call in reported levels of toil. The other essence is to look at what’s trending. And then the third one will generally be around the IT to business relationship. And then with each one of those constructional essences, the context and line items within each section will change from year to year.

    O’Hanlon: Gotcha. Alright. So this one focuses on site reliability engineering and what they’re seeing and what they’re dealing with on kind of a daily basis. Is that right?

    Vasiliou: Yes, yes.

    O’Hanlon: Okay. Alright, great. So tell me a little bit about some of the findings in the study. I know you guys do these, as you just said, reports yearly. So I’m interested in knowing what’s changed from year to year and what really surprised you in this year’s report.

    Vasiliou: Well, I like to say SREs are double struck with challenges because the SRE is essentially two jobs in one, right? They have to increase the efficiency of their operational activities while mitigating the risk of their transformational activities. So one of the key findings this year, which by the way this may be the most provocative dataset we’ve published just because some of the findings conflict with some popular theories in the market, but take the first one just as an example of that, is as part of the baselining set of data there was a self-reported drop in toil, which is the word they use to define repeated, mundane, busywork that doesn’t have any inherent value, of 15 percent. And one of the reasons this is such an insightful nugget to lead us into our various conspiracy theories is it was across the entire distribution of data, across all of their percentiles, as well as across all of the geographies that we looked at.

    O’Hanlon: Wow.

    Vasiliou: And so for me, when I had the blessed opportunity to do the research and sit down and co-write the report, having been stuck in the house for, let’s just call it a year and a half at this point, there was just something different about working on a piece like this and it just felt a bit more meaningful. And the conspiracy theory there or the hypothesis is that if people return to work, or return to the office I should say or some type of hybrid environment, will those reported levels of toil increase again next year as people adjust to the hustle and bustle of commutes just adding to frustration in how they think about things?

    O’Hanlon: That is a really, really fascinating thought process there. We could do an entire conversation about just that and whether what happens this year is going to be indicative of what happens in the future or if this year is going to be like a reset year. So from an SRE perspective though, the fact that the level of toil decreased 15 percent, that seems pretty significant. If you look at the entire spectrum of what they have to deal with on a daily basis, 15 percent, good lord, that’s huge in the SRE space.

    Vasiliou: Yeah. It is huge. I agree. It’s also based on the response of hundreds of survey participants year over year. And what’s interesting, Charlene, is one of the unique tactics we took in this year’s report is before we publish the reports and post survey pre report, we actually showed the results to various industry, let’s just call them, leaders. One of them we shared this particular section to had an alternative theory on why levels of toil dropped, and it had to do essentially with the fact that if people are not in the office, maybe does the very act of them not being observed compel them to do less busywork.

    So there was an alternative theory. But bringing us back to and leading into one of the other essences of the report, which is kind of the trends piece, it had to do with the amount of monitoring data sources, like the volume, variety, velocity of data, and the number of multi same-service platforms, e.g. multi CDN, multi DNS, et cetera, in use. And so will the return to work and the promise of AI ops help them keep toil levels low? Which leads us into the next sort of surprising finding, which is that SREs and their implementation or shift to AI ops is quite slow to maybe what we might be reading about in the industry, which was probably the second most provocative finding in the report.

    O’Hanlon: Yeah. So why do you think it is so slow then? Were there any trends that kind of came out of that? Any reasons why organizations are kind of slow to adopt AI ops?

    Vasiliou: Well, there is obviously a deluge of information and rhetoric in the market on the internet today. We need to seriously consider this idea of an information diet, which is a concept I first heard about a couple years ago. When we think about the idea of the hype cycle versus the challenges SREs face on a day-to-day basis, sometimes the market and the promise of what these types of solutions will offer might outpace actual implementation capabilities from, hey, we’re an SRE, let’s go implement this. I think part of the challenge here is probably the concept of AI ops is too broad and too large for consumption. It’s the idea of just saying, “Hey, let’s go solve world hunger or, hey, let’s go solve or implement AI ops,” right?

    O’Hanlon: Right, right.

    Vasiliou: You’ve got to break it down into smaller components and incrementally develop capabilities from there. Otherwise, how the heck are you going to baseline your progress for when you’re done? I think it’s too big, too broad, and some of the vendor promises may be of self-healing, auto remediation, maybe they were a little more on the hype side, where some of the other AI ops of components like root cause analysis or even correlation, maybe those are truthfully more on the hope and promise side.

    O’Hanlon: Okay. Do you think that AI ops – to your point, it is broad – do you think it just means different things to different people and so somebody actually may be implementing some type of AI ops and actually not realizing it?

    Vasiliou: The short answer is yes. So when we asked the question what monitoring tools or practices are used today, they were presented with seven options, ranging from application, infrastructure, experience monitoring, AI ops, and it was the fifth lowest, meaning that almost 40 percent of respondents said they’d never used it in the first place. The second question we asked is very simply what is the received value from AI ops, where one was the low value, nine was the high, and the range evenly spanned the value scale that was presented in the survey. What was interesting is there were a subset of people who said they never used AI ops but that they still received value, which was an additional dimension we didn’t think about when writing the survey.

    But it kind of brings me back to the essence of your question, which is are you user versus a consumer? And then go back to the previous comments about how big and broad this quote/unquote AI ops idea is, and there’s absolutely a propensity that people hear and think completely different things, unfortunately.

    O’Hanlon: Interesting. Interesting. So one of the things that we’ve been talking about in the SRE space over the last couple years is really how the role is kind of morphing and changing along with the market in general and to address a lot of organizational needs as well. Are there any findings from this year’s study that kind of bear out how an SRE role is changing and even if it is changing?

    Vasiliou: That will go back to what we were saying just a moment ago about mitigating the risk of their transformational activities. When you were asking the question, I’ll just cite the stat from our very first SRE report. We said that 85 percent of respondents said that in order to be successful in this role you have to commute into an office. So that got topsy-turvy turned upside down on its head.

    O’Hanlon: Right. Yeah. [Laughs]

    Vasiliou: But to get back to the essence of the question here, when we looked at the quantity of data sources and the prolific rise of the use of multiplatform providers, we sort of looked at this correlation between how SRE orgs are structured. Are you decentralized, are you centralized, or is there some type of hybrid in between? And then the decentralized piece was broken down even further by stack component, by platform component, or by business product or service. The vast majority of SREs said they are currently decentralized by business product or service, but I think the transformational piece here, which is something we’ll look at next year when we write the report, is because of the prolific rise of multiple third party and multiple same-service third party providers, there is a huge, gigantic spotlight to shift the primary dimension of org structure from product and service to a platform basis.

    And we talk about it like this. If you’ve got 10 different teams assigned to 10 different products or services and one member from each of those SRE teams developing capabilities that happen to be the exact same capabilities in development by those other nine teams, that’s the scalability and efficiency _____ that we start to lead in and talk about in this year’s report. So I think the transformational piece will be the assignment of SRE development engineering resources from product and service as a primary dimension to a platform – for example, cloud, CDN, DNS, API – as the primary dimension where those capabilities will be normalized and developed. Even though underlying platform structures will be different, those capabilities will then be offered as part of, let’s call it, an internal marketplace for use by multiple teams to kind of get away from that concept of silos and being segmented by product or service. So a bit of a long answer but all contextual to the key part there, which is the trend and the transformational piece that we wrote about this year.

     O’Hanlon: Right. Yeah, well it really is food for thought there if you consider how the SRE role was established and how it’s kind of – if you go down that path, how it seems to be changing and evolving as the more technology is adopted and more things are moved out to the edge and the need for SREs at basically all points on the network if you think about it. So great stuff there. Well, Leo, I know we could talk about all of the findings and have a much larger conversation, but unfortunately that’s all the time that we have for this one. But I do want to thank you very much for going through some of the survey findings. If folks are interested in taking a look at the study itself, is it readily available?

    Vasiliou: It is, it is. So it’s available at Catchpoint.com. Just head over to our learning and research section and enjoy the read. Charlene, one of the sentiments we wanted to leave readers with this year was this concept of baselining against Google’s definition of SRE, but we hereby declare by the power vested in us by absolutely nobody at all that you are hereby free to be an SRE.

    O’Hanlon: Oh, wow. Just one more thing to add to my plate. [Laughs] Well Leo, thanks again. I really do appreciate your time, and it’s a pleasure talking to you. I’m sure that we’ll talk again in the future about future studies that you guys have going on. So, thanks again. Really appreciate it.

    Vasiliou: You are quite welcome. Thank you for your time, Charlene.

    O’Hanlon: Alright, everybody. Please stick around. We’ve got lost more TechStrong TV coming up, so stay tuned.

    [End of Audio]

  • Best Practices for Modern IT Incident Management

    Best Practices for Modern IT Incident Management

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2021/06/best-practices-for-modern-it-incident-management.pdf”]

     

  • The Evolution of the Assessment of DevOps Capabilities (ADOC)

    The Evolution of the Assessment of DevOps Capabilities (ADOC)

    The Assessment of DevOps Capabilities (ADOC) is crowdsourced, vendor-neutral and designed for individuals, teams and organizations who want to baseline their current DevOps state, identify the next target state, gain insights into how to improve their organization and team capabilities and measure and accelerate continuous improvement during their DevOps journey.

    The assessment models five DevOps dimensions – the human aspects, process and frameworks, functional composition, intelligent automation and technology ecosystems – to help you gauge your DevOps maturity and identify areas for improvement. In this TechStrongTV interview, chief content officer Charlene O’Hanlon talks with Feisal Mohammed, Niladri Choudhuri and Don White about the evolution of the ADOC and how it can assist organizations at any stage on their DevOps journey. The video is below, followed by a complete transcript.

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Hey, everybody. Thanks so much for joining us today. This is Charlene O’Hanlon, I’m the Chief Content Officer at MediaOps, and I am very, very excited to be having a conversation with three very, very smart people from the DevOps Institute Ambassadors. We have Feisal Mohammed, Niladri Choudhuri, and Don White. Gentlemen, thank you so much for joining me today. I’m very, very excited to have a conversation with you all about the new assessment of DevOps capabilities.

    But first, I wonder if we can start by having you guys introduce yourselves. Please tell us your name, your title, your company, and what you think we all should know about you.

    Feisal Mohammed: I’ll start first—Charlene, is that okay?

    O’Hanlon: That’s perfect.

    Mohammed: Alright. Good morning, everyone, and good afternoon, good evening, where you are listening in. First of all, thank you for having me here, it’s a tremendous honor to speak today. My name is Feisal, I am with Sapience Consulting, I’m the Principal Consultant at Sapience Consulting, which is a consultancy and training firm that is headquartered in Singapore, but we deliver our services regionally in Southeast Asia and in Asia, per se. We’ve been in business since 2008 and our core expertise is actually in the area of service management, governance, risk, compliance, security management, and of course, in the last five or six years, the natural evolution of DevOps.

    And I’m proud and happy to be here. I’m a DevOps Institute Ambassador. I am leading the practice when it comes to DevOps for Sapience Consulting.

    O’Hanlon: Alright, great. Thank you, Feisal. Niladri, tell us a little bit about yourself.

    Niladri Choudhuri: Thanks, Charlene. I’m Niladri Choudhuri, CEO of Xellentro, India and Singapore. I’m also the Chief Organizer for the largest DevOps event that happens out of Asia, and coordinated the DevOps India Summit. And quite excited to be part of this panel because the ADOC, the Assessment DevOps Assessment Capability is going to be a great one, and we will further talk about it.

    O’Hanlon: Alright, great. Thank you, Niladri. And Don, please tell us about yourself.

    Don White: Well, I’m honored to be in the presence of some pretty brilliant folks that have been in the DevOps community for a long time. I really appreciate, Charlene, you inviting me. I come in to DevOps from a 15-year career in the software quality assurance space, and started with extreme programming and it evolved into the lean agile space, and then eventually got into DevOps.

    Worked with many small startups, got them transitioned into lean agile ways of working, extreme programming ways of working, and that led me into coaching and being a DevOps Dojo Sensei for the Fortune 1 company in the world. That catapulted me, launching my business, Agility Science, and that’s where I do consulting and coaching for people throughout the world, quite frankly, but mostly United States-based.

    O’Hanlon: Alright, great. Such an honor to have all three of you on the panel with me today. I love the breadth of experience and depth of experience that you all have and each one of you brings something different to the table, so I do appreciate all three of you being here.

    I want to dive right into the Assessment of DevOps Capabilities tool, I guess, for lack of a better word, it’s an assessment tool, that the DevOps Institute has recently released, and it is now available for organizations to use it to basically assess their DevOps capabilities. It’s one of those titles that needs no explanation, basically. [Laughter] But I think it’s a great tool, and I think it’s going to be very well received in the market.

    But I do wanna talk a little bit about the background of it. So, Feisal, maybe we can start with you. What are some of the challenges that you’ve seen in assessing DevOps capabilities in the enterprise? It seems to be, obviously, there is a need or this assessment tool, so what do you see?

    Mohammed: Well, for me, an assessment—any assessment worth its salt would need to have a good sample size. I think that’s essential. You need to have a really good sample size and not just depend on the responses of a select ________. Let me represent the—misrepresent the actual conditions, if you like, that the organization is actually at, right?

    So, what I do like about the ADOC assessment tool was that it allows for you to scale up the assessment. It allows hundreds of people to participate in this exercise. You know, if you do not have such a tool available, what happens is that this will be largely a manual, face to face process, right? And when it comes to a manual, face to face process of getting assessments, getting people to chime in on their views, chime in on their feedback—essentially, what you will get is tyranny of the loudest, right? The person with the loudest voice will be heard. And then you’ll get the messes that just shrink into the background, right, just disappear into the background.

    With this assessment tool, it allows people to, in some ways, some anonymity, and they’re braver to give their true assessment of where they are in terms of DevOps capabilities. I think that’s the really cool part about the ADOC tool.

    O’Hanlon: Alright. Niladri, what about you? What challenges have you seen with assessing DevOps capabilities in the enterprise? Beyond Feisal noted with having enough people to do a good sample, what do you see?

    Choudhuri: So, a couple of points. One point is, if you look at the assessment—who is doing what, is the point. So, there are multiple organizations or consultants who goes and does assessments. And one of the challenges which I see is that many of them thinks in terms of maturity. And like what I have discussed with John Willis and some of the people who have started the momentum of this, I mean, how can you have a majority of an outcome?

    It’s a continuous improvement process. So, we have to look at it from that point of view. Not that these 25 points have been ticked, so we are done, we don’t have to do any more.

    O’Hanlon: Right.

    Choudhuri: However good we are, we can still improve. So, that’s the first thing. And the second point, which I also see is that the senior, top people in the organization, they have, as people mentioned, they have a rosier picture of what is actually happening.

    And I have seen that, when I go to any of the conferences or even in the DevOps Enterprise ________, when you see them on the podium, the top management talking on the podium, I call it—I mean, it’s not that they are not doing good work, they are definitely doing good work, but it’s a more sanitized version of what is actually happening. When you talk to their team members during the breakfast or the lunch, you get to know a lot of the other challenges which comes up.

    So, as Feisal said, another very important aspect is to get the right information. So, one is the sample size. The other is, I would call it the psychological safety. The people should be able to come out and say what they really feel, and not always say everything is nice.

    O’Hanlon: Interesting.

    Choudhuri: Now, that, getting that right picture is very important, because ultimately, we all have to understand that we are doing it for the improvement.

    O’Hanlon: Yeah, that’s very well said—very well said. Thank you, Niladri. And what about you, Don? What are you sing? Because, obviously, you are working with so many different companies in so many different areas. I imagine you’ve seen these challenges kinda run the gamut, so what are you seeing out there?

    White: Everything that Niladri and Feisal said is spot-on. The one thing that I would like to mention is what to assess. Our assessment tool is so comprehensive and informed by all the expertise. And knowing what to assess is a huge part of it, but it’s really important to get a true, good assessment of the whole area. The psychological safety is absolutely spot-on. People need to be able to be true and honest about what’s going on, because you’re absolutely right, Ni—

    O’Hanlon: Niladri.

    White: – Niladri. The starting point, you can always improve. It’s all about that continuous improvement journey, but knowing where you’re at is critical. And most people try to think of the technical stuff—there’s so much people, the people part is the biggest part. And being able to assess the people part—because culture is my big thing. Culture is my huge thing, because if you don’t have the right culture, that mindset will not take root and it won’t grow, it won’t blossom, and you can’t grow it. you gotta get that culture right. The people part is the critical component.

    So, that’s—what I love about this assessment, it digs into that. It’s not just all the technological know-how, it’s the people pieces.

    O’Hanlon: I love that.

    Mohammed: And that’s spot on. If I just may add on a little bit and ________ on what Don said, I fully agree with you. The culture is the most important ingredient necessary for any movement to take place, right? Any maturing, any improvement—it has to be the right culture. And the thing about DevOps is, the organization is so—it’s so diverse, right, that DevOps may mean different things to different people.

    O’Hanlon: Mm-hmm.

    White: Yes.

    Mohammed: You ask a group of persons and they say, “Oh, we’ve got this set of tools, we are already DevOps.” And you ask another set of persons and they say, “Look, our processes are really lean. I think we’re DevOps.” And so, you know, people do not have a holistic, complete view of what DevOps is. And that’s fine. They’re coming from different perspectives. And when assessment comes in, it binds everything together, and it gives the true capabilities of what an organization is really capable of, right, from all aspects. And that’s really important.

    White: I mean, I learned some things just by taking the assessment of some things that I wasn’t even aware of, practices and things of that nature. And you know, quite frankly, we’ll take it next year and we’ll learn more, because DevOps is continuously evolving, right? That’s the big thing, especially from the technological perspective. But the people pieces—that’s the huge thing, the mindset and where you’re at from psychological safety, those are the huge pieces.

    O’Hanlon: That’s a really, really interesting point, because, you know, you think about an assessment, a lot of times, companies will take an assessment, and it’s kind of—in their mind, it’s kind of a one and done thing, right?

    White: Mm-hmm.

    O’Hanlon: And it’s kind of the same with DevOps, you never really—to your point, you guys, you never really achieve DevOps maturity, because the industry is changing so much.

    So, with that in mind, though, a company will take an assessment, they have the information—how do they use that information, and is it something that they treat as maybe, say, a living document that is constantly updated and improved upon? Niladri, I’d like to start with you on this question, because I think it’s very, very important that organizations understand exactly what we’re talking about when we’re talking about this assessment tool and DevOps in general.

    Choudhuri: Absolutely. Very, very important point, because that also has a lot of impact on what we get as the data. The point here is, we have to be very, very clear as a consultant when we are going with ADOC is that this is not a tool to fire your people. This is not a tool to evaluate your people, whether they are doing something good or bad. It is about how to make them more efficient, effective, and better. It is about achieving the organization’s goal, what needs to be done.

    That is definitely a very important aspect that I feel. Because if there is that fear, if there is, that psychological safety is not there and people think, “Oh, at the end of this, my management will look at it and see whether Niladri has done better or Feisal has done better and give a promotion or a hike to Feisal and not to Niladri, then Niladri is not going to deliver—I mean, give the right information.” Then the whole purpose is lost. So, we have to be very, very categorical in stating, as a consultant when we go, that this is for the improvement journey and not to punish somebody.

    White: I couldn’t agree more with that.

    O’Hanlon: Go ahead, yeah. So, Don, do you have maybe some thoughts on how organizations can use the assessment information after it’s completed? I mean, you know, we’ve made it clear that organizations really need to consider this as kind of an ongoing thing, and I think it’s super important that organizations do understand that. But, you know, maybe after the first assessment, what can they do with that information?

    White: Well, the big thing is, getting everybody having a collective understanding of what your current state is. And this is just one current state tool to get everybody collectively understood on that. Understanding your value streams and all that, those are all current state tools, but it’s a starting point to help you figure out a roadmap to move forward. It’s your starting point, and you look, and as a consultant, we can guide that, because we know kind of the sequential order in which you wanna attack these things, right? And we can help them prioritize their roadmap and their backlog of how they wanna proceed, is how I view it.

    O’Hanlon: Feisal, any thoughts on that?

    Mohammed: Yep. You know, assessments—Niladri’s right, Don’s absolutely right as well. Assessments shouldn’t be used for the wrong purposes. It should be guided by the real desire to improve, to move to the next level. That’s the first.

    The second thing is that an assessment shouldn’t be a one-time exercise. Look, I’m at an age where I’m doing health screening every few years, I really am. And every health screening, I get a snapshot of where I’m really at in terms of my health. And then I figure out, where are the areas I need to improve upon? Where are the areas I need to watch out? I need to look at just little bits of maybe change in lifestyle habits so that I get the benefits of the health assessment results, right?

    And it’s not a one-time exercise. I need to do a checkpoint assessment at some point in time in the future to determine whether what I’m doing is yielding the right results.

    O’Hanlon: Mm-hmm.

    Mohammed: So, it should be an organized, periodic set of assessments with predetermined, agreed plans to move from one state to a future desired state, and then those assessments take place over and over again, heading towards that general direction of improvement, right?

    So, one thing we need to debunk is that we do it once, then we figure out what to do, and then that’s it. No, we need to constantly evaluate. We need to constantly assess ourselves in regards to our capabilities.

    O’Hanlon: So, it’s not just about understanding or taking this assessment and understanding where you are, though, but you also have to have kind of that guidance, I you will, from folks who are experienced in the field. You know, it’s one thing for you to—Feisal, if you went to the doctor and you got the tests done and thy explained to you exactly what the results were.

    Mohammed: Yeah.

    O’Hanlon: But if you went out and did all the testing yourself, you’d look at all these numbers and say, “I have no idea what this means.”

    Mohammed: I would not only have no idea, I would probably be alarmed, you know?

    O’Hanlon: [Laughter] Right.

    Mohammed: I’d think, “I should be dead by now,” right? I’m looking at all these test results—but you do need that expertise to help break these pieces of information down for you, calm you down, and say, “Look, these are the steps that you need to take,” right?

    O’Hanlon: Yeah.

    Mohammed: There are a lot of things that you can do, there’s a lot of things that you should do, right, but these are the things that you should focus on immediately in that journey, right? There’s an order is what Don said. There’s a sequence, there’s a realistic sequence which you can undertake, right, to gradually improve and hit towards the general direction of excellence.

    O’Hanlon: Exactly, exactly.

    Choudhuri: If I may, Charlene—so, this is a tool which is helping us in moving to improve the way of working. And taking what Feisal said, that it’s not a one-time activity—so, we have to look at that evolutionary process of improvement. So, you look at an assessment, you find the weaknesses in the different, the five dimensions, then you decide, “Okay, let’s look at some of the value streams where the weakness is more,” decide on what you need to do, whether you need training, whether you need automation, whether you need whatever change in the process, you do it, you take it forward, you go for another set of assessments. And you keep improving on your journey.

    Because today, what is important to understand is, we have to be adapting to the changes that is coming and more to come.

    White: What I would like to also—

    Choudhuri: And this will help you with that.

    White: What I would also like to point out is, you also need to keep the outcomes. Why are you doing all of this in the first place? Make sure that that is what you’re driving all of this toward.

    The other thing I wanted to point out is, there’s the enterprise assessment and then you have, I think, a team assessment. And so, you use enterprise to kinda get a holistic picture of it, and then once you kinda figure out where you’re at holistically, you can figure out where within the organization you want to do it. Then you can assess those areas, and then you continue to assess those areas as you’re continuing that journey, and it’s a continuous process.

    And Feisal, I love your metaphor with the health. I think that really resonates well, because it’s really what—it’s very similar to that. We assess all the different metrics in our body—well, just look at an organization as an organism, right? An organism that has health concerns, and we need to tweak that with continuously assessing it and coming up with a roadmap and a plan and then executing on it, and then testing our hypotheses that we’re moving toward our outcomes that we’re trying to achieve.

    Mohammed: Absolutely. And it should not be a project, it should be a program.

    White: Yes, yes.

    Mohammed: Right? It should not be a one-time effort, it should be a program effort—weight management, health management is lifetime. It should be that way, and organizations should embrace that.

    White: And the wider it’s within the organization, the better, because the folks that—if you’re just dealing with a partial part of the organization, well, those people that are going through the transformation are not working in a vacuum, they’re working within an organization that needs to kind of be on the same page, because they need to interact and collaborate with one another. If they’re not on the same page and wanna keep the old ways of working and are not open to being able to collaborate and work with these people that are trying to do more DevOps stuff, they’re gonna have limited success.

    So, the broader the understanding of this journey is, the more successful it will be.

    Mohammed: Agreed.

    O’Hanlon: That’s a great point, that’s a great point. And, you know, Don, just to kind of expand a little bit on that and the need for having somebody who’s kind of an experienced person who’s been in the business for a while to kinda help them through the assessments—I would imagine that it not only helps them understand where they are, but also kinda help them build a roadmap for where they need to go, and also show them the areas where they’re in need of most improvement and, from a culture perspective, I imagine that that is super important for organizations.

    White: Absolutely, yeah. Being able to prioritize your plan of attack and know where you really need to focus your energies, but being able to assess your actions is just as important. Because you have a hypothesis that you’re doing these things that are going to move you closer to your goal, but after you do those things, you want to validate your hypothesis by assessing.

    O’Hanlon: Right, right, right. Alright, and offering up areas where maybe the organization hadn’t thought—they would not have thought on their own. So, interesting stuff. Alright.

    Hey, guys, I would love to have this conversation for hours, and I know we could, but we are running up against our time. But I do want to thank Feisal, Niladri, and Don for such a great conversation. I wish you guys the best of luck with ADOC, and I think it’s gonna be a great success. You guys are awesome, you’re so well versed in the DevOps space and you really know your stuff, so considering the fact that you guys were involved in creating it, I know the industry is definitely gonna get a lot of value out of ADOC.

    So, thank you, again, and thanks so much for getting on the Zoom with me and talking about it and about the market in general. So, thanks again—it was great to see you guys.

    White: Thank you. Pleasure meeting you, too.

    Mohammed: My pleasure. Bye, guys.

    Choudhuri: Bye.

    O’Hanlon: Alright, everybody. Please stick around. We’ve got lots more coming up, so stay tuned.

    [End of Audio]

  • Ambassador Insights: Value Stream Management

    Ambassador Insights: Value Stream Management

    Value stream management is the next critical evolution for enterprises and organizations that want to further mature their efforts toward smart, efficient and effective software development and delivery. The need for ongoing software innovation and delivery is becoming a top priority for all businesses today, thanks to the new digital demands organizations are facing from their employees and customers.

    Value streams help ensure that software and services under development deliver on the promise of value for employees or customers. But it’s not as easy as it seems; plenty of enterprises still struggle to know exactly what value is being derived from their software development efforts.

    In our third episode of Ambassador Insights we talk with DevOps Institute ambassadors Siddharth Pareek, the Global DevOps Center of Excellence Leader at NatWest Group; Garima Bajpai, the founder of Canada DevOps Community of Practice; and Steve Pereira, founder of Visible, about how value stream management can help enterprises on the next step of their software development journey.

    The video is below, followed by a transcript of our conversation. Enjoy!

    Transcript

    Charlene O’Hanlon: Hey, everybody, welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I am here now with a group of very, very smart people in the value stream management space. They are part of the DevOps Institute Ambassadors, and they are here for our monthly installment of the DevOps Institute Ambassadors Insights Panel Discussion.

    This month, the topic is on value stream management, so like I said before, these guys are experts in the field, and I’m sure we’re gonna get some really insightful information from them. Thank you, all three of you, for joining me today.

    We have Siddharth Pareek, who is the Global DevOps Center of Excellence Leader at NatWest Group. Siddhartha, thank you so much for joining me today.

    Siddharth Pareek: The pleasure’s all mine.

    O’Hanlon: We also have Garima Bajpai, who is the Canada DevOps Community of Practice—is that correct, is that your correct title, Garima?

    Garima Bajpai: Yes, I’m the Founder for the Canada DevOps Community of Practice, and thank you for the introduction.

    O’Hanlon: Alright. Well, thank you for joining me today. And last but certainly not least, we have Steve Pereira, who’s the Founder of Visible. Steve, thank you so much, it’s great to see you again.

    Steve Pereira: Thanks. Great to see you, it’s great to be here.

    O’Hanlon: Alright, great. So, let’s talk value stream management. You know, it’s something that we’ve been talking a little bit about here and there on devopsy.kinsta.cloud over the last couple years, but it seems like in the last year or so, especially, it has taken on more steam, if you will. It’s definitely more significance, a lot more people having the conversation about value stream management and its role in organizations, but I think it’s probably important that we at least start at the beginning, level set a little bit, and maybe, Steve, we can start out with you. Can you just kinda maybe loosely define what value stream management is and what it means to organizations?

    Pereira: Yeah, absolutely. That’s a great starting point. I think folks in the DevOps space are familiar with the origins to a degree where we had agile kind of be wildly successful in boosting development performance, right, and then all of a sudden, we hit this block where it’s like, okay, well, we can’t really go any faster unless we look at the bigger picture, right, and we start to involve Operations.

    Well, that’s where I see value stream management now is that DevOps has reached this point where we’re seeing massive performance improvements, we’re seeing a lot of positive outcomes, and we’re hitting the boundaries of that where all of a sudden, the bottlenecks and the opportunities are elsewhere at a further zoom point. So, if we now zoom out again and look at a larger sphere of influence, there’s a ton of opportunity outside of DevOps where value stream management is really the recipe for success. It’s a holistic operational capability that allows you to tie together this big picture view of your organization—and not just software development, but value streams are everything in your business, right? Your entire organization is just a collection of value streams delivering value to customers.

    So, the ability to organize, visualize, measure, and manage all of that in a very, let’s say, low touch, high automation way is going to be a game changer for organizations of all kinds, whether they are primarily software driven or building and delivering software, or if they are supply chain health care logistics, it really doesn’t matter. It’s gonna touch everything, because it has to, to drive the level of performance that we want and that end to end level of productivity.

    O’Hanlon: Okay, alright. Garima, have you, in your position, you’re obviously very deeply embedded in the DevOps space, have you seen kind of an increased interest in value stream management over the last year, especially in the DevOps space?

    Bajpai: Yes, I have, and I actually come from a large enterprise background and I work with complex systems, largely monolithic environments, which are transitioning into cloud native applications.

    Now, when we talk about these large enterprises, value stream mapping, to me, has been a tool in the toolbox of value measurement. So, I would actually reflect from the standpoint where Steve had left. So, value stream mapping, to me, is as much an art as it is science. So, what Steve was mentioning, the scientific aspect of value stream management, which is basically leading to more productive, cost-efficient organizations where we can bring speed and scale.

    But it has also an element of creativity where we bring the discovery part of the value, right? So, how do we ensure your value stream management is able to discover new value for the organization? That’s the first point. The second point is, visualization of that value is also important. So, how your value stream management is able to map all the complex value streams which you have in an enterprise and bring it together to visualize that value in one way. So, that’s the second thing.

    I also wanted to bring another point, which I have experienced when working with large organizations. When you think about a data-driven approach towards value, there is no unified process to combine the value in one way, to build consensus in the organization. There are various functional silos and complex structures, and there is a maze of organizations which we have to bring together for consensus building. And that is where value stream management is pretty useful.

    And the fourth aspect I would like to bring from a creative aspect is, we also combine value stream management with applied data science to produce the future of the organization, the future state, defining the future state.

    So, these are the four elements I would like to bring into the conversation, probably changing the conversation a bit as well, so, let’s see how it goes. [Laughter] 

    O’Hanlon: [Laughter] Alright, great. So, Siddharth, kind of expanding on that, is your organization currently using value stream mapping or value stream management, and if so, have you guys noticed any changes in when you’re using it versus before you started using it?

    Pareek: I’ll put it this way. We’re at the starting phase of the journey of adoption of these value stream mapping concepts. And I could easily answer and say that what Steve and Garima said, I’m done with it. But I’ll add something to the flavor so that the audience understands value stream mapping more.

    What you are doing when you’re talking about DevOps is, you’re talking about reducing failures. We are talking about releasing early, we’re talking about less failures, less bugs, all those things. What is really the customer’s, the end user who is really worried about it, really concerned about it, maybe not. They are probably concerned about the customer satisfaction. They’re talking about how much reviews they’re getting on their product on different platforms, or maybe more.

    And what is happening is, there is a gap between these two things—what developers are delivering and what the customer is expecting. And that is where the role of value stream mapping comes from, where it bridges the gap between the IT side and the business side, which is clearly visible to everyone across the stream. And what it does is, it tells you a similar story for everyone. When you ask a Dev guy what are the values you’re delivering, he will not talk about incident reductions or chain failure occurrence or DORA metrics, all those things. They will talk about, we are delivering what businesses expect of us.

    Coming back to the story of why, how much it is done within the organizations of ours, I think this needs to be picked up and probably come up in the later conversations. Why it has not been done so much, because of the problems that exist within the organizations.

    So, in short, we are starting the journey, but miles to go.

    O’Hanlon: Okay, alright. So, it sounds like value stream management is a great idea and organizations really should be considering it, but it might not be as simple as just flipping a switch or saying, “Hey, let’s do value stream management.”

    So, what are some of the things, then, that may be tripping up organizations as they start on their value stream management journey? And Siddharth, since your organization is kind of in that place right now, what are you seeing as kind of the roadblocks, if you will, to value stream management in your organization?

    Pareek: I mean, we talk about value stream mapping, we talk about a holistic view of the place on the left-hand side where the idea generates to the place on the right-hand side somewhere, where the value is delivered to the customer. And over there, software development teams or a testing team has a small role to play. 

    The bigger roles are your governance, your security, your compliance. How can you visualize them? How can you make, you know, process re-engineer them? For example, the NatWest Group which I worked for, they have huge compliance laws that need to be followed. Can just a simple value stream exercise streamline them? Maybe yes, maybe no. And why I say either of them is, because it depends upon the deep-rooted problems that could be solved or could not be solved going forward.

    O’Hanlon: Alright, great. Steve, I know your organization deals a lot with companies that are going through the value stream management kind of adoption journey. So, what are you seeing as some of the things that organizations are having trouble with as they start out using value stream management or as, even in their consideration phase?

    Pereira: Yeah, there’s a lot going on. There’s tons of complexity. There’s a huge spectrum of circumstances. Certainly, Siddharth really touched on a major one, which is the existing requirements in an organization that enforce the status quo, right? The things that keep us where we are, are these powerful forces of, like, things need to be done a certain way and we expect them to follow process. So, thinking of how to improve process or things that will affect the flow of value through the organization always get pushed to the wayside, right? Because it would be nice to have that, but we gotta keep everything rowing as is, right? We can’t risk that and we can’t ever forget about the fact that nothing can fall through the cracks in the status quo.

    But that’s where we see that drift, you know, the slow drift into legacy and calcification and friction is that. That doesn’t mean that you’re moving forward, right? It doesn’t mean that you’re going to make progress. And the promise, here, of value streams is really in re-orienting the entire organization to be driving vastly improved value flow, but also, as Garima mentioned, innovation, right? It’s not only just making things better, it’s making better things and it’s making different things, right? It’s this idea of thinking in terms of value and orienting towards value allows you to re-imagine your entire organization, and that is kind of the promised land. 

    But to get there, you have to get over the realities of the org chart, right? The realities that we structure our organizations based on legacy hierarchies where everyone has to fit in and report to somebody and then they have reports and you have to go up and over through the org chart. If you look at an org chart and you map the flow of value to the org chart, it’s just this wandering path that goes all over the organization and no wonder it’s inefficient, no wonder we struggle to deliver value and really make meaningful improvements.

    So, I think I would say demoting the org chart in terms of importance and focusing more on the streams and the interactions between the streams, starting to see those streams, and then aligning our teams and aligning our activities and our operations to those streams is no easy feat, but we can start really easily by just seeing it, right? Just seeing what’s going on, just observing the current state, that lays the groundwork.

    So, I would say that there can be a lot of defensive reactions to the idea that the org chart is not that important to customers, to value delivery. That could threaten people who are really invested in that hierarchy and their position in it. But ultimately, it does bring everybody together in a much more meaningful way to think in terms of streams.

    The other challenge, I think, is that, when we think about surfacing gaps and surfacing issues, a lot of cultures means that people get pointed at, right, and it’s, they’re scapegoating and there’s people, individuals who are responsible or those challenges, and we know that that’s not true. But the cultures that are in legacy trouble, are in these calcified states and not succeeding with transformation efforts, it’s often because that’s the mindset. The mindset is, we need to find the person accountable and force them to tackle the problem. It’s not our problem, it’s their problem, because I have my problems and someone’s trying to scapegoat me for something, so it’s only fair it’s going around, right? 

    And the level of visibility and the metrics and the measurements that you can get from value stream management can be used or abused, right? You can use those measurements to draw all kinds of conclusions, and in the wrong culture, it can be weaponized. That’s not to say that there’s not a ton of value and a ton of promise there, it’s just, if it’s misapplied or it’s done in a way that’s more kind of tailoristic or legacy founded, you’re potentially doing harm by surfacing all of this reality that people tend to ignore and just go about their business.

    O’Hanlon: You bring up some good points, and obviously, it doesn’t sound like value stream management, adopting it, is a walk in the park, but obviously, there are clear benefits, otherwise organizations really wouldn’t be considering it.

    I’m wondering if you could maybe kinda choose one or two things that maybe organizations need to do to derive the value from value stream management. Garima, I’d like to start with you. What are some of the things that, as I said, organizations really need to do to kinda derive that value from value stream management? Considering all the things that Steve just said, it sounds like there’s really an uphill battle for a lot of organizations.

    Bajpai: Right, and I think we will start from what Siddharth as well as Steve has mentioned that, coming from a large enterprise background, I see that there’s a lot of valueless complexity in large organizations, which quickly leads us to job security. So, there is a lot of organizations which are struggling with this problem.

    Now, to disable this problem, I think what we will necessarily have to do is, first of all, nobody wants to do a useless job. We need to be sure that we have inculcated behavioral aspects into value stream mapping. And, you know, looking from a bird’s eye view perspective, there are three things which we need to necessarily do.

    The first and foremost thing is empowering people and building accountability where you can actually visualize that in your value stream map, everybody is accountable for a value, you know? Nobody wants to do a useless job, right?

    The second part of this whole problem is making the value stream mapping as efficient as there is a loop that is basically, you’re incrementally building the value, you’re not trying to kind of big bang this approach of doing your value stream mapping and engaging everybody to kind of ensure that we decompose this complexity in the organization.

    And the third aspect, which is really very important, is that, first set the strategy. Whenever you are trying to do a value stream management, what is the objective? There can be four objectives—cost, you might need to ensure speed, you might need scalability in the organization, or you want to introduce new value into the value stream. So, there are four possibilities. So, what are your key objectives? Just define that strategy before you prioritize or you do any kind of decomposition of the value stream, from a value stream management perspective.

    O’Hanlon: Alright. Siddharth or Steve, do you have anything that you’d like to add onto that?

    Pareek: Yep. One thing is, and the organizations started very wrongly is, to confuse value stream mapping with the process mapping, to think both are somehow a similar exercise. However, people need to understand, process mapping talks about a very micro view of what things are happening, whereas value stream mapping talks about the macro view.

    And why that is important to know is, if you go into the process mapping stage, you may optimize one component of your whole floor, which is good for that component, but if you look holistically, it may create chaos for other components as well. 

    So, let’s suppose, you know, you will have streamlined a manual process of delivering certain products at a faster rate. You’ve improved that process, but what you’ve done is, maybe for other components, you have created a long stack of inventory to clear it out. And that is where this value stream mapping would come across. Because you’re going one level above the thought process, or from micro to macro. So, that is one proof that people make it happen.

    The second thing that makes it happen is, people go with jumping on the value stream mapping exercise or sessions they need to have. The first and primary thing is, they need to get the buy-ins of those stakeholders, because after the exercise, this scenario, the output would be very scary for people, accept and to action upon. So, they should have a good acceptance that yes, we agree to what happens after these sessions. Two things. I think that’s it from my side.

    O’Hanlon: Okay. Steve, any thoughts?

    Pereira: Yeah, I think that one thing that I want to clarify for the audience is that we’re talking a lot, I mean, this session is about value stream management and we keep talking about value stream mapping. And it speaks to the starting point, you know? It speaks to how you actually start to make traction with this and get going is understanding the big picture and it starts with mapping. And for me, it starts with mapping outcomes to obstacles and key objectives in the organization.

    So, starting with clarity, and we’re talking about the difficulty involved here and how complex this is. Really, we’re getting so much better at adopting these techniques, because we’re starting to realize that you can’t get there with agile, you can’t even get there with DevOps, and we struggled for decades trying to make this work. The value stream thinking approach, the holistic approach, the fact that this is the entire organization and it’s entire ecosystems that are involved in this. The flow of value is larger than we imagined initially, right? It’s not software development, it’s not even Development and Operations, right? It affects everything in the organization, but that perspective puts you decades ahead of where we were stuck in the mud.

    And so, just adopting that way of thinking and stepping back and saying, “Okay, well, what’s really going on here? What are we dealing with in the current state?” That’s gonna put you in this really strong position to adopt things like value stream management. But value stream management to me is the act of managing the value stream. It’s not software. There are tools that are available to do that job and we’re in early days of that, but management is the act of managing value, right? It’s visualizing, it’s tracking the flow, it’s understanding the flow of value through the organization.

    So, that really, to me, starts with mapping and this baseline view. And I’ll echo everything that the other folks said—bringing in the right perspectives from the top to the bottom is really gonna make that happen. And it’s really, you know, the first opportunity where we’ve had that invitation in a very accommodating way, right? This is truly inclusive. There’s something in this for the business. There’s something in this for customers there’s something in this for technical folks, and everybody gets some value out of it. Everybody gets tons of value out of it, but it’s not just, “Yeah, you need to look at DevOps, because otherwise, this tech thing is gonna get out of control.”

    O’Hanlon: Mm-hmm.

    Pereira: There’s messaging and there’s value in it for the business, and there’s something in it for the customers, and that’s unique and that is a perspective that we’ve never had before, but is starting to come to reality.

    O’Hanlon: Alright. Well, definitely, as I said before, we’ve been having the conversations on devopsy.kinsta.cloud about value stream management and value stream mapping, and I firmly believe that, at the very least over the next year, we’re going to be hearing a lot more about value stream management. 

    So, Steve, Garima, Siddharth—thank you, all three of you, for bringing your expertise to today’s DevOps Ambassadors Insights Panel on value stream management. I appreciate it very, very much, and I do value your expertise, so thank you, all, for joining me today. I really do appreciate it.

    Pereira: Thanks for having us. Great to see you all.

    O’Hanlon: Alright.

    Bajpai: Thank you. Bye bye.

    Pareek: Thanks, Charlene. Goodbye, everyone.

  • Helping Bring Balance, Diversity to the IT Workforce

    Helping Bring Balance, Diversity to the IT Workforce

    It’s a fact: Minorities and women traditionally have been underrepresented in the IT space. According to the Brookings Institute, less than 7% of computing and math-related jobs are held by people who are Black and Latino. And while women are faring better, they still only represent about 30% of the workforce in computer and mathematical occupations, according to the institute. Clearly, there is more work to be done in creating a balanced, diverse IT workforce.

    At MediaOps, one of the traits I believe helps define this company is inclusiveness, recognizing the value each person in our organization brings to the table. Different educations, different backgrounds, different perspectives … they all help us see the world in a different light and make decisions that are rooted less in biases and more with a deeper understanding fomented by the populations each of us represents. This, I believe, is fundamental in achieving balance; by recognizing and celebrating our differences, we create a strong, unified organization.

    Be the Change

    It is with the goals of diversity and inclusiveness that MediaOps is proud to announce “Engineer the Change,” a scholarship program in conjunction with Boca Code, an immersive coding school that provides in-depth technical training. MediaOps will sponsor two scholarships annually to students from disadvantaged communities interested in pursuing a career in the tech industry. The scholarships, each valued at $10,000, will enable students to enroll in the flagship Software Engineering Career Course at Boca Code.

    The “Engineer the Change” scholarships will be awarded to two deserving recipients on an annual basis. To be eligible, applicants must be 18 years or older and be part of an underrepresented community. To be considered, applicants will be required to submit an essay detailing how they can serve as role models to other disadvantaged individuals hoping to acquire the skills to become successful tech workers, and what type of career in the tech industry they are hoping to pursue. While the idea is to help the South Florida tech community, applicants can apply from anywhere, as long as they include in their application essay why they are coming to South Florida to launch their tech career.

    Submissions for the first scholarship for the Software Engineering session, taking place April 5-June 4, are now open. The deadline to apply is March 15. The second scholarship application process will open Aug. 1 for the session taking place Sept. 20-Dec. 3.

    To learn more about how to apply for the scholarship, please visit: https://mediaops.com/engineer-the-change/

    Get Involved

    MediaOps is offering these scholarships because we believe diversity enriches everything. We encourage other companies to do their part to help promote diversity and inclusiveness, both within their organization and through programs targeting underrepresented communities locally or regionally. It is time for the IT sector to do its part in promoting technology to women, minorities and other traditionally underrepresented groups; only by getting involved today will we help shape the next generation of technology workers.

  • Ambassador Insights: Cloud-Native

    Ambassador Insights: Cloud-Native

    Cloud-native is a methodology and a mindset that’s been gaining traction in the DevOps and application development space as more organizations look to leverage the benefits of cloud infrastructure, including scalability. As with many other topics in the DevOps space, however, cloud-native isn’t easily definable; rather, it is loosely described by the technologies it utilizes, including containers and Kubernetes.

    In our second episode of Ambassador Insights, featuring DevOps Institute ambassadors Leonardo Murillo, CTO of Qwinix Technologies; Tracy Bannon, senior principal and DevOps strategic advisor and software architect at MITRE; and Pawel Piwosz, lead system engineer at EPAM Systems, we delve into what it means to be cloud-native, look at some of the cloud-native technologies helping shape the landscape and address the security aspects of cloud-native applications and infrastructures.

    The video is below, followed by a transcript of our conversation. Enjoy!

    Transcript

    Charlene O’Hanlon: Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I am here with another episode of the DevOps Institute Ambassador Insights Panel Discussion. I’m so excited to have these on a monthly basis with some very, very smart people who also happen to be ambassadors with the DevOps Institute. And each month, we have a different topic of discussion to align with our monthly spotlight topics on devopsy.kinsta.cloud.

    This month, we are going to be talking about cloud-native and cloud-native technologies, and so, I have some experts in the field right now. First up, we have Leonardo Murillo, who is the CTO of Qwinix Technologies. Hey, Leonardo, thank you so much for joining me today.

    Leonardo Murillo: Thank you for having me, Charlene. I really appreciate it. This is great.

    O’Hanlon: Alright, alright. Next up, we have Tracy Bannon, who is the Senior Principal and DevOps Strategic Advisor and Software Architect at MITRE. Tracy, thanks so much for joining me, we really appreciate it.

    Tracy Bannon: Thanks for the invite.

    O’Hanlon: Great. And finally, last but not least, we have Pawel Piwosz, who is the Lead System Engineer at EPAM Systems. Pawel, thank you, also, for joining me today, we really appreciate it.

    Pawel Piwosz: It’s a pleasure to be here with you.

    O’Hanlon: Great, great, great. So, let’s dive right into the discussion. I know we’ve been talking on devopsy.kinsta.cloud and Container Journal a lot about cloud-native, but I’m not sure, actually, that a lot of people understand exactly what we mean when we say cloud-native, so maybe we should set the stage, if you will.

    Leonardo, maybe you can start us out since you are really focused heavily on cloud-native. Can you kinda tell us what we mean when we say cloud-native? What are we talking about?

    Murillo: Sure. So, I think when we talk about cloud-native, we’re talking about a specific mindset and patterns to apply when we’re building both systems as well as organizations, which is kinda one of the things that I wanted to discuss today, right? Because cloud-native is not just how you build technology, and you don’t really need the cloud to build cloud-natively, right? Usually, when you think in terms of cloud-nativeness, you’re thinking about loosely coupled architecture, you’re thinking about containerization, immutability, statelessness, right? All of these are components that are incorporated in a cloud-native solution, and I think the organization has also to become cloud-native, and that’s where DevOps becomes really important, right? To be able to leverage and really take advantage of all the different qualities, right, that the cloud has basically surfaced and made available, right? What do you think, Tracy?

    Bannon: To extend on that and sort of foot stomp for what you’ve said already and love that you want to talk about the organization, we can talk about, I call it a reverse Conway maneuver.

    Murillo: Right. [Laughter]

    Bannon: [Laughter] So, there’s a lot to be said—I’m actually finding that there’s not agreement on what cloud-native is. There’s an argument—it means containers. Well, yes, and let’s talk about serverless and the impact of serverless. So, it’s not a specific architecture pattern, but it does mean that we are building to take the best advantage of the infinite scalability, right, and the self-healing nature and other aspects of cloud. Love your point as well, Leonardo—while we say it needs to be on cloud proper, building for cloud, right, doesn’t mean that I’m necessarily hosting in an AWS GCP, et cetera and so on. It means that I have applied those principles, and I can do that within my data center, my private cloud, or whether I’m paying somebody else to be the host for me.

    Murillo: Yeah, great point.

    Piwosz: That’s true, and it’s not only about the application, it’s about everything what is around. For example, CI/CD, how we store our code, how we approach to the code, how we approach the security networking. Because this is something that we very often forget when we are going to the cloud, right?

    O’Hanlon: Mm-hmm.

    Piwosz: So, platform as a service, we have everything, we don’t need experts.

    Bannon: [Laughter] Don’t get me started at all!

    O’Hanlon: [Laughter]

    Bannon: But that’s an interesting point is that there are so many fantastic capabilities that are being provided as a service that I don’t think the folks actually know where to begin. I’ve had some awesome infrastructure folks who go out and they do some Googling and they do some research and they come up with a reference architecture. And heaven forbid, but God love them, they go out and spin it up and push the button, and—wow, this is a good solution for my firm or for my client or for my needs—and it isn’t, necessarily.

    So, there’s a lot of trade space that we’re unintentionally losing with the rapidity that we’re moving, trying to move towards cloud. Architecture should be more important, not less important. It shouldn’t be a stalling factor up front, but I jokingly say that, in order to push some value, provide value out into industry or to my clients, I have to be doing that from vision forward, right? I can’t take a steel girder and put it through a wood chipper, right? It’s not going to work because it wasn’t constructed and thought of that way.

    But Leonardo, to your point earlier, as much as the technology to me is the fun and sexy part, the human aspect really needs to be dealt with as well. We talk about it a lot in the DevOps piece of it, the DevOps portion or support effort on it, but you really bring up that cloud-native requires us to think about the organizational structure and building a separate culture than what we’ve had before. I’d be interested in what you think about some of the emerging software factories, or should I say continued proliferation of software factories as the way to move forward on software?

    Murillo: I think that actually talks about kind of a different subject, and I’d like to kinda step back a little and think—because you mentioned something that is very much aligned to this, and it is the whole strategy as to how you approach the cloud, right? It’s not just about click a button and going in, right?

    Bannon: Mm-hmm.

    Murillo: And, to me, that has a lot of resonance to what DevOps is all about, right? If you think into kinda the cada mindset, right, define your North Star first, right, assess your current state, think about it consciously and mindfully, right?

    I think if organizations that are looking to go into the cloud or mature into the cloud do take that step, do take time, they will be able to maneuver this gigantic ecosystem of tools that are out there and technologies that are out there. Because I think there’s also an interesting component that we should discuss. You mentioned, Tracy, how it’s not just about the technology, it’s also about the humans, right, the people that are implementing.

    Bannon: Mm-hmm.

    Murillo: But I think that also resonates with the fact that technology is not there just for the sake of picking the latest and greatest tool, right? I read this great post by somebody that I can’t recall, that basically talked about how boring is good. You know, how boring technology is good because people are used to it and they’re kinda like aware of how it works.

    And I think the closer you are in your evolution path to what is comfortable, the better. And I think that’s one of the problems that I sometimes see in cloud adoption—people try to bite too big of a chunk of change at a given time, right?

    Bannon: Yep. Mm-hmm.

    Murillo: And there’s so much to choose from to make that huge bite. An actually targeted approach that is mindfully defined that is well strategized will solve a lot of these problems, right? Because it will give you a signal amongst all this ecosystem noise that teams are gonna be exposed to, right? So, Pawel, you are kinda like engineering these solutions, right? How do you work around this ultra-diversity of available technologies, right, when you’re building something?

    Piwosz: Mm-hmm. This is … a very big problem. Because right now, together with cloud, we gained much, much more speed with everything, really. So, imagine 20 years ago you had a server room with racks and servers there, so you’d change only the server, but the logical side was still the same.

    Today, we are jumping. Let’s stay with AWS. We are jumping from instituting analysis to microservices, then to serverless microservices, then to serverless itself. Who knows what we will find next year, for example, right? You need to switch your mindset here. This is something that especially all kinds of CisOps—well, I am all kinds of CisOps—people have in mind, right? The same for networking, for security. There is a huge difference in speed here.

    So, you need to incorporate into your mind things like do fast, fail fast, learn fast—especially learn fast, because we are forgetting about this very often; too often, I would say. And also, we are forgetting very often in the trenches about the security of the cloud.

    Bannon: Oh, gosh, yes.

    Piwosz: Because—yes, because we’re saying, okay, we have a shared responsibility model, so they are responsible for everything. We’re just running our application and not caring about anything else, what is really, really wrong, I believe.

    Murillo: And I think that points to a fundamental misunderstanding, right, of what security in the context of cloud native architecture is all about, right? And I also think about, Tracy mentioned this infinite capacity, right? And you mentioned, Pawel, going fast.

    I’ve been thinking a lot recently as to how those two components need also to be very effectively managed.

    Bannon: Yes.

    Murillo: By leadership, by those that are sponsoring these initiatives, right? Because after all—and this is something that I’ve been talking about lately, right? We have optimized for speed alone already without having, really, awareness of the impact that that would have on the environment and many things, right? And I think we really need to establish a mindset where engineering teams are aware that infinite capacity doesn’t mean just free for all, grab whatever amount of resources you have, that shared response security is not infinite, overwhelming security, right?

    And I think this is also relevant in the context of the tooling that we were talking about, right? Everything now is available kinda point and click. You download a package, you have an appointment. You download another package, you have authentication and connectivity, right? And we don’t go into details necessary to understand kinda the supply chain of all these solutions.

    So, I think that’s where—the mindset of DevOps, right, reduce waste also becomes very relevant, right? Just because you have infinite capacity doesn’t mean you can’t be wasteful or you don’t have to be constantly evaluating the outcome of your ongoing efforts, right? Yeah, so, I think that’s very important.

    Bannon: There’s a treasure trove of topics that you just landed on, so it sounds like it could be a longer collaborative.

    O’Hanlon: Yeah, right. [Laughter]

    Bannon: So, in terms of reducing waste, one of the things that I’ll put out there is that I believe, in what I’ve observed with teams that I run or teams that I’m reviewing the content is that some of the cloud capabilities have made us, I think, lesser programmers, lesser developers, because we’re not concerned about the same things that we were before. We’ve delegated authority or we’ve delegated that concern.

    I’ve seen some pretty hideous, performance-wise, if I were to run it anywhere other than being able to up my compute, it used to be that we had to be concerned because it cost a lot to add additional resources, right? If it wasn’t as performant as we needed it to be, you just threw more hardware at it. That went away for a long time because it was cost-prohibitive.

    We’ve almost gone back and revisited that in some ways. From a security perspective, it’s always been my perspective that it needs to be baked in. It has to be part of the ecosystem. So, when folks started talking about DevSecOps, I was actually against that, because DevOps means that there’s a security part of it, but I do understand that it was, at times, not thought about. Our developers need to be educated, but they need to be held accountable because it becomes—there is a group effort. Now, when I say developers, I mean the athletes who are hands-on, they’re engineering with us, they’re moving the software forward.

    But there are two pieces that come to mind with this. There’s a limit to how much they can consume. Mentally, there’s a limit to how much they consume. I’m looking at Pawel’s background and I’m thinking to myself, “I love all the stickers” and yet, those are all the technologies that he’s considering that he’s looking at. So, as leaders in technology, one of the things that we need to do is to provide guidance to the folks who are on our teams to help them reduce the noise. It doesn’t mean to ignore the new things, but it does mean go ahead and get to finish, get to done on one thing, get it working, learn from it, and then improve it. And if improving it means that there’s a certain amount of acceptable refactoring or pulling in another tool—absolutely, right? That’s technology insertion, that’s a good, smart thing.

    But it does also mean that we don’t instantly glom onto everything that’s coming along. I have one organization in particular where every team is allowed to have the autonomy and latitude and I’m just there as an observer, and it’s a little bit of melee. There are lots of good pockets of interesting things, but because there’s such technical diversity even in a small space, they’re having a hard time, because they’re not able to get crisp and good and deliberate with the first set of tools. To your point earlier, Pawel, they’re not getting good enough with what they’re doing before they’re switching on to something else.

    So, cloud native mindset is pretty important, but helping to folks understand cloud native from a, what is it from a patterns perspective, what are the architectural tradeoffs for it, and then helping them to make selections and stick with it long enough to get a success, I think, are really keys to helping organizations.

    O’Hanlon: So, do you guys think that cloud-native is kind of an all-or-nothing proposition? Are organizations—have you seen organizations kind of going all-in on cloud-native and then maybe pull back?

    Murillo: I’ve seen them going all in and I’ve seen them crash and burn. [Laughter]

    Bannon: Yes! [Laughter] Alright, then!

    Murillo: Yeah, I think—I was talking the other day as to, everybody knows juggling is really good for the brain, but if you try to learn to juggle with your most precious items, you’ll never learn because you’re gonna be very afraid.

    I think it’s the same about cloud and DevOps, right? Everybody knows it’s great, everybody knows there’s gonna be a lot of value out of it, but if you try to learn it with your most precious things—for instance, your entire organization—you’re gonna have a lot of resistance to getting it right.

    So, I think the same applies for DevOps and cloud-native. I think you need to iterate. You need to start small with projects that you’re capable of experimenting with, right? Kinda like the whole concept of a culture of experimentation and iteration is important, right? But there’s gotta be awareness to the fact that you cannot just experiment with everything, right, or with everything at the same time.

    So, what I mentioned, right, bite small pieces at a time, iterate, do concepts, and use those concepts to build kinda your operating model, right? What does a cloud mean to you for your organization, right? And then expand up until you have a very solid framework that is well establish, well understood, and then you can kinda start juggling with fire, but not until then.

    Bannon: That also helps us think through greenfield versus brownfield. I deal a lot with governments and a lot with federal governments and different agencies in defense. And there’s a tremendous amount of brownfield. It doesn’t mean that there’s old brownfield, but it means that there’s something pre-existing, so there have to be decisions made about where do I add on the cloud-native? Do I do it around the edges, is it incremental, am I doing strangler fig tree patterns, et cetera and so on? That’s one piece of it. Net new sometimes is a good place to try cloud-native, right, because you do have perhaps less confines around it, so take something smaller that’s greenfield and make your first foray that way.

    I think it’s an interesting conversation about the starting and stopping points for cloud-native? I noticed—and I’d like to hear, Pawel, if you’ve seen the same thing—I saw everybody lift and shift as quickly as they could. “I wanna get rid of my data center, so I’m just gonna move my workloads, right? IAS, I’m gonna move my workloads.”

    So, they moved their workloads, and I naturally thought the progression would be to pass or would be to cloud-native and to the refactoring. What I actually observed was a pendulum swing to the analytics side. And so, there was a tremendous, I have all of this compute available to me, I have less expensive storage, I’ll move over to the analytics side, and we’re just starting to see, a real increase in the cloud-native application space. Unless you’re truly talking about upstarts and greenfielding, there has been much less of it with the brownfield and the incremental improvements.

    Piwosz: Yeah, I agree with you. So, first of all, if you just do lift and shift to cloud, whatever we call the cloud, you will cry very soon. So, this is the first thing.

    The second—yes, we have a lot of possibilities regarding analytics, we have beautiful words right now, buzzwords like observability, telemetry, et cetera, et cetera. So, we’re just expanding our monitoring, let’s say old-fashioned monitoring to the new areas and collect more and more and more, and more structured things.

    So, this is something what is very, very easily achievable, but also—and this is in relation to the previous topic here, if you start with cloud, well, you are already in the cloud. There should be still a logic behind everything. Because, today is so tempting, because you do not have to do the initial investment, right? You just click a button and start using serverless or just create a big, big cluster of something, right?

    And then, in my work, I observe this multiple times, then you create a crazy, really crazy solution for a very simple thing. Well, what can go wrong in this, right? So you are using like 10 or more technologies which are completely different, you are trying to wire them together and then you are saying—okay, I know 20 technologies, it looks perfectly well in my CV. But when you talk with people, you just realize that it doesn’t work as it should work, really. That’s why, very often, organizations which are going to cloud and do not take logic in this, how it is organized, how it is architected, how this even developed, they are paying much, much more, not just because they did lift and shift, but they started to create very, very crazy solutions, right? And this is the kind of waste that you mentioned as well.

    Bannon: I’m gonna throw out just a couple quick words that’ll make people cringe, but when I think about—so, agility 20 years ago, right, the agile manifesto, there’s a woman named Linda Northrop from the Software Engineering Institute at Carnegie Mellon who said it was one of the worst things that ever happened to software architecture, because unintentionally, there was this emergent architecture, my architectures will just emerge, I don’t have to worry about them in advance. I want to push forward that enterprise architecture needs to still exist, but in a different form, in a different format. There still needs to be, it’s okay for there to be somebody more senior, somebody who is helping to drive the architecture and helping to pick which cloud technologies and where cloud native is the most appropriate.

    Because there’s different trade space, right? Even if I talk containers, there’s different trade spaces between how I’m using the containers and how I’m moving forward with that. Does that resonate with you, Pawel and Leonardo?

    Piwosz: Yes, yes. I would even add here that if you want to be cloud-native, your developers need to be cloud-native. So, there is no more, “It works on my machine”—this is obvious, right? But also, I will be bold here, so even development should go into cloud. And this is another layer here, which we didn’t touch, but it is very important, I believe.

    O’Hanlon: Well, I feel like we could have this conversation for at least another hour, but unfortunately, we gotta wrap things up, guys. But I do appreciate Tracy and Pawel and Leonardo for your insights. You guys are great. I’m gonna have all three of you back on and we’ll talk about other things in the future. We have lots of topics to get through this year.

    The level of intelligence and insight you guys bring to these conversations is just so, so value added, so I do appreciate your time in joining me today for another one of our DevOps Institute Ambassadors Panel Discussions. So, thank you, guys, again. We really do appreciate it, and please do stay in touch with me. I’d really absolutely love to get your expertise back on the show, so.

    Bannon: Alright, fantastic. Be well. Stay safe, everybody.

    Murillo: Thank you very much.

    Piwosz: Thanks, everybody. Thank you.

  • Ambassador Insights: Enterprise Digital Transformation

    Ambassador Insights: Enterprise Digital Transformation

    Digital transformation has been on the minds of many organizations for a few years now, but since the onset of the COVID-19 pandemic last year the need to transform IT infrastructures has taken on a sense of urgency. The rush to work from home coupled with the shift to online everything has pushed organizations to adopt the tools and technologies necessary to enable IT agility for all users.

    In this inaugural episode of Ambassador Insights, featuring DevOps Institute ambassadors Sean Davis, information security advisor, DevSecOps, at TransUnion; Jennifer Fischer, executive director of the Center of Innovation and Professional Studies at Felician University; and Pankaj Gupta, senior director of Product Marketing, Cloud ADC, and SD-WAN at Citrix, we take a look at some of of the factors driving digital transformation, the need for security in digital transformation initiatives and how organizations can get started on their transformation journeys now, if they haven’t already.

    The video is below, followed by a transcript of our conversation. Enjoy!

    Transcript

    Charlene O’Hanlon:  Hey, everybody, this is Charlene O’Hanlon, Chief Content Officer at MediaOps, and I am just thrilled to pieces to be introducing a brand new segment that we have on TechStrong TV which we’ll also be running on the devopsy.kinsta.cloud website. It is a panel discussion that I’ll be having monthly with DevOps Institute ambassadors—you see three of them right here on the screen with me. As I said, it’s the first in what I hope will be a series of monthly panel discussions with these ambassadors and other ambassadors on the future topics that we have on devopsy.kinsta.cloud.

    The first inaugural discussion will be on Enterprise Digital Transformation, and the featured topic will be changing every single month, so this week it’s Enterprise Digital Transformation, next month it will be on Cloud Native.

    So, I’m looking forward to all these discussions, but I wanna go ahead and kick off this first one with our speakers today. First up, we have Sean Davis, who is Information Security Advisor, DevSecOps, at TransUnion. Hi, Sean, thanks so much for joining me today.

    Sean Davis: Thanks for having me, Charlene.

    O’Hanlon: Next up, we have Jennifer Fischer, who is Executive Director of the Center of Innovation and Professional Studies at Felician University. Jennifer, thank you so much for joining me today. Good to see you.

    Jennifer Fischer: Thank you, Charlene. Pleasure to be here.

    O’Hanlon: Alright, and last but certainly not least, we have Pankaj Gupta, who is the Senior Director of Product Marketing, Cloud ADC, and SD-WAN at Citrix. Pankaj, thank you so much—as always, great to see you.

    Pankaj Gupta: Thank you, Charlene. Glad to be here.

    O’Hanlon: Okay, great. Well, as I said before, the topic of this panel discussion is on Enterprise Digital transformation, which I know is a huge topic to swallow. There are so many things that we can say about Enterprise Digital Transformation, but it’s certainly a topic that has been on a number of organizations’ minds, especially since the onset of the pandemic and the rush to basically align their business practices with digital transformation efforts to be more productive and to stay relevant in today’s fast-paced business environment.

    But as I said before, a lot of things have changed since the onset of COVID, and I want to kinda maybe set the stage a little bit by asking you guys—where do you think digital transformation and these initiatives have kinda progressed since the onset of COVID-19 and that rush to remote work that so many organizations have had to kinda go through? Whoever wants to start?

    Gupta: I can take the first crack, Charlene. This is an excellent question. The impact of COVID is twofold. First of all, it’s realization by IT and business for the need of the digital transformation. So, that’s first, is the faster realization of the need for digital transformation.

     And the second thing is about execution speed of digital transformation has increased tremendously due to COVID in the last one year or so. IT and business are more in lockstep than ever before. IT is more aligned now with the business outcomes. In the last 12 to 18 months, we have seen four phases of it. The first was, it started just with business continuity. How do I get my business moving in this new COVID environment? Then focused more into employee productivity, because as they started working more from remote.

    And then, more people started working remote, workers started working from remote, then security became very paramount, that, “How do I secure all of them?” And I think the next phase which is coming is that digital transformation will be more about hybrid workforce; some of the employees coming back to the office. So, that’s the fourth phase which I see for that.

    And in this environment, talking to customers, I have seen CIOs, the number one priority is to keep employees engaged, remain productive from anywhere, from any device they are working. They want reliable connectivity for every employee whether they are working from home. They also want us to ensure that same application experience, whether they are there in the office or now working from home.

    But what is also keeping them awake is that now these workforces working from home and home networks are not as secure as the corporate infrastructure. So, when employees access these applications or direct Internet access, their endpoints or home network doesn’t become an entry point for vulnerabilities into the infrastructure.

    O’Hanlon: Right, right, right.

    Fischer: Yeah, I fully agree, and I echo the need for a focus on security and a remote workforce. I think that really will become the foundation for digital transformation going forward. And I think it’s really interesting to look at the longer term impacts, transformational impacts on some key industries. So, when we think about things like telehealth and online learning and consumer facing applications like in retail and grocery and food delivery and those types of things, you know, you really have to plan for this hybrid environment as we’ve discussed going on for an extended time.

    And, you know, whether some of it will ever truly sort of come back, right? I think, to some degree, you know, some of the convenience and the productivity and the benefits that have been realized through this will be here to stay for the longer term.

    Davis: Absolutely. I’m thinking about—the pandemic has been a really great pressure test of a lot of these concepts that we’ve heard for years across the industry, remote work being one of them. You know, everyone says, “Oh, we get better productivity because there’s remote work.” But what this seems to have done is, it’s really allowed the business to pressure test how well they can pivot. What does that mean for their customers? Because now customer needs are different, what they’re looking for that’s a priority to them is a little bit different. Internal needs of the organization are different. Now, you know, you’re shifting focus from just delivering those products to ensuring they’re highly secure, right?

    So, a lot of these things we’ve been preaching in the industry for a very long time, especially around DevOps and DevSecOps, are really starting to take a front seat in organizations. One of the brilliant things that I’ve seen because of the pandemic over the last year is, even organizations who don’t have formal transformation initiatives and efforts in place are forced to still go through some type of transformation with their organization to maintain competitiveness or even survive. Because now it’s not just about thriving in the environment, it’s about understanding how to pivot to even survive. We’ve seen a lot of retail industries go bankrupt, we’ve seen a huge shift in real estate, right—so, how businesses decide, even with their hybrid strategies, how they’re gonna renegotiate contracts with all of this office space that’s sitting idle right now, and does it make more sense for them to shift there?

    So, there’s a lot of operational considerations that are being made by organizations as well as some unique opportunities and unique challenges are starting to be presented. I think HR is starting to take a front seat a lot more in initiatives. You look at employee wellness—it’s more important than it’s ever been, and it’s giving the opportunity for these guys to stand at the front lines and finally be cheerleaders or their organizations in a way maybe they haven’t had an opportunity to have a spotlight shined on.

    Because a lot of us think HR sits in the background, and now, a lot of their programs are really pivotal and the cornerstone of how businesses are going to move forward and look at employee care, satisfaction. You know, onboarding is a lot different. You know, it’s pretty reveletional to see just a lot of these things we’ve been talking about in the industry, even before DevOps, that people have played around with and said, “These are better concepts or better ways of business,” but now we’re actually pressure testing them through a real world tragedy and pandemic and seeing how that plays out and what that looks like for each and every organization.

    O’Hanlon: Yeah. You know, it’s interesting, because we’ve been talking about digital transformation for years now, and there was a lot of talk, but not a lot of action. And I think it was because a lot of organizations really just couldn’t wrap their brains around it. You know, they didn’t have, like, a reason to do it beyond, you know, providing customer satisfaction or keeping up with their competitors.

    But, you know, having this pandemic occur kinda gave them a reason to really go and say, “Alright, this is what we need to do to (a) keep our employees productive, (b) provide that top quality customer experience, and just kinda keep the wheels on the bus.” And, you know, before, it was more like—okay, well, we’ll see these, we’ll measure by certain metrics and maybe we’ll see an increase, maybe we won’t. Is that enough for us to do digital transformation?

    But I also think that it’s important for—and Sean, you alluded to this—digital transformation impacts so many different areas of the business, it’s not just about improving customer experience. It’s not just about making employees more productive. It’s about keeping them same, you know, [Laughter] with the HR apps and things like that and employee wellness. It’s amazing how, by having that laser focus on digital transformation, once there was a reason to do it, a real, legitimate reason to do it, companies that have undergone the digital transformation and are still undergoing them have really started to thrive and they’ve been able to pivot their business successfully. And that, to me, I think is—you know, it’s a success story. If you really take a seat at, you know, take a look at what’s been done so far and just the fact that so many organizations have been successful so far in their efforts.

    And I didn’t want to take that off the rails, but I wonder how much of that is, when we’re talking about DevOps, where does that fit into a lot of these kinda success stories, if you will, with the organizations? I mean, is it a central core of digital transformation efforts, or is it more of a tool, if you will, within a larger process? Whoever wants to answer that one.

    Davis: I’ll hop in first this time, if you like.

    O’Hanlon: Yeah, sure.

    Davis: So, with DevOps, I think there’s a unique opportunity that a lot of organizations are taking. At the core of most digital transformations, at least I’ve been part of and been privy to from peers in the industry, they’re very centered around technology. You’ll hear the term “every business is a software company” being thrown around. Now, while that may not always ring true for everyone, I believe the spirit of what they’re trying to say is, there’s a better way for us to use technology to enable a better customer experience, a more valuable outcome or our customers, and through leveraging that technology, we’re able to see better returns and give back to the community in a lot of different ways beyond just our products.

    DevOps, I think where the real value comes is, there’s been this evolution over the last year or two where people are starting to realize that a value chain, or the supply chain of an organization and the value that’s being delivered doesn’t end when the product is in our customers’ hands, but it’s when value has been delivered to our customers’ customers, right? So, we go to that Nth degree to make sure that not only are we just selling something and saying, “Hey, have a great day” because we got it in your hands as fast as possible, but we’re able to use feedback loops and telemetry to actually say, “How successful is this for your customers? You know, what type of experience are your customers having? How can we work with you and partner to have a deeper relationship than just a buyer and seller?” Right? So, we’re starting to see a lot of that proliferate the industry.

    The pandemic’s also provided us a really great opportunity to take a step back, because everyone is slowing down, everyone’s having to adjust and pivot and say, “How do we overhaul all the systems?” Right? Instead of looking at this, you know, where, “Let’s improve this silo” or, “Let’s improve this area of the business,” we’re able to start bridging a lot of those areas instead of just saying, “Well, you know, let’s throw the hammer down and start busting these silos”—

    O’Hanlon: Right.

    Davis: – “let’s start bridging a lot of these areas and understanding where the challenges are.” It allows us as leaders of our organizations to dig much deeper to understand broader problems with the organization, and we can see that, once again, going back to how that’s being pressure tested, right.

    We all know, as building continuity plans, that looks really great on paper, but if it’s not put into practice every year, and what better way, unfortunately, to practice that than actually experiencing a real outage, a real security breach, a real pandemic do we put those things through the paces to say, “Is the theory and the practice that we put on paper actually practical and applicable to what we’ll do in real life?” and then suss out where those problems or challenges are with the execution of that plan to be able to reinforce that plan and strengthen it so we can deliver better value, both internally to our organization and externally to our customer and market.

    Gupta: I think before the pandemic, for many of the organizations, digital transformation was an initiative. It was a goal, it was a project.

    O’Hanlon: Mm-hmm.

    Gupta: But during the pandemic, digital transformation has become a necessity.

    O’Hanlon: Yes.

    Gupta:  And when a project becomes a necessity, that means that what you’re really looking for is the agility and speed and ability to respond faster, almost in real time. And this is not just about IT, this is about wall to wall, end to end processes. And IT is that connecting tissue of the overall digital transformation, and the foundation of that is the DevOps. Because DevOps brings automation, brings ability to respond faster. And the technology trends which have happened in the last five years, like the emergence of the cloud, ability to auto scale in cloud, ability to automate things from the cloud, more and more people are working remote. Ability to deploy automation tools which are delivered from cloud, because IT is not going back to the office.

    So, DevOps has become a very critical component to achieve that speed. Every company’s starting point is different. For cloud native companies, they already have a lot of implementation of their IT into the cloud already—if not, more and more companies have started moving. And that is actually creating new opportunities for the DevOps engineers overall. It is their skill set which is tremendously needed in this marketplace, and it will continue to grow. And that’s where the places like DevOps Institute help to build that skill set for IT teams across the world.

    Fischer: Yeah, absolutely. And I would add that, from the point of view of transformational outcomes, you know, one of the key things there is making sure that cultural change has been institutionalized. And so, you know, from the standpoint of DevOps, and sort of coming back full circle to your question, Charlene, around, you know, is it a core or is it something broader—it’s both, right? Because, of course, it’s underlying the technology and the ability to achieve success is there, right, within the pipeline.

    But beyond that, you know, there’s relevance as well, even in business functions, if we’re talking about the opportunity to identify new revenue streams or looking at the overall impact of building a continuous learning culture and the ability to accelerate change—these are things that translate to every area of the business. So, from my perspective, you know, DevOps really has that overall end to end impact to be able to deliver against. And I totally agree with my co-panelists that the pandemic has been that driving force to be able to surface that and really, you know, sort of shine a light on the value that it can add in a time of crisis. But from a long-term perspective, the value certainly continues to be there.

    Innovation as well has a significant role to pay here, too, right? So, just in terms of being able to innovate faster, to be able to look at that pivot point as was described earlier that, you know, that’s a huge learning curve. I mean, there’s some pain that went along with that, you know, having to do it through the pandemic, but there’s also some long-term gains in being able to understand resiliency and responsiveness in that time of crisis.

    O’Hanlon: Yeah, it’s really, it’s been amazing for me to see how quickly organizations have been able to undergo these digital transformation efforts and really understand what their business needs. It’s almost like they—you know, they just kinda launched, if you will. It’s just like, from zero to 60 in, like, nothing.

    Fischer: Exactly.

    Gupta: Mm-hmm, yeah.

    O’Hanlon: But, that said, are we too late for organizations that haven’t started their digital transformation processes yet? I mean, those that may be a little slow to start, they recognize the value, they just haven’t been able to kinda get their stuff together yet to do it, but you know, is it too late for them? And if not—I hope not, I hope not—but if it’s not, what are some of the things that maybe they need to keep in mind as they start to think about undergoing a digital transformation process? You know, what are maybe some of the best practices that they need to consider?

    Jennifer, I’m gonna let you start with this one because, you know, this is your turn, so. [Laughter]

    Fischer: Sure, sure. And I think, you know, interestingly, I think the same principles hold true, right, in terms of best practices for digital transformation, whether we’re talking about, you know, in terms of the pandemic or not, right?

    O’Hanlon: Mm-hmm.

    Fischer: The key thing, the most important thing is that introspection and insights, right? So, really understanding and being honest about and knowing your business, right, understanding what those end to end processes are, knowing and understanding your marketplace, knowing and understanding your customers so that, to Sean’s point, when you do wanna deliver to that Nth degree, you’ve got the insights there as part of your end state, right, that you wanna achieve.

    So, I think all of those things hold true in either case, and then bringing them together into a well-defined strategy that reflects—honestly reflects, right, the strengths and weaknesses of your own organization. And then, last but not least, I think something that often gets not as much attention as it needs to, having metrics in place, right, so that you’ve got that continuous learning ability over time and being able to come back and not only say, you know, “Did we achieve what we set out to?” but on an ongoing basis, where do we need to continually pivot and shift our efforts to make sure that we stay.

    And, of course, as goals change—I mean, we talked a little bit before about what happens when this is done, right? So, be it a hybrid workforce or some of the other trends that we might expect to see in 2021 with DevOps and, more broadly in business and in the economy, how do we help ourselves and our business partners to be able to continually pivot in that very agile way? And, you know, so to me, it’s about those three things, right? Having the right insights, the right strategy and tactics to find, and then third, the right metrics in place to keep you on point.

    O’Hanlon: Alright. Sean or Pankaj, do you guys have any best practices you want to share?

    Davis: Sure. So, I want to answer your earlier question—no, it’s not too late.

    O’Hanlon: Okay. [Laughter]

    Davis: There is no such thing as too late. Please, if there’s any business out there, you have not gone through a digital transformation now, it is never too late.

    O’Hanlon: Good.

    Davis: Now, the second part of that I will caveat with, because I think it just needs to be said. A lot of the practitioners feel this way, but it’s not often announced, and I don’t believe it’s always heard enough—transformation is not about just carrying you from one state to the other. I really wish that the industry as a whole would start to adopt digital evolution. Because that’s really the truth of what we’re doing. We should be evolving every single day. We’re adapting to the pandemic, and then we will adapt to the next event that occurs within our industry—good or bad.

    We’re constantly adapting to the needs of our employees. We’re adapting to these new technologies and frameworks and ways of doing business every single day. That’s an evolutionary step that will never change. The transformation is just the spark, the catalyst, if you will, for that evolution to begin and to be recognized and, you know, as Jennifer had mentioned earlier, institutionalized in the organization, right? And that’s your culture, that’s your people, that’s your technology, whether it’s DevOps, whether it’s agile—whatever it is, right? There’s never, it’s never too late to start.

    From the perspective of best practices, I know I’m gonna sound like a broken record to all those that have probably seen millions of videos on the culture of transformation, but start with your culture. And I don’t just mean implementing programs that are making onboarding easier or customer satisfaction—employee satisfaction. But I mean, really start by taking stock of where your organization is right now. You don’t have to be light years ahead, you don’t have to be like Netflix, you don’t have to be like Amazon or Microsoft. You are your own unique entity. You will be the next whatever company, right, that somebody is going to want to model the great things that you do.

    I always think back to the TPS system, Toyota Production System, right? Toyota was massively successful in being one of the best manufacturers in the entire world despite giving the secret away to the rest of the world and all these other manufacturers adopted it, but they still were not able to achieve the same level of performance as Toyota, because it was built by Toyota, for Toyota. This was the way they did business, they felt this worked best for them.

    And I think that’s a sorely missed or overlooked area in a lot of transformations is—there’s so many frameworks, there’s so many ways of doing it, there’s so many quote-unquote best practices that are out there. Take a look at where your organization is. Take a look at where your people are and think about where you want to be. And then find things that align to that, that help you be successful, and eventually, you’ll start noticing you’re creating your own processes—you’re creating your own frameworks, you’re creating your own ways forward, and then share those with the world, right? Because it’s not just enough to consume something, see that it works, and move on, but take the lessons that you’ve learned and the things that you’re creating and share that out in the world. Maybe someone else is able to use that and perpetuate their business in a positive direction.

    O’Hanlon: Alright.

    Gupta: I think Sean and Jennifer covered many, many great points, and there are so many great practices. We are in 2020, so if you sum all the numericals in 2020, it comes to the fore, and I’m going to cover the 40 best practices.

    First, I think Sean and Jennifer did a wonderful job explaining that embrace the cultural shift. It is a new way of thinking, it’s a new way of doing. But to succeed in this cultural shift, IT skill set is the most important part. You must shift the culture, all ________ aligned, but if you don’t have a skill set inside that organization, you will not succeed. So, as you are embracing this cultural shift, invest in the IT skill set. That’s the first.

    The second one is design and build for speed. Because the automation and the speed to respond to the market differentiates the winners versus losers.

    So, the philosophy should be to automate everything you can, and that’s where the DevOps comes into the play. Look for every possibility which you can automate. And automation requires the DevOps skill set, but it also looks at your applications in a different way. What I can modernize so I can reuse those functions—that’s what the microservices kind of application brings into that.

    DevOps is also about modernization and connecting them together, so they work like a machine, one after another, one feeding another. So, that’s that whole part.

    Also, start thinking, as we move into 2020 or 2021—how do I build a self-correcting infrastructure? And cloud is already giving you auto scale, resiliency—all those pieces into that. We don’t have to go into detail, but when you’re building and designing for the speed, see what are things that can achieve that.

    Third thing, which is going to be more and more critical, is the security first, security first, security first.

    O’Hanlon: Yes.

    Gupta: The recent SolarWinds example taught us so much. A small component on a broader enterprise, a small crack or vulnerability can impact the whole ecosystem.

    And in this world of application and API, where API has become the lifeline of the businesses and more and more digital transformation related business, are you protected your applications in API? As we move into the world of the multi-cloud, do I have a consistent security posture across multi-cloud? So, those are some of the things, that security first rather than the bolt-on.

    O’Hanlon: Mm-hmm.

    Gupta: And the last is that build for visibility. What I mean by invest into your observability stack, build into tools and mechanisms to give you a visibility inside what is happening in your infrastructure, what is happening in your application. Because if you don’t see, you can’t fix it.

    To summarize—embrace the digital shift, embrace the cultural shift, but make sure you have the right skill set to do that, design and build for speed, security first (no more bolt-on security) and visibility, visibility, visibility. Because if you can’t see, you can’t fix it.

    O’Hanlon: Excellent. Excellent. Well, all are great points, all are great best practices, and I want to thank all of you, all three of you for your expertise today during our discussion. Great stuff.

    If organizations have not begun their digital transformation efforts, now is the time. I think every organization understands the importance of digital transformation now more than ever, and it’s great to hear that it’s not too late—thanks, Sean. And it’s security, as Pankaj and Jennifer both mentioned—super, super important, and it should be an integral part of digital transformation efforts.

    We have lots of information about digital transformation and what’s happening in the space in general and some—you know, again, some of the best practices on devopsy.kinsta.cloud. So, I do urge everybody to check out the website and read up what we’ve got on digital transformation.

    Guys, before we close things out, any parting words, any parting advice on digital transformation or DevOps in general?

    I guess not, alright. [Laughter]

    Gupta: This is the time—this is the time that will create the stories which you will tell to your grandkids.

    O’Hanlon: True. Absolutely.

    Davis: Yeah, I think focusing on doing what’s right for your organization and doing what’s right for your customers, take care of your people, take care of your customers, don’t just do what’s easy. Because there can be so much change that’s going on that it’s very easy to say, “Okay, well, we can revisit this,” right, and generate a lot of cultural debt that never gets paid back off.

    Fischer: Yeah, I was thinking similarly, you know, there’s—in some way, too, you know, the reality of the pandemic conditions has been a level of exhaustion, I think, as well. And even despite that, it’s important not to keep focusing ahead and making sure that things that might be beneficial, particularly, coming up on the radar, trends for ’21 that could be taken advantage of—you know, don’t lose the momentum. Even though it’s been an exhausting past number of months, keep the momentum going and take advantage of the exciting trends that are on the way for 2021.

    Davis: Absolutely.

    O’Hanlon: Excellent. Alright. Well, on that note, I do want to thank all three of you, Sean, Jennifer, and Pankaj. Thank you so much for your time today, thank you so much for your expertise, and love to have you guys back on a future panel discussion or even on TechStrong TV. So, thank you, again, I appreciate it, and thank you, all, for watching and we’ll see you next time.

    Gupta: Thank you.

    Davis: Thanks, Charlene.

    Fischer: Thank you.