devopsy.kinsta.cloud

Category: Enterprise DevOps

  • ADOC: Assessing DevOps Culture

    ADOC: Assessing DevOps Culture

    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, Alan Shimel talks with Garima Bajpai, Louise Cermak and Brendan O’Reilly about reshaping culture to get the most out of any DevOps journey. The video is below, followed by a complete transcript.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hi, everyone. Thanks for joining us on another segment here for TechStrong TV. This is a special segment panel for TechStrong that I’m gonna be conducting, here. I’m happy to have you join us. I’m also really happy to have three interesting people join us. Let me introduce you to them. And if I mispronounce people’s names, I apologize; we do the best we can here on TechStrong TV, right?

    But we’re gonna start with Garima, is it Bajpai? Fair? Good? Okay. Garima, why don’t you introduce yourself?

    Garima Bajpai: Thank you, Alan. I’m Garima Bajpai from Ottawa, Canada. I am the Founder for the DevOps Community of practice here in Canada, which has three chapters, Toronto, Edmonton, and Ottawa. I’m also the organizer for the DevOps Summit which happens in Canada November 8th and 9th, and I am Ambassador with DevOps Institute, as well as an Ambassador with the CD Foundation. So, today, we are going to have a very interesting dialogue on DevOps assessments. So, I can’t wait to get started, right?

    Shimel: Yeah, thank you, thank you. Thank you for all you’re doing for the DevOps community. Next up, let me introduce you to Brendan O’Reilly. Brendan, welcome—a little bit about yourself?

    Brendan O’Reilly: Sure. So, my company is called Daysha DevOps. We’ve been working with the DevOps Institute now for about five or six years, predominantly delivering their training. And I myself am a consultant, and like the other speakers here today, really looking forward and excited about what’s happening with ADOC, because I see a big opportunity for our customers to get deeper into their DevOps journeys, to progress those journeys.

    Shimel: Fantastic, and thank you. And then last, but certainly not least is, we have Louise Cermak—Louise, did I get that right?

    Louise Cermak: Almost, yeah.

    Shimel: Well, say it right, because you’re entitled to have your name said right, it’s my fault. So, please, how do we pronounce your name?

    Cermak: Thanks, Alan, it’s “Chermock.”

    Shimel: “Chermock,” okay.

    Cermak: Yeah, so, I’m Louise Cermak. I’m a Principal Consultant with Catapult CX. We build software ourselves, and we also consult in agile and DevOps and have been doing so for sort of 10, 15 years. And we’re excited for ADOC, because actually, having the combination of being engineers as well, we can really understand the capability and how to apply it.

    Shimel: Absolutely. Well, all three of you, thanks for joining us. So, a couple of you have mentioned ADOC, right, and this is something that our friends at the DevOps Institute announced, I guess it was last week or the week before now. And ADOC, for our audience who may not be familiar, stands for Assessment of DevOps Capabilities. And this is a new assessment model that the folks at DevOps Institute have been working on.

    Look, you know, I know they’ve been working on it for over a year already. It’s been primarily driven by Helen Beal, who is a—Helen is a very well-known DevOps person in the community, but she’s also the Founder of the DevOps Institute Ambassadors, and has been a DevOps consultant herself for many, many years, as long as I’m doing DevOps.com.

    And then Helen was really helped with this by Eveline Oehrlich, who’s a DevOps Research Director at DevOps Institute, a former Forrester VP. And then I also know that she’s been helped a lot with people like the three of you, who are real world DevOps consultants who are helping organizations every single day with their DevOps transformations and capabilities.

    So, before we jump into ADOC, though, let’s take it up a notch and talk about DevOps assessments in general, right? Are they—why are they important? Why are they important, and if anyone wants to give us sort of a brief history of evolution or time around these assessments and how they’re used, let’s say, by consultants and/or end user organizations.

    Garima, I know you have a lot of experience, so if you don’t mind, I’m gonna ask you to kick it off, and then have the rest of the panel chime in.

    Bajpai: Right, and I actually term DevOps transformations as a journey towards remaking culture. So, it has been largely a complex journey, because of two factors, actually. The first factor is that the complexity brings along with, you know, a lot of focus on how you can upskill people, how can you actually transform your knowledge based and skill set to a journey which is basically based on experimentation, on learning, and learning from failures, right?

    And the second aspect is that there is no such literature available. You know, there is a lot of talk about DevOps transformation, but the literature is in the making. So, there is limited academic support as well as support from a best practices perspective how to do this transformation, right? So, these assessments come very—it is very crucial, because it will help you assess where you are, and every organization will have unique challenges, right?

    So, it is important to assess where you are in your journey and what you can do. You know, it’s not like a traditional transformation journey of three to five years where you are relying on a lot of targets ________ models which were already defined. It’s continuously evolving, right? So, you will have to have a view on what you can do today and how you can incrementally, in short cycles, transform.

    So, what happens in this process is that, you know, assessment becomes more crucial and essential, because there are discrete efforts. There are efforts in short cycles, and this assessment and measurement will help you course correct, will help you understand where you are heading to in your journey and what is needed as next steps to ensure that you incrementally build value, right?

    So, that’s why, I think, these assessments are extremely important. We will talk along this conversation how ADOC can actually help you on this journey as well as what are the major impediments and challenges organizations have and what should they look out for.

    Shimel: Fair.

    Cermak: I think, over the last few years where we’ve been helping organizations, what we’ve noticed is that many of them are trying to do their own assessments, and I’ve been into so many organizations where people have got Excel spreadsheets and they’re trying to measure how they’re performing.

    Because, you know, Garima’s right—there’s a lot of learning and experimentation. A lot of it is self-learning, which is what we encourage, right, from a DevOps culture perspective. But people wanna know that they’re going in the right direction, so they start with their own spreadsheets, fill them in, try and measure their capabilities. And a tool like ADOC helps organizations have a much more structured way of doing that, and obviously, it’s more scalable than an Excel spreadsheet, but people wanna know that they’re doing the right things.

    Shimel: Agreed.

    O’Reilly: Just a little bit about the history, perhaps Alan—you know, ADOC is brand new, but there was a progenitor in the form of DORA, if you recall.

    Shimel: Sure, sure.

    O’Reilly: Yeah, so, that was with Jez Humble and Nicole Forsgren. So, when they produced their State of DevOps report, it was a means by which organizations could form views about what good looked like, so you have your release and then so on.

    And it definitely raised people’s curiosity about—can we do this, can we measure? And of course, one of the principles with any DevOps transformation is to be data-driven. And so, the 180-odd questions that are included in the enterprise edition are very much about trying to capture and turn subjective opinion into something quantitative, a good first guess. And I think DORA has been successful, it’s now part of the Google organization, I believe, but this is a nice independent offer from the DevOps Institute.

    We’re really looking forward, here at Daysha, to taking that to our clients. I see some really interesting use cases. Some of the people that I’m talking to right now are just starting in a CTO role, and they want to baseline what they’re doing.

    Shimel: Absolutely.

    O’Reilly: So, they can look—you know, six months from now, they can say, “How much have we done?” They wanna get an understanding of what have they got in-house right now and then look at it again to see if they’ve been effective in those changes that Garima was—really well-made point by Garima—nice, short, sharp, Plan Do Check Act type changes that are gonna take place over the next six months.

    Shimel: I mean, for me [Cross talk]—

    Bajpai: Right, I mean, I also want to focus on two specific aspects of ADOC, which stands out. So, a lot of people have actually understood that you cannot remake culture without people-centricity, right? So, that’s a given. And we also understand that emerging technology can be a tool in your toolbox when you’re trying to kind of transition from X state to Y state. And a lot of focus has been placed on processes and frameworks.

    What ADOC has been standing out for me is, they have actually reflected to other different things, which are equally essential. The first thing is functional silos. And if you look at large enterprises, what they struggle with, like, what has been in the past is that we have large, functional organizations and units with their own business goals and objectives. And when these people are trying to [Audio skips] towards ________-centricity, towards DevOps capabilities. That’s a large challenge, because you know, it’s not easy to actually break down the functional silos, burn all the ships so that there is no, you know, way back. It has to be carefully done so that we have a possibility of course correction. That’s the first important point.

    The second important point which stands out for me is automation. And when I look at automation, I see that data driven approach towards DevOps and how that will ensure that we automate good processes, we automate the capabilities which are creating value, not only end to end, but also within the practices, right? So, that’s—those two things, I think, put together with people, technology, and process would actually make a kind of, a full house for, you know, doing this assessment in one way rather than looking at it in pockets.

    Shimel: Agreed. In my mind, you know, Brendan, you mentioned the DORA folks, and of course, Nicole has moved on from Google, she’s over at GitHub, and I don’t know if Jez is even with Google anymore, frankly. But really, with DORA, it wasn’t necessarily a consultant’s tool, though consultants used it.

    I think one of the interesting things with ADOC and what I know about how it came about is, it really was designed for consultants to use as part of their consulting practice to help you collectively help your clients get a baseline, a roadmap to show where you’re strong, where you’re weak and going forward so that that consultant can be more helpful, more impactful and, frankly, more efficient, which translates to less dollars, right, that clients waste in kind of circling around to figure out where the ground zero is.

    So, I would just point out that, now, that’s one use of ADOC is as a consultant’s tool. There’s also the community version for individual organizations and large enterprises can do it on their own, they don’t necessarily need a consultant. But it really was designed with that in mind, and I think it’s gonna be interesting to see, you know, DevOps especially, it was one of the knocks on DevOps, right? And I’m DevOps.com, I’ve heard this from day one—it’s squishy, there’s no manifesto, like in agile. There’s no real definition. It’s, how do you put your finger on it? You know, it seems like a unicorn or a mythical beast or something.

    Well, with ADOC, a lesson I learned early in my career in technology was, everything can be measured, and we measure everything, right? And ADOC kinda gives us a little bit of that certainty, at least as opposed to where you are in DevOps. I’m wondering, have you guys actually had a chance yet to try ADOC out with real world clients and what some of the results or findings were?

    Cermak: Yeah, we’re doing that right now with a client and we found that it was much easier to prioritize the activities that they needed to do, so we could align the activities with their roadmap and make sur that they were incrementing in the right direction to address some of the challenges that they had with their own customers.

    So, we took a very customer-based approach to prioritization of the activities, and they could really see a difference in the way they were able to engage the customer, deliver the features much faster, get the features agreed properly and through improving their continuous delivery pipeline, for example, and their lead time to change would improve and stability and reliability. So, we were able to prioritize exactly the things that were important right then to them with their customer base.

    Shimel: That’s great. Anybody else?

    O’Reilly: Well, just to echo, I personally haven’t had experience with the product just yet, but I have had that experience of walking the corridors with a spreadsheet, meeting people, capturing data—yeah, and that’s a really slow, inefficient way to capture a picture that evolves very, very quickly. So, I’m excited to do it this way, which is just way more efficient and lower cost to the client.

    And I think in terms of the consulting add-on, it’s that experience of having been through several transformations that allows us to analyze the results once they’re produced. And then, exactly like Louis has pointed out—prioritize, right? So, what changes can we make that will fit in with the natural rhythm of this company if they’ve got, if they’re not yet delivering on a regular basis? So, that kinda stuff I think is where the consulting value add is.

    Shimel: Interesting.

    Cermak: And the other thing that’s quite nice is, you can get the marginal gains as well, because you don’t have to tackle everything at once. You can improve one metric and then go and do the next one and the next one and continually improve, which I think the teams that we’re working with have really appreciated that, because they can see an uptick quite quickly, they get motivated, they wanna change more, they want to get better, and they keep going and keep going and getting those marginal gains.

    Bajpai: Right, and this is actually an extremely good point, because it gives us a perspective and this is something which I actually have experienced myself. I went to experience ADOC myself and, you know, I wanted to bring my team in as well. But what has happened in this journey, I have realized that organizations have overestimated the potential of short-term gains. And when I say that, often, people do not realize that whatever transition or transformation from a DevOps perspective they are doing, they are looking at short-term gains and probably losing out on the long-term potential of, you know, larger, creating larger value, long-term value, right?

    So, this is also a reflection that when you take this kind of an assessment, you would potentially have two aspects—what you can do in short-term, and what you achieve through several initiatives put together incrementally and how that outcome would look like in long-term, right? So, that is where these assessments would become very crucial for organizations, at especially big organizations.

    Shimel: Agreed, agreed. With all three of you being involved in consulting, I’m gonna ask you to take off your consultant hats for a second and for end users, end user organizations out here watching this, is ADOC of use to them without a consultant?

    Cermak: Oh, definitely, yeah. You know, we do build software, and we use those metrics ourselves, and we’re constantly monitoring those dials and—okay, we do some consulting around this stuff as well, but actually, we’ve got customers that we need to deliver to, and for us, being on top of all of that all the time is really helpful.

    So, anyone taking the assessment would be able to identify changes that they could make in their own engineering. That’s straightforward. It’s really set out very easily to understand.

    Shimel: Very good.

    O’Reilly: Alan—

    Shimel: Go ahead, Brendan.

    O’Reilly: Yeah, so, there’s a friend of mine who’s a lawyer, and pretty much any time I ask him a question, the answer is, “It depends.” [Laughter] So, in answer to your question about whether end using organizations can benefit from this or that consultant, I would say it depends. It depends on the mindset in the organization, the appetite for learning, the appetite for change, and so forth.

    But for sure, even just to kind of get started and to understand where they’re at, there’s huge value here without a consultant just to get a picture of where you’re at.

    Shimel: Agreed. And I think that’s part of this, too, and I think that’s also where there’s the—I forget if they call it the enterprise edition, which is the full, I forget how many questions there are already, hundreds of questions, versus the community edition, which I think is just, like, 30 questions or something like that. But even the community edition, you know, I think brings value to an end user organization who may just want to—you know, let me stick a flag in the ground as a marker and then see where we go from there.

    Guys, we’re about out of time, but I want to thank you, all three of you, for joining us. I should mention that if you’re interested in ADOC, right, Assessment of DevOps Capabilities, you can find out a lot more about it at the DevOps Institute site, which is DevOpsInstitute.com, and I know that there’s licenses for consultants, end user organizations. We’ve also launched the membership association, so as a member of the association, I think you get some use of it as well.

    But for now—Louis, Brendan, Garima—thank you so much for joining us on TechStrong TV. Good luck, and keep us posted with ADOC.

    Cermak: Thanks, Alan—pleasure.

    Bajpai: Thank you.

    O’Reilly: Thanks, Alan.

    Shimel: Thank you. Alright, we’re gonna take a break and we’ll be right back with our next guest.

    [End of Audio]

  • Languages and DevOps: Mainframe

    Languages and DevOps: Mainframe

    In true DevOps fashion, I nearly forgot to cover the mainframe after saying it warranted its own blog!

    There is a lot going on right now in the mainframe space, so the question of mainframe language choices has several different answers. We’ve got Linux running on the mainframe, we’ve got cross-compiled open source capable of running on the mainframe natively, we’ve got mainframe-based containers and we even have traditional mainframe tools being ported to other platforms (hello, COBOL on Linux!) so that development can happen on smaller platforms but target the mainframe.

    Taken in the order they came available, we have traditional mainframe development, in languages like COBOL and RPG, right on the mainframe in standard LPARs. This has gotten easier over the years, but is still basically the same development environment that was used in the 1980s, with prettier UIs.

    Then we have Linux LPARs available that allow for development right on the mainframe. There are issues and differences from other Linux development environments, but not as many as you’d think. This approach gives a broad selection of development tools on a Linux platform, making it an appealing choice.

    Next came containers, which can then run Linux in a container with the container offering the interfaces that Linux expects to find. This approach has the benefit of being more like development on other Linux platforms, but interaction with core services can still be platform-specific at times. This approach offers the breadth of open-source languages that came naturally with containers plus the few that have been ported over to z/OS.

    Then came speed porting. The biggest weakness of the above options was that it took too long for vulnerabilities to be addressed and new functionality to be moved over to the mainframe. The fact is that porting a language took time, and wasn’t as rapid as the response for the core Linux kernel. There has been a movement to improve the dev tools that create the ports, and now response time to CVEs or improvements in the kernel is much better. A side effect of this movement has been increased availability of languages and tools that are used by DevOps to get things done.

    Finally, we have recently received support for traditional languages on other Linux platforms. Most notably, given the number of lines of code out there, COBOL is now officially supported on Linux, meaning you can develop on the desktop without a ton of overhead, and then deploy to the mainframe. This has the effect of enabling DevOps processes and mentality for more traditional languages. This is still new, and the differences between developing on one platform and deploying on another will have to be worked out, but it is a step in the right direction.

    So what should you use?

    Mainframes are generally a more controlled environment than most DevOps teams are used to. The work required to support and update a given language, keeping it and its libraries up-to-date is more complex than just a generic Linux system, and that gives rise to very focused shops in the mainframe space. Generally speaking, you will be told what to use, or more to the point, which languages are supported. If you get input into the process, recommend Python, as it has the biggest pool of developers and libraries out there at the moment. But chances are, the mainframe team already has a language in place that they want DevOps teams to focus on, and in that case, use what’s available.

    No matter which language you end up using, API-wrapping mainframe functionality is a time honored tradition at this point, make the mainframe do the heavy lifting and return just what your application needs. Think of it as a big, smart database that can pre-process results for you at high speed, in high volumes.

    And keep rolling.

    Mainframes have been around forever. They’ve been pronounced dead dozens of times, and yet the security, stability and locality of a mainframe keeps them in the mix. Data gravity helps too – the data is there, the routines to do processing on the data are there, handing that data off to another platform for presentation isn’t that big a deal, and the mainframe just keeps ticking along. Because (at this point) generations of developers have made it tick. Keep that tradition alive if you’re in a mainframe shop; they are literally the core of systems in the places they are in heavy use.

  • DevSecOps Practices Gap Assessment

    DevSecOps Practices Gap Assessment

    DevSecOps practices are essential to deliver software safely and securely withinDevOps value streams.

    To get the maximum security protection from DevSecOps, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevSecOps and determine a strategy for improvement. Gap analysis provides valuable inputs for formulating a strategy and roadmap to improve a topic including DevSecOps.

    My SlideShare Gap Survey, Assessment and Analysis For DevSecOps explains how my 9 Pillars Gap Assessment Tool greatly speeds up the gap survey, gap assessment and gap analysis process for DevSecOps.

    It is important to clarify a few definitions for these purposes, because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions:

    • Gap survey is discovery tool used to collect information about the current state of practices for a topic.
    • Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
    • Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
    • Gap analysis is the process of determining priorities for reducing the gaps found during a gap assessment.
    • Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

    For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

    I define a seven step process for gap assessments. The steps are as follows:

    1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic.
    2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as DevSecOps, will normally be fairly complex with tens, if not hundreds, of practices. Categorize the practices into groupings (I call the groups “pillars”) to make the list of practices more understandable and meaningful. Doing this will require some research and work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE and some other topics such as containers.
    3. Enter the chosen practices into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
    4. Determine who needs to be included in the gap survey.
    5. Collect data using the gap survey.
    6. Perform a gap assessment.
    7. Perform a gap analysis.

    Let’s take a look at the above seven steps for DevSecOps.

    Step 1: Pick a Topic to Analyze

    For our purposes here, the topic is DevSecOps.

    Step 2: Determine Recommended Practices for DevSecOps

    For an example DevSecOps assessment, I used the practices under nine practices categories described in a blog that I co-authored called 9 Pillars of Continuous Security Best Practices. The nine practice category pillars are:

    • Leadership
    • Collaborative culture
    • Design for DevOps
    • Continuous integration
    • Continuous testing
    • Continuous monitoring
    • Elastic infrastructure
    • Continuous delivery
    • Continuous security

    Step 3: Enter the Selected Practices into a Gap Assessment Tool

    You can find and download a free gap assessment tool, pre-loaded with a sample of DevSecOps practices in a file called DevSecOps Assessment, from one of the resource pages found on my website, EngineeringDevOps. You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

    Step 4: Determine Who to Include in the Gap Survey

    For the gap analysis to be comprehensive, people in roles that are affected by container practices need to be surveyed, or at least represented, to ensure their perspectives are included. Some example roles that are typically included:

    • Business leaders – because leaders influence culture and budgets for DevSecOps.
    • Developers – because developers need to design in accordance with DevSecOps practices.
    • Project owners – because they influence product work priorities.
    • QA testers – because they need to test in accordance with DevSecOps practices.
    • Ops – because DevSecOps practices affect operations.
    • Security – because DevSecOps practices affect security practices.

    The survey can be conducted for an individual application, a group of applications or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organizational segment that is being targeted for improvement.

    Step 5: Collect Data Using the Gap Survey

    A gap survey should allow each surveyed person to enter an “Importance Level” score, a “Practice Level” score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included in in my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=not relevant, 1=not important, 2=nice to have, 3=important, 4=very important or 5=critical. Practice-level choices are 0=not sure, 1=rarely, if ever, 2= sometimes, 3=most of the time, 4=always or 5=we are good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

    Step 6: Perform a Gap Assessment

    The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

    No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

    Step 7: Perform a Gap Analysis

    The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories that are determined by a consultant or topic expert.

    The result of the gap analysis indicates where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

    What This Means

    While is it clear that DevOps offers immense value for software deployment, the adherence to best practices for DevSecOps is essential to reduce risk and assure security. Each organization is different, and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization. This blog explained a gap assessment approach, which uses my nine pillars of best practices for DevSecOps. My free DevSecOps assessment tool facilitates a gap analysis for DevSecOps and priorities to improve DevSecOps practices for an organization.

  • 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]

  • How to Use the Assessment of DevOps Capabilities (ADOC)

    How to Use 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, Accelerated Strategies Group CEO Mitch Ashley talks with Ulises Gonzalez and Leonardo Murillo, two DevOps Institute Ambassadors, about how to apply the ADOC to get the most out of any DevOps journey. The video is below, followed by a complete transcript.

    Announcer: This is Digital Anarchist.

    Mitch Ashley: Well, I have the pleasure today of being joined by two very interesting gentlemen, we have a great topic to talk about. The first gentleman is Ulises Gonzalez, and also Leonardo Murillo. Very nice to meet you both. Congrats—good to be getting together with you. Congratulations on getting together, [Laughter] to have a TechStrong TV talk.

    Leonardo Murillo: [Laughter] Thank you. Thank you, Mitch.

    Ashley: Ulises, would you introduce yourself? Tell us a little about you and who you represent.

    Ulises Gonzalez: Oh, absolutely. I’m Ulises Gonzalez, I’m a DevOps Ambassador for Panama. I’m a Product Owner on Agile611. We are a company of way of working located in Spain and Panama. I’m glad to be here.

    Ashley: Great to have you. And Leonardo?

    Murillo: Alright, thanks for having us here, Mitch. So, my name is Leonardo Murillo, and I’m CTO at Qwinix, we’re a product engineering company in Denver, Colorado, and I’m also Founder of Cloud Native Architects, which is a consulting firm specialized in continuous delivery, security, and reliability, doing consulting for enterprises, and I’m based out of Costa Rica.

    Ashley: Excellent, excellent. Well, good to be with you both, we have a fun topic. I know you both are DevOps Institute Ambassadors. For people that don’t know what DevOps Institute is or maybe what the Ambassador program is—does one of you wanna take a shot at kinda giving a quick overview?

    Murillo: Absolutely, I can give it a shot. So, there’s a huge component to DevOps that is human centered, right? It’s about culture, it’s about practices and kinda mindset. So, the DevOps Institute is an organization that looks to provide a means for DevOps practitioners to skill up, to gain knowledge, to network. It’s at DevOpsInstitute.com, so I really encourage everybody to go and find out some more. It’s a great, great organization.

    Ashley: A lot of sharing, a lot of collaboration. A lot of folks who are going through the same journey, maybe at different speeds or different places with their career or with their organizations, so what better place to work with each other, learn from each other, and help each other? So, that’s a great thing. Very cool organization, the DevOps Institute.

    Well, we’re here to talk about this new assessment program, the short name of it is ADOC, but it’s the DevOps Institute Assessment of DevOps Capabilities—thus, ADOC.

    So, does one of you wanna tell us a little bit about what the assessment is for? Why would someone want to use this as an assessment tool?

    Murillo: Why don’t you go first, Ulises? [Cross talk]

    Gonzalez: We need to remember that adopting DevOps is not a one-day process. Adopting DevOps requires a lot of effort, a lot of co-working, a lot of understanding on where we are. So, understanding your DevOps capabilities is vital to assess your current practices. And then, it helps to know how to devise or develop an improvement plan, it’s very important.

    In my experience, when we don’t know how to do DevOps implementation in a proper way, we can do more damage, do more harm that receive the benefits. That’s why DevOps capability assessment is a very wise decision to make to start or to understand where we are. Where we are to make good decisions, to get that deep understanding about our practices, and of course, to make a plan, to make a—how to define the next steps to be close to our goal or our vision to accomplish. That’s why DevOps Capability Assessment is a more than a tool, it’s a very wise way of starting of gaining understanding on what we are doing in our company.

    Ashley: Mm-hmm. Good overview. I know you both are with partner organizations that would actually help people go through this assessment, correct?

    Murillo: Correct.

    Gonzalez: Yeah.

    Ashley: Great. Leonardo, why don’t you say a little bit about what you think that process would look like? And by the way, it’s not an unusual thing to hire someone to come in and do an assessment and get an external perspective, and then you kind of evaluate where you are and decide where you wanna go or what things would help you get to the next place.

    This really gives you a standardized way, something that you’re at least kind of—not quite a benchmark, but something kinda like that so that you have a consistent assessment of how you’re looking at organizations so you can benefit from what others have learned about going from where you are to whatever the next step is. Does that make sense?

    Murillo: That makes sense, and I think you basically are talking about some really relevant points in terms of kinda like the standardization of the tool to assess, right? Because as Ulises pointed out, it is a long time effort. It doesn’t happen overnight. And it requires the involvement and ownership of many people across the organization. It’s not just technology alone, right, that will enable this transformation. And I think the assessment is a tool that needs to be leveraged and revisited often, right?

    Because, as you perform initiatives or as you deliver initiatives towards elevating a certain capability, the target is gonna continuously move, right? And you wanna make sure that, as you progress, you have a common framework that allows you to really gauge progress, right? Because you wanna be able to compare your previous state to your current state as you work towards that desired state, right? And in the context of capabilities, for instance, there is something relevant as to thinking of capabilities in terms of dimensions as kinda like the DevOps capability assessment approaches it, and not as maturity.

    Because capabilities are subject to continuous improvement. There is a certain sense of kinda like a ceiling to maturity, right? You’re mature now, there’s nothing else to do. But there is an ongoing process of continuous improvement which, I think—well, I think we’re all into DevOps, right? We know continuous improvement is one of the core fundamentals, right, of DevOps adoption. And that’s a little bit—and also talking about how, I think, this should be approached and how, at least my organization, approaches it. It’s not a one-time assessment, and a one-time picture that tells you how to get to the end, it’s an ongoing process, and this is just a way for you to quantify the current state. And you will need to continue doing that as you progress, and deliver initiatives in the dimensions where more value can be extracted. Does that make sense?

    Ashley: Yeah, very much so, and I’m glad you brought up the maturity. I mean, there are methodologies, methods of using, a maturity matrix. Those tend to be, you know, do you have a process, do you follow it, do you improve it, or whatever that might look like as your adoption. DevOps is so customized to organizations, where they are, how they create software, their own sort of life cycle of how they work, which is one of the great things about it, but there’s no one way to do it to assess that, “Are you mature?”

    But I think that point in time look at it makes a lot more sense of how to think about where we are now on our journey. You may want to course correct, right? You may wanna say, “We’ve learned a lot, and we’ve actually just learned that this actually is really something that’s even a more beneficial part of DevOps, let’s focus on there, next.”

    Am I on the right path, here, Ulises?

    Gonzalez: Oh, absolutely. To me, the process of continuous improvement is literally endless. Organizations and companies are immersed right now in a competitive environment that is constant and required a lot of frequent changes—in every sector, in every area, in every country. That’s why quality process improvement becomes literally an imperative. For that reason, the purpose of offering products demands and services demands us low cost and meet customer expectation.

    To me, as I said, I’m very aligned with Leonardo. It’s very important to get insights about our current transformation state. Identify what our strengths are, and understand and accept our weaknesses to make decisions. Because the decision latency is critical to reduce, because we need to inspect and adapt about our outcomes. DevOps, it’s not only about tools, even though that kind of tool, like the assessment, helps us a lot to, as I said, gain insights from different points of view. In my case, a Product Owner, a Product Development leader, we need to inspect constantly about the results that we get. Because it’s not about what I want as a business, it’s what a market needs. That’s why this kind of assessment helps us a lot through this kind of process, to realize how steps we need to make to get close to our goal or our business objectives for this month or this quarter.

    Murillo: And let me riff off of that a little bit of what you just said.

    Ashley: Yeah—please do.

    Leonardo Murillo: I think you raise a very valid point in terms of prioritizing, right? And I think that’s very valuable of this type of assessment. When organizations approach the adoption of DevOps, attempting to follow a pre-defined path, a pre-defined immutable process, they’re really not evaluating what is most meaningful for the organization at that particular point in time. Like you were just saying, right, when you’re building a product, you wanna deliver those features that are most meaningful, that are gonna provide the most value to the users of that product.

    And I think a capabilities assessment gives us a little bit of that in the context of an organization. There are many, many different dimensions and sub-dimensions of what an organization can improve towards DevOps maturity. But what is more relevant to your organization at this point in time is not gonna b the same for other organizations.

    Ashley: Mm-hmm.

    Murillo: And this type of assessment gives you the ability to identify where to focus your efforts. Because you don’t wanna try and boil the ocean; you don’t wanna try and fix everything at the same time. Because then, you likely will struggle, right?

    So, this concept of identifying, granularly, which areas allow for improvement and providing a quantifiable means to assess which ones are more relevant or your organization at this point in time is a very effective mechanism to direct, after all, scarce resources. There isn’t endless money, there isn’t endless time, and there isn’t an endless capacity of people to change. So, you need to very effectively apply initiatives to those areas that make the most sense for your current state.

    Ashley: Mm-hmm. Spot on—very important point. [Cross talk] How is this administered? How does someone go through the assessment? Is it a series of interviews, do they fill out an online survey? Lots of ways of doing these things—how do we do this with ADOC?

    Murillo: You wanna talk about that Ulises?

    Gonzalez: Yeah, a little bit, it’s ________, it’s a mix between online surveys and, of course, interviews with several leaders or persons of importance of the company, because we need to understand or get that 360 degree understanding about what is really happening. That’s why the instrument or that kind of assessment, it was common understanding of what we need to know about we need to understand what we are.

    That’s why we can use it in several ways. As you said, we can use it from an online survey, so everyone can participate independently of the part of the value stream where you are, because this is a very important topic. And then, when you get inside, you can interview the people who are already responsible, already part of the time to start to make decisions. That kind of point is very important to me as well, because this instrument allows us, we can gain a capability to make decisions as well. We need to wait a long period of time. We don’t need to wait a lot to make decisions quickly in a smart way, data-driven. We can make a data-driven hypothesis, we can put in our roadmap a lot of, as Leonardo said, prioritizing steps to get what the company wants. That’s why this is an easy way to get a lot of understanding on what’s happening right now in our company.

    Ashley: Mm-hmm.

    Murillo: And let me share some ________ as to how I think this also needs to be applied. Because as Ulises mentions, right, the tool itself is an online delivered Likert style assessment, right—multiple questions, different dimensions, and that is used to define the scores to your capabilities.

    But as we’ve mentioned multiple times in this conversation, ever organization is different. And I think this is also where the DevOps Capability Assessment is being partner led. There are consultants out there that are delivering this and applying this in organizations.

    I think this is also why it’s very important to partner with somebody. Because it’s relevant to have an external view to understand where there might be bottlenecks to tie this together with other practices when you think kinda in terms of value stream management. You wanna make this tool a component of a comprehensive intervention, and that intervention is going to be defined not just by the tools that you’re using, but also by the structure of the organization.

    You will want to understand exactly what your structure looks like—both in terms of paper, what the organizational structure looks like, as well as in terms of team dynamics. And that will give you a sense of who you really need to talk to, who are the ones that are influencing, who are the ones that can give you further insights? Extend the tool. I think that’s very important in terms of applying this, which was kinda your original question, right, Mitch?

    Ashley: Mm-hmm.

    Murillo: And this is just one tool in an arsenal. It’s a tool that satisfies a lot of precision in terms of gauging a state, and it needs to be executed in a way that is consistent with the organization, just as the process of maturing into different levels of skill, right, will vary depending on your unique characteristics. I think that also applies in the context of delivering this type of assessment. There is a discovery opportunity for partners to really get to understand the culture of the organization, the culture of the teams.

    And I think another component that is relevant, and in the book Accelerate, that I’m sure everybody is familiar with by now, there’s this concept of organizations trying to apply DevOps practices to one group and then just trying to replicate that across the organization and now that really doesn’t work too well.

    As you expand your DevOps adoption to more groups in the organization, you’re gonna have to repeat a little bit of the process to really understand how each one team will evolve, and what is the current state of each different organization as you expand. This is not something that you do once, you transform a business unit once and then you copy paste. That’s kinda all the thoughts that come to mind when you mention how this actually looks like in practice, being applied within an organization.

    Ashley: Well, and it seems extremely helpful to have the data that’s collected through the online portion and then really, those interviews also add, as you mentioned, talking about things like culture, structure of the organization—it’s that context, right?

    So, you may be wherever you are on your answer to certain parts of the assessment tool, but understanding how that fits into your environment, your company, your culture, how you work—I like to describe thigs as, you know, if you are a data driven, no decision gets made without data, that’s a different kinda culture than one who goes by, let’s say, these are the inspiring leaders that help make the important decisions, right, just to pick two very different examples. But that context matters. You’re gonna take different actions based on the environment that you’re doing DevOps in. [Cross talk]

    Let’s talk about how someone would use this—I’m sorry, Ulises, I cut you off there, but we really wanna hear, too. So, you go through this process with your help. What does someone get from it? Do they get a document or a readout? And then how do you go about helping them with the next phase of using some of that information to their benefit? Go ahead.

    Murillo: Yeah. Go ahead, Ulises.

    Gonzalez: Okay, everybody. [Laughter] Okay, to me, of course, there are different outcomes you can get, absolutely. You can, after you complete that kind of assessment, you gain insight of your current information, you get the ability to benchmark your teams and your organization across different industries on your actual level of practices. With our help, you can visualize the road ahead from one baseline to another future state. Of course, the management gets the investment areas, so we need to make decisions. They’ve got very normalized indicators to understand what we need to do on the next iteration or the next spring or the next process.

    Of course, the operation teams part gets understanding on most critical areas you need to improve. So, as I said, the assessment brings us a lot of information with data, normalized data, in a controlled environment to make decisions, to make smart decisions, to gain common ground, to create consistency. Because, as Leonardo said previously, to me, it’s about consistency and a holistic view in a way that enables everybody in the company to understand independently of the level that we are, we understand the same parts of DevOps that we need to achieve, because it’s a business outcome we need to support.

    So, that provides us with a high impact of our software, our service, our productivity. So, more than an instrument that provides us number, it gives us very helpful insights, as I said, to make wise decisions.

    Ashley: [Laughter] I appreciate your perspective on it, Leonardo, because what you’re describing, Ulises, very much follows that Plan Do Check Act.

    Gonzalez: Yeah.

    Ashley: You know, take those actions based on that continuous improvement process and cycle again so you can use this as a tool more than once, right? You can go back and assess yourself maybe in a year or so, see if you—did you end up where you thought you were going to head, or did, actually, the journey migrate a little bit, move a little bit on a different track, now let’s adjust to that and move forward?

    Murillo: Exactly, exactly. And I think the Act component is where there’s a lot of room for creativity and innovation, right? Once you have your, as Ulises points out, your normalized metrics, right, your normalized numbers, you will need to identify what are the better mechanisms to influence change, to produce change? They might be technical, they might be technically implemented, they might be technically led, and they might not.

    So, here’s where training—and I’m shamelessly plugging, her, the DevOps Institute, this is where a lot of the skill up type of initiatives that organizations like the DevOps Institute also promote and enable. There is skill up, there is education, there is cultural changes, there is many, many ways in which you can act. And, as you point out, Mitch, which is really, really spot on, you will need—you want to constantly measure. And in terms of constantly measuring the impact of these changes, you need to reassess, and it’s a constant, ongoing effort, whether it’s every year, whether it’s every six months, whether it’s more often, I think it depends on the state of the organization and kinda what they’re experiencing at this point, what they’re going through at this point.

    But I think it should never stop, because it’s continuous improvement, so you want to constantly renew this perspective of where you are.

    Ashley: Well, let’s talk a little bit about—so, how would one go about doing this? Do we visit the DevOps Institute site and that kinda helps us get the process started, maybe we have a partner, one of your organizations already, or maybe we need help in selecting somebody to help us go through the process? I assume there’s resources available on DevOpsInstitute.com, is that correct?

    Murillo: I think that’s correct. I think you can go and see all the different partners that are offering this tool, and you can basically look them up. That’s what I would do, look them up, see what their specific areas of expertise are in addition to the tool, where they’re located, and get a sense of who might work best for your organization. It’s a tool that, I think a lot of the value of the tool revolves around it being introduced by a partner that can lead the way. It’s sometimes difficult to gauge when you’re too close, right? So, go to DevOps Institute and look for a partner.

    Ashley: And it’s a global activity, right, as represented by both of you.

    Gonzalez: Yeah.

    Ashley: We were talking U.S. and Panama, and I forgot where you were.

    Murillo: I’m based in Costa Rica, yeah. My [Cross talk] is actually not based in Costa Rica, so we sell to the U.S. market.

    Ashley: I see.

    Murillo: But I’m in Costa Rica and I speak Spanish, so if you want some Spanish support, you’ve got two people here that can give you that guidance.

    Ashley: Exactly. Well, very good. We’re running out of time, unfortunately. We could talk about this all day, I’m sure there’s some really interesting things and, as you do this with organizations, you know, you carry that knowledge with you to the next customer, too, so there’s benefit in working with you as you go through this process, because it—

    Murillo: Oh, and Mitch, you bring something up—real quick, before we go.

    Ashley: Mm-hmm.

    Murillo: There’s something unique about the Assessment for DevOps Capabilities, and that’s that the body of knowledge that was used to produce this tool is directly extracted from the real world experience of, I don’t remember the number, but it’s dozens of actual DevOps practitioners, the DevOps Institute’s own Ambassadors and other partners, I think there’s tremendous value in that. It gives a collective perspective, a joined wisdom that I think is encapsulated in the tool.

    Ashley: Mm-hmm, yeah. It’s far from an academic exercise, right?

    Murillo: Mm-hmm.

    Gonzalez: Yeah.

    Ashley: Developed by DevOps people for DevOps people.

    Murillo: Exactly.

    Gonzalez: Exactly.

    Ashley: Well, it’s been a great pleasure talking with both of you, Leonardo and Ulises, and I wish you the best as you work with organizations and use the ADOC tool, and we’re looking forward to seeing some great impact and help that you can help bring to their organizations. Thank you for joining me today. Great to talk with you both.

    Murillo: Thank you, Mitch.

    Gonzalez: Thank you so much, bye bye. Ciao, Leonardo.

    [End of Audio]

  • Languages and DevOps: Recommendations

    Languages and DevOps: Recommendations

    In light of the points brought up in these articles, what is my advice for which language to use on a given project? The same advice I have always given development teams: Use the right tool for the job. My father was a woodworker, and drilled that concept into me. I brought it to development, and it is true. The difference is that “the right tool for the job” is a much more complex question in an existing IT environment than it is in woodworking. Whether you need a chisel or a screwdriver is immediately obvious. Whether Python or Go is the right tool … not so much. Things to consider:

    Does the tool have a broad developer base?

    This is the most straightforward question on this list. Can you get people to work in the language? I worked at a place that still had RPG III code running on a mainframe. We used to joke that those two retired developers in Australia were getting rich from maintaining it – and we still did some new development in the language. It was a bad choice that we moved away from. Maintaining the old while developing a new platform made sense. Packing any new functionality into a tool about which few knew the ins-and-outs, and even fewer were being trained for? Made no sense.

    Does the tool specialize in, or have modules/add-ons that customize it for your target?

    While at the 50,000-foot level, you can theoretically do any computing job in any language, that doesn’t make your preferred language a wise choice. Making certain the tool supports what you need to do is paramount. This is the closest to “right tool” thinking – does it do the job?

    Is the developer base growing or shrinking?

    While this is more important for longer-lived projects, you do want that developer base mentioned in the first point, above, to still be around. This extends to add-ons, also. If you choose ASP.NET today, will it be a solid choice tomorrow? (I’m not saying it won’t, here, just picked one framework to illustrate the point with).

    Does the tool do what you want, or will you be working around faults to get there?

    Honestly, you can – and people have done it – write websites in C. That doesn’t make it the right choice. You’ll end up spending more time getting around the fact that C is ill-suited to this task than you will developing the actual site. Assess the language with regard to how well it actually does the job you need to do. This is a different take than the second point, above – this is the “just because you can, doesn’t mean you should” part.

    Does the tool fit in your environment?

    This is the one that far too many struggle with. New development teams want to bring the tool they’re most comfortable with, because it reduces development cycles in the short term. The issue here is simple. It is far easier to manage an environment that makes a conscious effort to keep our burgeoning number of tools, languages and libraries as controlled as possible. Introducing Go to develop servers, just because someone is excited about it, makes no sense if the entire environment is Node on the server side. Use the environment you have so you can maintain things more easily. Everything is more thoroughly vetted – from which add-ons to include through security – with the language an organization uses the most; take advantage of that. Start with, “We use Java in 70% of applications,” and then deviate from there only if you are moving toward a goal of moving off of Java (again, not saying you should, just an example).

    As a New DevOps Person, Which Should I Learn?

    Not so long ago, the ubiquitous advice to new developers was, “Learn Java!” It was everywhere, doing everything, even when it wasn’t the best tool for the job.

    Similarly, that answer is now “Learn Python!” Of all the languages out there, it is the one used the most. I do not have data to back the following statement up, but I will bet most Dev people have used Python on one or more projects already, and a fair number of Ops people have, too. If Java is the past, Python is the future.

    That said, check out companies where you would really enjoy working and see what they’re doing. Generally speaking, they’re not looking to hire Python developers if they are doing 70% of their coding in Go. I can’t recommend tailoring your learning to one or two organizations’ environment(s) (unless you already work at one of them), but consider the popular languages that have been listed in this series and learn the ones your target organizations use first.

    All of these languages have free/cheap options for learning them. No one is stopping you from learning Go; indeed, there are websites whose purpose is to help you learn by doing. The same type of learning is available for most languages, with implementation details varying a bit. There are a wealth of great books available for all of them, also, if that is your preferred method of learning a new language.

    In the end, learning a new language will never be a negative. It will help you be aware of the list above, and provide meaningful input in the inevitable “Is this the right tool?” conversations.

    So, start with Python and then work through others. With one side note: if you lean toward the Ops side, know what different Ops tools require, and consider learning some of those, also. There is one prominent Ops platform that still uses TCL, for example, and we all know about CICS. So be aware of what might be needed, and at least be familiar with that.

    And Keep Rocking It

    Modern IT environments are unbelievably complex. From rights management to storage, to data gravity, to a wide array of languages and appliances – you and your teammates are keeping it all humming. Keep doing it. Learn new languages before they become necessary to your job, but never think you’re falling behind. If the company is still clipping along, you are the right person for the job.

  • Seeing the Bigger Picture With BizDevSecOps

    Seeing the Bigger Picture With BizDevSecOps

    Not long ago, if you can believe it, software was shipped on physical floppy disks and CDs. These physical relics contained dense paper instruction books that humans read diligently for hours on end (I guess they had more time to spare back then?). Complexity was a given for computer-based tasks.

    Fast forward past the consumerization of IT to 2021, and you’ll find extremely high standards for technology. End users now expect intuitive apps with instant end value and 100% uptime. If they don’t receive gratification within minutes, they’re likely to trash it.

    In the race to meet digital innovation demands, software companies are increasingly tapping new strategies to deliver iteratively. Thus, disciplines like DevOps, DevSecOps, low-code and SRE have flourished. But are we adequately considering the end value of that work? Some feel business leadership needs a larger seat at the table and more input: enter the newest iteration of these disciplines, BizDevSecOps.

    I recently met with Gregg Ostrowski, CTO at AppDynamics, to discuss how to introduce BizDevSecOps in an organization. For Ostrowski, it boils down to having full-stack observability to connect application performance, security threats and revenue generation. Only by democratizing access to important metrics and identifying runtime weaknesses can business outcomes truly drive production.

    Full-Stack Observability

    Within our new pandemic-first reality, all organizations are amplifying their use of digital services to interact with customers. However, software teams are struggling to keep pace in this new environment — 89% of technologists report feeling under tremendous pressure at work, the Agents of Transformation 2021 report found. This strain has only increased as IT complexity soars amid the pandemic — 83% felt their job became more complex over the past year.

    IT staff is under mounting pressure to perform, and they may not have the correct elements in place to support elegant and profitable applications, said Ostrowski. When it comes to monitoring, in particular, alert fatigue could especially hamper innovation attempts and make it difficult to know what to prioritize.

    Instead, Ostrowski advocates for letting tangible business outcomes, such as conversion rates and performance, drive development. To correlate the impact on revenue more directly, he encourages “giving business leaders a seat at table during the entire CI/CD pipeline.” One aspect to roping in business, security, development and operations is unified observability across the entire stack.

    The Pendulum Swings

    But wouldn’t it be challenging to give business leaders a seat within a technical software delivery process? Well, this wouldn’t be the first time business has directed technological change.

    Ostrowski recalls the mid–2000s and the dawn of the mobile market. During this period, IT became consumerized for laypeople, with glossy apps and impressively intuitive experiences. He recalls a general loss of faith in IT staff, as workers often had “better tech at home than they did in the office.” This drove business leaders to invest heavily in modernizing their companies.

    In the following years, cloud solutions quickly re-empowered IT with new computing models, emboldening them to compete using the same tools as tech companies. However, simple deployments using a single server quickly morphed into arranging multiple workloads on various cloud service providers (CSPs). Virtualization, serverless and microservices architectures also brought novel complexities into the stack.

    “The IT staff is being asked to do jobs they’ve never done before,” Ostrowski said. He explained that SREs, for example, must understand networking, infrastructure and security — a vast portfolio for a single person and role. Supporting many disparate paradigms is simply beyond the scope and scale of what a single person can do, meaning new automation must be constructed — because “if you’re too busy debugging, you can’t innovate,” says Ostrowski.

    Amid mounting complexity and the burden of rising cloud costs, it appears business leaders again have a role in directing and prioritizing technological efforts.

    Getting Busy With BizDevSecOps

    According to Ostrowski, connecting IT and business with BizDevSecOps all hinges on collaboration. “If you don’t get to a point where you can collaborate with all these pillars, you’ll degrade your business,” said Ostrowski.

    BizDevSecOps also could help connect the dots to comprehend anomalies. For example, suppose a commerce application is experiencing a 15% conversion rate, but it drops to 7% after an upgrade. In this scenario, collaboration is crucial to identify usability bottlenecks in production and adjust accordingly.

    Tracking business outcomes can align development around improving the user experience. If broken features are hurting conversion rates, all stakeholders need to know to adjust accordingly. “User experience is the golden gem,” said Ostrowski.

    Other benefits of a BizDevSecOps approach may include:

    • Correlating activity and revenue: Ensuring spikes of activity are associated with revenue generation and not attacks or faulty instances.
    • Workload optimization: Monitoring business outcomes can help adjust the scope and size of machines as needed.
    • Before and after: Comparing financial results before and after migrations, new versions or new feature additions.
    • Postmortems: Pinpoint and correlate data when conducting postmortems.
    • Progressive delivery: A more rapid release frequency helps a business retain agility and pivot when needed.

    Visibility Enables BizDevSecOps

    DevSecOps is now a common philosophy — it promotes development with security baked into the application. Now, BizDevSecOps could be the next iteration; a collaborative approach that considers additional perspectives. BizDevSecOps is a vital method to “continue to build trust and collaboration so everyone has a seat at the table,” said Ostrowski.

    Ninety-six percent of technologists agreed that monitoring the entire IT stack to connect technical performance to business outcomes will be important in 2021, the Agents of Transformation Report found. To enable this, business, security and development must inevitably de-silo. According to Ostrowski, adopting BizDevSecOps depends on a window into performance management and business intelligence, because “when changes happen and no one knows about it, it’s a serious problem,” he added.

  • Unified Enterprise DevOps Platforms Eliminate Bottlenecks

    Unified Enterprise DevOps Platforms Eliminate Bottlenecks

    Nearly all enterprise digital transformation projects include moving software to DevOps processes and platforms. The effort, cost and time it takes to be successful with these transformations depend on a lot of factors, but one thing stands out: as indicated in my white paper Unified Enterprise DevOps Platform Why? How? And What?, “An enterprise with many variations of DevOps platforms and tools is at best chaotic, and at worst, is a gross impediment to overall organization agility – undermining the very purpose that DevOps is meant to serve.”

    In my recent blog Why a Unified Enterprise DevOps Platform is Necessary, I indicated that “The aggregate set of platforms and tools is like a Frankenstein’s monster, with many incompatible parts resulting in an awkward looking product that is hard to control, replicate and evolve.”

    Success with DevOps requires frictionless interplay between the people, processes and technologies that need to cooperate for continuous deliveries to happen effectively. The existence of different DevOps solutions creates organizational barriers to unification, because different groups become dependent on their local variations.

    A Unified Enterprise DevOps Platform Accelerates Time-to-Value

    Culture barriers, process problems and DevOps platform “wars” all are factors impacting the progress of digital transformations. A unified enterprise DevOps platform would accelerate time-to-value, and realize efficient, safe operation for digitally transforming enterprises and organizations.

    The following are general requirements for a unified enterprise DevOps platform.

    ● A new, unified approach that supports end-to-end capabilities for continuous delivery of software, as a managed service, for multiple streams of pipelines.
    ● Unified metrics that show business value, costs of the value stream and timing for end-to-end continuous delivery flow across multiple pipelines.
    ● Unified capabilities including visibility, orchestration, integration, security, governance, traceability and management of flow for application value streams across multiple pipelines.
    ● Capabilities to unify continuous testing/QA, troubleshooting and debugging.
    ● A new, unified approach to simplify and accelerate toolchains that support new cloud-native and cloud-adapted applications, infrastructures, machine learning, commercial off-the-shelf and open source software.

    A DevOps Platform Blueprint

    In my SlideShare DevOps-as-a-Service Values, I described a four-layer blueprint for a unified enterprise DevOps platform that satisfies these general requirements. The main elements in the blueprint are:

    ● Stakeholders – There are three types of stakeholders: business, appdev users and DevOps admin teams.
    ● Service access layer – Consists of portals and APIs for business, appdev and DevOps administration users and access security.
    ● Service layer – consists of user services and DevOps admin services.

      • User Services include things that appdev users need to perform their application development and testing work. This includes capabilities for no-code automation and orchestration, repos for code, artifacts and data, multi-CI/CD pipelines and sandboxes, test data, configuration, continuous testing/QA, service level objectives (SLOs) for business and appdev users and troubleshooting and debugging.
      • DevOps admin services include things that a DevOps team needs to administer and manage the platform. This includes capabilities for platform administration, the ability to import pipelines into the unified platform, integration with enterprise service catalogs, integration with enterprise issues and change request systems, SLOs for DevOps administrators and capabilities to implement governance policies-as-code.

    ● Resources layer – includes resources that the services need to run including application stacks, infrastructure resources, tools, infrastructure code and topology data.

    One of the most important benefits of a unified platform is the ability to unify SLOs for each class of stakeholders. The SLOs need to be chosen to best fit the requirements of each application.

    Business value can be demonstrated by the following SLOs:

    ● Productivity metrics.
    ● ROI data tracking.
    ● Agility of services – Lead time for changes and frequency of releases.
    ● Reliability of services – Change failure rate; time to restore services.
    ● Governance compliance and security.

    Appdev user value can be demonstrated by the following SLOs:

    ● Platform availability.
    ● Service response time.
    ● User experience scores.
    ● Change request response time.

    DaaS team value can be demonstrated by the following SLOs:

    ● Scope of applications – number of apps supported, number of users per month.
    ● Number of requests served per month.

    Without a unified enterprise DevOps platform, all these SLOs would have to be implemented multiple times, once for each type of DevOps platform.

    To realize DevOps-as-a-Service for enterprises with multiple related pipelines, each pipeline needs to be configured to work within a unified model where common tools process each application and microservice continuous delivery task in parallel. Unified control and monitor points are needed – and should be exposed by the unified platform – to realize SLOs in a unified way. Without a unified platform, all of these SLOs will need to be implemented separately, for each platform, and then another system will be needed to aggregate them into a common view.

    The SLOs will indicate where the biggest bottlenecks are for a particular pipeline. In many enterprise pipelines, the biggest bottleneck is testing, troubleshooting test failures and debugging to resolve the failures. It is a myth that continuous testing is just the execution of automated tests. The whole range of “testing things” includes test planning, test resource scheduling, test design, test implementation, test environment management, test execution, test results reporting, test result analysis, troubleshooting, debugging, fix retest and test management, and all can be sources of bottlenecks. These “testing things” are all sources of bottlenecks for every stage of a DevOps pipeline, for all Three Ways of DevOps. Without a Unified enterprise DevOps platform, all these testing things must be addressed separately, in accordance with the different pipeline platforms.

    Testing, troubleshooting and debugging tasks are a major source of bottlenecks for most DevOps value streams. A unified platform improves continuous testing/QA, troubleshooting and debugging as follows:

    ● Continuous testing/QA – Orchestration of test environments, execution of tests and reporting test verdicts is unified.
    ● Troubleshooting – Failures are displayed in a consistent format, including trends correlated to pipeline and application log data, to simplify analysis of test failures.
    ● Debugging – Causes of failure can be isolated with intelligent analysis of troubleshooting results, and the platform can quickly install the fixes and orchestrate the test environment to verify the fix is working.

    These testing, troubleshooting and debugging advantages have a major impact on the ability to accelerate digital transformations.

    What This Means

    Digital transformation of many enterprises and organizations are being seriously impeded by having too many DevOps platforms and tools. A unified enterprise DevOps platform resolves the technical problems of broken, leaky, “Frankenstein” toolchains and processes. Enlightened leaders that understand the importance and the broad impacts of unified enterprise DevOps platform are wise to recognize the sense of urgency surrounding a migration to a unified platform, and take action to stop the proliferation of too many platforms.

    To realize a unified enterprise DevOps platform in an enterprise takes more than simply buying and installing a new platform and telling everyone to start using it in place of what they are used to. With multiple entrenched DevOps platforms in place, there are practical and political considerations that must be overcome. Introducing any changes across a large group of applications in an enterprise can be chaotic, and will often be more costly and take too much time if the changes are not well-coordinated in accordance with a carefully crafted strategy and implementation roadmap that leaders and team members are aligned with.

  • Survey Finds Digital Transformation Outcomes in Doubt

    Survey Finds Digital Transformation Outcomes in Doubt

    The COVID-19 pandemic forced organizations, both large and small, to either launch or accelerate digital business transformation initiatives that, to varying degrees, depend on their level of DevOps acumen to succeed. Value stream management platform provider Digital.ai today published the results of a survey of 200 IT decision makers, 200 security decision makers and 200 business executives in organizations with at least 500 employees which suggests that, while there’s a lot of confidence in those initiatives, the business outcomes those efforts are intended to enable are still very much in doubt.

    The survey finds 95% of respondents believe their digital transformation initiatives are going well, with 22% reporting they have been completed. Just under a third (32%), however, said they still have a lot to accomplish. Just under half (49%) said they have yet to see the results they expected. In fact, more than half of respondents (56%) also noted they are concerned about the return on investment (ROI) of those initiatives.

    Overall, the survey suggest optimism continues to prevail. A full 92% of respondents said they are creating new value for the business, with 93% claiming the business as a whole remains competitive. However, more than half (57%) are concerned that business, IT and security goals might be misaligned. More than half (54%) are concerned about meeting customer needs. Nearly two-thirds are concerned about software vulnerabilities.

    More challenging still, 94% of respondents need software development and delivery to be better aligned to business objectives. Only 54% claim to be strategically aligned. Almost every respondent (99%) needs more visibility into business planning processes, with just over a third (34%) noting they are not especially good at attaining that visibility.

    Not surprisingly, a full 91% said they still need more time to work on their digital business transformation initiatives.

    Derek Langone, head of strategic transformation for Digital.ai., said the survey makes it apparent there is a much greater need for a set of key performance indicators (KPIs) for IT teams that are tied to specific business objectives. As organization of all sizes realize how dependent they have become on software, any delay can have a major impact on revenue and profitability projections, noted Langone.

    Of course, not every digital business transformation project is going to succeed, no matter how optimistic business and IT leaders may be. Many initiatives were hastily conceived during the early days of the pandemic. Others were simply accelerated without enough due diligence. Digital.ai is making a case for a value stream management (VSM) platform that enables organizations to first understand the true status of these projects by synthesizing all the data residing in various DevOps platforms, and then assessing the impact any delays might have on the business.

    It’s not quite clear how many organizations have managed to get as far as they have without at least some VSM platform equivalent. However, as software development continues to become more complex, it’s also apparent that without a VSM capability, the odds various digital business transformation initiatives currently underway will eventually be derailed are substantially higher than many IT and business professionals would like to admit.

  • What Amazon’s New CEO Means for IT’s Future

    What Amazon’s New CEO Means for IT’s Future

    Amazon is placing its bets on the future of cloud. The announcement that CEO Jeff Bezos will be stepping down and passing the torch to Amazon Web Services (AWS) leader Andy Jassy at the start of Q3 2021 signals a major shift in the future of technology – and not only for organizations specializing in IT, storage and web hosting. Rather, the growth of AWS signals a multi-industry-wide demand for cloud services as the new normal for conducting business – and those that continue to rely on legacy technologies could soon see their businesses falter in the shadows of competitors in the near future. However, every company’s individual systems are entirely unique, and modernization doesn’t happen with a one-size-fits-all approach. So why should organizations invest in new technologies – and how?

    Setting Sights on the Cloud

    The pandemic has made painfully clear the need for organizations to get away from their aging legacy systems and to embrace the cloud for a variety of reasons. First, COVID-19 has forced almost all businesses, across all industries, to embrace more distributed networks – requiring business-critical systems and functions to be accessed from countless different sources at any given moment. This can prove a major pain point for organizations with IT infrastructures that are prone to difficulties and outages. These shortcomings can have a detrimental impact on customers and citizens, as well. In light of major IT outages in states like New Jersey, California and Oregon, it’s clear that pursuing a more modern approach to IT systems is no longer just an option – it should be the only option. This is because, in addition to the benefits for users and enhanced business function, there are added benefits for the company itself and the world at large.

    Shifting systems away from data centers requires significantly less energy to power – and as data centers are responsible for as much greenhouse gas emissions as the airline industry, the environmental impact coupled with operational cost savings enable businesses to meet customer demands for greener practices while reducing overall operational costs. What’s more, this change to cloud services will allow for horizontal scalability within organizations, ensuring that businesses are able to meet demands for their offerings in real-time.

    The Sky is the Limit: Strategies for Improving IT Infrastructure

    If your organization is relying on a mainframe, it won’t be able to reap the many benefits that cloud infrastructure has to offer – and organizations that shy away from making these vital updates run the risk of running their business offline entirely. As a result, the time to act is now – but in the rush to get IT departments in order, it’s vital that organizations choose a modernization strategy that is best suited to their unique business. For most organizations, a modernization journey begins with one of the four following approaches:

    • System Replacement: Sometimes, organizations aim to expedite their modernization journeys by doing away with their aging legacy systems entirely. Through a system replacement, organizations purchase off-the-shelf solutions from third-party vendors and conduct business via the new software while their existing infrastructure and applications are taken out of service. While this approach enables a speedier shift toward the cloud, it should be noted that these solutions aren’t tailored to a specific company’s needs or functions, and that these solutions can be especially costly.
    • Rewriting: In an effort to retain key legacy knowledge while enabling better business function, some organizations pursue a rewrite of their existing systems within a more modern environment. Through this approach, a team of professional developers work to manually recreate the system and its applications – which often results in an extended timeline for modernization, exorbitant costs and an especially high risk of complete project failure.
    • Automated Refactoring: Through looping in a team of IT experts, this strategy enables an organization to migrate their legacy system’s procedural code bases into object-oriented languages within modern environments that are more appropriate for today’s business demands. Using specialized and automated tools designed for the project at hand, this modernization strategy ensures that an organization has a system designed for its unique business cases and an immediate pathway to the cloud.
    • Rehosting: To help companies maintain their legacy information, many organizations pursue rehosting as part of their modernization strategy. In this approach, a company’s existing legacy codebase is transferred away from their mainframe and their unchanged procedural code bases, data and other core functions into a new computing environment that is more suitable for current needs. This fast-paced process helps to set organizations on track toward the cloud as quickly as possible.

    Aiming for the Cloud(s)

    Amazon’s shift in leadership is a testament to the growth potential and overall importance of the cloud – not only for companies that manage web services, but for all industries around the world. However, by proactively taking the steps to move away from legacy systems and pursue a cloud-first approach to business, organizations will be better positioned to maintain their revenue streams, improve scalability, drive customer satisfaction, reduce operational costs and even protect themselves from potential disasters down the line. By setting and sticking to a set strategy and timeline for modernization, companies can ensure the success of their most mission-critical applications and functions to ensure their continued success and survival in a world or rapidly changing business demands.

    The sky is the limit – are you ready to aim for the cloud(s)?