devopsy.kinsta.cloud

Category: DevOps Practice

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

  • Low-Code Automated Software Testing Drives DevOps

    Low-Code Automated Software Testing Drives DevOps

    The DevOps world has quietly turned its focus to solving an essential challenge: enabling software teams to innovate quickly while meeting high customer expectations for quality. In other words, to build useful things faster with fewer mistakes. This tension has been growing for years, but 2020 added the challenges of remote work and accelerated digital transformation to the continued disruption brought about by cloud, SaaS and DevOps. In 2021, we need a road map for taking test automation to the next level with quality engineering, a discipline that incorporates best practices and data-driven testing into the end-to-end customer experience and drives organizational growth.

    Rethinking the Quality Process for the DevOps Era

    Quality engineering (QE) has traditionally lacked the tools needed to keep pace with digital transformation. Many QE teams struggle with complex, brittle automation frameworks and slow manual testing which create serious bottlenecks to DevOps adoption. While development accelerates, QE is left with disparate or outdated workflows and toolsets.

    Rising to the challenges and opportunities presented by DevOps and digital transformation will require innovation in our approach to quality. More than ever, we need to shift our focus away from quality assurance as a task that you perform late in the software development life cycle (SDLC) in favor of quality engineering practices throughout the entire life cycle. It starts with broad, effective test coverage – beginning when your developer is working on a local branch and continuing until a high-quality customer experience is confirmed in production across the entire surface area of the application – web, API, mobile, email, PDF or otherwise. It also goes deep; you evaluate all aspects of quality, ensuring that you satisfy requirements related to functional correctness, accessibility, performance, user experience and more.

    Low-Code Test Automation Unlocks a Culture of Quality

    With low-code, genuinely effective testing is at the fingertips of every role, from manual testers to developers, automation engineers, product owners and customer support. Requiring all of these roles to develop specialized programming skills is impractical, so low-code tools serve to democratize quality engineering by enabling everyone to participate in authoring tests, updating tests, and gaining insight from test results.

    Low-code testing brings several advantages to quality engineering, particularly in the transition from manual testing to automated testing. While traditionally this process would create major disruptions, low-code platforms are smoothing the way. In their IT Automation predictions for 2021, Gartner expects that by 2024, improvements in automation capabilities will refocus 30% of IT operations efforts from support to continuous engineering. For manual testing teams, that shift would likely trigger talent changes and a long process of pilot projects, retraining, and gradual rollouts. Low-code is key to managing this shift, upskilling workers and ensuring quality throughout.

    Modern Automation Solutions Embrace Rapid Change

    A key challenge with traditional test automation tools is that they were designed for applications that didn’t change frequently and were intended only to validate code. They relied on static selectors to identify page elements. If the selector (say, an ID) changed or objects (the XPath) moved on your webpage, then your tests failed. As more enterprises accelerated development via DevOps, Agile and CI/CD, the burden of test maintenance resulted in the same bottlenecks as manual testing.

    2020 was a breakout year for low-code test automation. New, easy-to-use solutions surpassed the capabilities of legacy frameworks that have dominated the sector. These solutions incorporate machine learning, data analytics and other advanced technologies to greatly reduce the burden of test maintenance and overcome the test rigidity challenges of legacy frameworks.

    With AI and machine learning, test automation solutions are trained by a tester simply navigating their product. As the tester moves through common customer journeys, the solution builds an understanding of each element and its context so that if an element moves or a property changes, tests containing that element are updated without human intervention. This drastically reduces the amount of maintenance required to ensure your tests are current. When tests do need to be updated, low-code models make it easy for anyone to jump in and make the updates. Looking ahead, auto-healing and low-code editing are crucial to supporting quality engineering in high-velocity teams.

    Testing the Entire Customer Experience

    Traditional pass/fail validation stops short of offering real insight into the user journey, a critical step effective quality engineering. The next generation of test automation platforms expands focus from validating code to validating the entire user experience. This starts with broadening testing to cover non-functional requirements, such as application performance, accessibility, and user experience. For example, identifying trends in load time for key pages and monitoring visual changes are done autonomously and essential to managing the customer experience. From there, you can prioritize quality efforts toward the components of your application that are most heavily used or highest risk. This enables you to make data-driven decisions about test coverage — focusing your testing efforts on high-priority pages like the checkout page for an e-commerce site, or high-risk pages such as those with multiple interactive elements that are linked from other pages, such as signup forms.

    But even a fully data-driven testing strategy that only focuses on the app or website UI is unlikely to cover the full end-to-end user journey, resulting in test coverage gaps and potential pain points for customers. For example, a common user journey may include opening an email, clicking on a link, checking a web site, and downloading a PDF. Whereas the limitations of legacy tools relegates testing to the web portion of that journey, modern solutions allow you to validate the entire user or customer experience (CX): receiving and opening an email, clicking on the link, logging into the web site, downloading the PDF and verifying its content. It’s even possible to confirm values in the backend via API – all without writing a line of code. Developing the tools to seamlessly monitor, repair, and manage the expanded CX is central to our innovation and to our customers’ success.

    Quality Engineering as User-Centric as You

    Quality is no longer an afterthought or just a box to check before deployment; it’s an essential part of the user experience, and therefore an essential part of maintaining a competitive advantage in every industry that uses software to serve customers. Test automation is critical for high-velocity teams racing to innovate faster, shift to DevOps, and build quality products while working remotely. Thankfully, a growing number of quality assurance teams are getting a seat at the table as DevOps is implemented, elevating the profile of quality as a strategy and growing demand for test automation solutions that can keep pace with the demands of DevOps.

    In response to this demand, a new generation of intelligent test automation solutions is enabling teams to rise to the challenge by embracing low-code and machine learning to maintain quality. To build a culture of quality engineering in this environment, your team needs test automation solutions that are as user-centric as you are: solutions that provide coverage across the entire user journey. Solutions that not only verify functional correctness, but provide rich insight into all aspects of quality and enable continuous improvement. Perhaps most importantly, you need solutions that enable everyone on the team to participate in quality. This ensures that the entire SDLC actively participates in building user-friendly products that continue to set the standard for quality at the speed of DevOps.

  • Solving Cloud-Native Challenges in the Rush to the Cloud

    Solving Cloud-Native Challenges in the Rush to the Cloud

    The shift to cloud-native environments away from traditional data center infrastructures continues unabated, but security and complexity challenges remain a struggle for DevOps teams.

    These were two of the main takeaways in a survey and analyst report published by the IT consultancy firm Flexera. 

    The survey, based on the responses of 750 IT professionals, revealed that 92% of the organizations represented in the survey have a multi-cloud strategy, 80% have a hybrid cloud strategy and only a minority (45%) have integrated data between cloud environments.

    The top challenges, according to the survey results, are:

    • security (81%)
    • managing cloud spending (79%)
    • governance, lack of resources/expertise and compliance (75%)
    • comprehending cost implications of software licenses (55%).

    The solution for these challenges largely involves — in addition to implementing the right DevOps culture and practices — adoption of the right tools and platforms, especially for security. However, first-generation cloud-cost management tools “simply are not cutting it” for modern architectures, said Asim Razzaq, CEO of Yotascale, which offers a cloud resource optimization platform.

    “Today’s modern architectures are dynamic, and ownership is transient and not always well-defined. The greatest strength of containers and Kubernetes is the ability to scale on-demand and share cloud resources among multiple applications,” said Razzaq. “Tracking cloud costs in modern architecture requires a strong ability to automate cost attribution — or tag management — for those dynamic resources, and the ability to understand usage at the application level, even for containers that are sharing resource instances.”

    First-generation cloud management tools are, in this way, unable to provide the information DevOps teams require to understand how to automate cost attribution for modern architectures, said Razzaq.

    “[DevOps teams] can’t break down costs into any level of meaningful detail for engineering and finance teams to digest and act upon,” said Razzaq. “Conversely, newer approaches that are focused on Kubernetes cost management lack the ability to understand and break down the costs of non-cloud-native workloads.”

    Indeed, tools are often frustrating to engineering teams because of their static custom reporting, broad and generalized recommendations and no effective workflow for effective collaboration between finance and engineering, Razzaq said.

    “The biggest source of frustration is the inability to drill down and manage costs in a way that matches the way that these teams do business. There may be 10 teams, each with five production applications running in the cloud, for a particular account,” Razzaq said. “Engineers need to see, at the application level, what their resource utilization, costs and cost anomalies are in order to make the best cost/performance decisions for their applications. Without that, they’re flying blind; having to defend their cloud usage without any supporting data.”

    As an example, a misconfigured Kubernetes cluster can “cause a massive spike in costs,” Razzaq explained. “Without detailed cost and utilization reporting at the team and application level, an engineer can spend weeks digging through spreadsheets and logs trying to track down the source of the anomaly. That’s weeks of their time that they aren’t [using to] be productive on new features.”

    cloud-native

    Razzaq said there are a number of solutions DevOps teams can adopt to address these issues, including automated cost attribution and tag management, actionable recommendations and comprehensive observability capabilities.

    Automated cost attribution and tag management “is the foundation of accurate and detailed cloud cost management,” said Razzaq. “Engineers need tools to help them set tag management policies, identify untagged instances and update tags quickly and easily in their cloud environment,” he said. “With this in place, cloud-native workloads can be automatically tagged as they are dynamically created, ensuring that cloud costs are always clearly attributed to the right teams and applications.”

    Actionable recommendations at the cloud-instance level with closed-loop feedback also are an important process “so that engineers can see exactly why the recommendation is being made, and what the cost impact will be of taking that action,” Razzaq said. “The ability to provide feedback on the recommendation and dismiss recommendations that don’t align with business needs ensures that new recommendations are relevant,” Razzaq added.

    Finally, tools that provide a unified view of both cloud-native and traditional workloads that have been shifted to the cloud help to ensure “that engineering and finance have a single source of truth for their cloud costs that enables them to make smarter decisions for their business,” Razzaq said. 

     

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

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

  • 4 Ways SASE Fuels DevOps Productivity

    4 Ways SASE Fuels DevOps Productivity

    Many enterprises are adopting secure access service edge (SASE) solutions as part of their digital transformation efforts. SASE, in a nutshell, merges together SD-WAN and security stacks to deliver secure networking and improved WAN performance, making it a logical choice for cloud-enabled businesses going through the throes of digital transformation. However, SASE offers other benefits, which may be of particular interest to DevOps teams.

    Let’s take a look at four ways SASE can enhance the productivity of DevOps teams.

    Reducing Collaboration Challenges

    SASE reduces the challenges associated with team collaboration. SASE, by design, integrates WAN optimization with cybersecurity. Today’s DevOps teams need to work together, despite being physically separated, and must have reliable, secure connectivity amongst the team. “DevOps are all about time-to-market, and DevOps teams are looking for ways to shorten their  CI/CD cycles. A critical part of that process is reducing their dependency on the networking and the security teams,” said Boaz Avigad, director of product marketing, CATO Networks. “Since SASE solutions already provide optimized performance and robust security, DevOps [teams] are free from waiting for infrastructure teams to provision the necessary resources. SASE provides DevOps the control and operational cadence they need without compromising performance or security.”

    SASE Improves Networking

    SASE improves overall network performance with integrated load balancing and failover capabilities. DevOps teams cannot afford to lose connectivity, especially when rolling out new iterations of software or resolving bugs. “For DevOps teams, fast and reliable application performance is critical,” said Avigad. “SASE architectures free DevOps [teams] from worrying about the infrastructure by connecting all the company’s edges, data centers, mobile users and cloud resources, with the same self-healing, secure and fully optimized global network. Should a line fail or a route become congested, SASE automatically switches to an alternate path.”

    Better Security Built In

    SASE helps to secure DevOps projects with native cybersecurity capabilities. When properly implemented, SASE integrates numerous security technologies directly into the network stack. “DevOps teams worry about information interception and protecting their applications from threats. All security services share a single, unified context, improving insight and closing the gaps in legacy security architectures; gaps attackers often exploit,” said Avigad. “SASE not only includes NGFW, IPS, SWG, AV and MDR services, it also converges them together into a single-pass architecture.”

    SASE Removes DevSecOps Burdens

    SASE secures internal applications, along with the interactions with those applications, which in turn helps to reduce the burdens on DevSecOps team members. Applications that run over SASE/SD-WANs are further secured by zero-trust network access (ZTNA) and software-defined perimeter (SDP), technologies that help to keep all interactions between an endpoint and an application secure. “Many proprietary applications are too sensitive to run over the public internet. SASE protects those applications by obfuscating traffic, protecting all entry points with a NGFW and restricting access with its zero-trust architecture,” said Avigad. “All internal application traffic is also continuously inspected for threats.”

    Adopting SASE for DevOps teams is beginning to make a lot of sense. The technology addresses many of the pain points that DevOps teams experience as businesses drive toward digital transformation. What’s more, the security benefits offered bring forth additional productivity, while also unifying the security stack. 

  • Empowering DevOps With Cloud Desktops

    Empowering DevOps With Cloud Desktops

    Today’s organizations need to enable their IT teams to rapidly deploy, manage and maintain their applications and services. This is a primary driver behind the growth in adoption of DevOps. By uniting the IT operations and software development teams, organizations are helping to provide continuous delivery and accelerating the systems development life cycle.

    At the same time, the chronic cyberskills shortage makes it hard for organizations to find the talent they need to hire and collaborate with. The cloud, and specifically cloud desktops, can address many of these challenges and help organizations get the most bang for their buck when it comes to their DevOps teams. In fact, the two technologies have a symbiotic relationship.

    DevOps Hiring Challenges

    Due to the shortage of individuals with key skills, organizations are facing a significant challenge these days as they try to find the right developers. In fact, a recent report by the Linux Foundation and edX finds organizations are searching for more people with open source DevOps skills (65%) than developers (59%) for the first time.

    It is possible, in some instances, to hire remotely, but there are potential snags. For instance, hiring people in another country will likely entail a visa process that can take several months to complete. And collaboration with external project partners can create project bottlenecks that inhibit productivity.

    Once the people you need have been hired, the onboarding process begins. Getting new hires settled in a workflow and procuring and shipping the laptops or workstations they need takes at least a couple more weeks before they can even begin to become productive. But organizations want to be able to hire developers anywhere they can find the right people and they need them to be productive within hours, not weeks or months.

    Collaboration Woes

    DevOps teams cannot function without collaboration, but this, too, can be difficult – particularly if those teams are geographically dispersed. Developer teams have attempted to solve this problem by adopting a variety of technologies, such as legacy VDI solutions, VPNs for remote work, physical workstations connected over a WAN and more. These technologies have helped solve some of the problems, but they’ve also introduced a host of other issues that negatively affect productivity and increase cost and complexity. That includes lack of performance, unreliable user experience, IP security concerns and data management problems.

    Cloud Desktops: A New Approach

    In light of all that isn’t working, it’s clear that a new approach is needed. Cloud desktops offer many advantages when it comes to addressing some of the key challenges DevOps teams face. For one thing, they make onboarding much easier. By using cloud desktops and workstations, all that the new, talented software developer needs is a device and an internet connection, and they instantly become a part of the development team. This resolves another headache that consumes unnecessary IT resources.

    Shipping and hardware preferences are no longer an issue with the cloud desktop model. There is no more shipping, no more maintenance overhead, no more Windows-versus-Mac debates. Now, developers can pick the device they want, depending on their role requirements. They can even use smartphones and tablets in docking stations instead of laptops to connect and work in the fully configured and secure cloud desktops.

    Benefits for Developers and Testers

    Because cloud desktops support multiple desktop images, they are ideal for DevOps teams. For developers, this means that they can have multiple desktops, all with differing versions, all kept separate. This is great news if you don’t want to have to keep reimaging a physical device.

    Giving a developer a persistent desktop is one option that cloud desktops enable. Another option is the ability to give the developer a brand-new, “clean” cloud desktop every day (non-persistent). For enterprises, this means they can control the developers’ IDE so code leaks don’t happen from one release to the next, intellectual property is better protected and they can enforce stronger overall data security.

    Testers benefit as well, as they know they’ll have a totally clean, brand-new cloud desktop every day. This allows them to test and test again in isolation, knowing nothing was left behind from a previous test. In addition, the right cloud desktop enables anytime, anyplace collaboration; geographic limits become a thing of the past.

    Empowering DevOps

    The speed and agility of DevOps have made it a mainstay of software development, but certain criteria must be met for it to succeed. Its premise is faster delivery times, but companies cannot provide continuous delivery if they don’t have the skilled DevOps talent they need. Once they’re recruited and hired, provisioning often takes up more valuable time.

    With the clock ticking, organizations need to select skilled individuals, regardless of their location, and get them working and collaborating as quickly as possible. Cloud desktops address both of these challenges. In addition, they improve the user experience compared to typical VDI solutions – even for compute-heavy users. Cloud desktops increase time-to-productivity, too. As you equip and add to your DevOps team, consider the benefits of adding cloud desktops to the mix.