Category: Blogs

  • DevOps Trends to Watch in 2021

    DevOps Trends to Watch in 2021

    Engineers at fast-paced startups often wear both Dev and DevOps hats. Early in my career, as a developer at a sentiment-analysis startup, I was tasked with writing scripts to spin up servers, configure them, install necessary software and deploy the code we wrote. My custom shell scripts, Python scripts and cron jobs did all the heavy lifting so that we could reliably deploy software and scale resources on AWS. Fast forward to today, and that problem of confidently building and securely deploying software has become an even more enormous challenge at scale.

    The Cloud-Native Application Stack

    A simple looking e-commerce app today can easily be a big set of coordinating microservices that are powered by containers, orchestrated using Kubernetes and hosted on multi-cloud/hybrid cloud. This combination enables faster delivery of code, cheaper hosting bills and more efficient use of server resources.

    While the application components certainly became smaller over time, organizations today are tasked with managing tens of thousands of containers in a production environment. In a 2020 Cloud Native Computing Foundation (CNCF) survey, 92% of respondents said they use containers in production, a 300% increase from just 23% in the first survey from March 2016. Such coordination complexity at scale is being managed by software delivery pipelines. Just as Ford revolutionized the automobile industry with its assembly line, these integrated DevOps products are massively impacting verticals like finance and insurance.

    DevOps Trends

    Trend: Developers are now Decision Makers and Influencers

    We are excited to see the increasing impact and influence of developers when it comes to the selection of tools. The top-down sales motion largely doesn’t work in the cloud-native world, and needs to be supplemented by bottom-up community adoption. The best developers pick peer-recommended tools to solve these tech challenges. Developers today leverage large communities, self-organize and pick the best open source tools to kickstart small projects that have potential to impact the growth curve of any organization. For vendors, developer evangelism becomes an important strategy for customer acquisition.

    Trend: Integrated Software Delivery Pipelines

    CIOs typically pick category-leading products for each category of the DevOps toolchain, like CI, CD, SAST and SCA. Historically speaking, integrating these tools to maintain an effective CI/CD pipeline has been painful and requires stitching together tools using custom scripts. We hear the frustration when we speak with maintainers of such scripts. To address this challenge, we think end-to-end integrated DevOps platforms will become the norm. Such platforms will offer a few best-in-class components with built-in automation, and will enable organizations to integrate other DevOps tools in a plug-and-play manner.

    Trend: Shifting Left with Code

    The shift left phenomena, which enables fixing of bugs/security issues early in the software development life cycle when it is cheapest to do so, is accelerating. By implementing a shared security responsibility model and enabling developers to take more ownership related to infrastructure, security and other critical production issues with code, organizations are shipping code faster and cheaper with less bugs.

    Trend: Low-Code DevOps Automation

    Many workflows are pretty standard in the DevOps world. Go look at an alert in production; prioritize it, look at the knowledge base for a fix, create incident, apply fix, resolve ticket and then repeat. This example is an oversimplification, but there are many repeat use cases that can be automatically managed. These workflows can and should be automated, which can make DevOps teams more effective. We think that customizable low-code automation interfaces will evolve to act as secret weapons for effective DevOps engineers.

    Trend: Security at the Speed of Dev

    Software release cycles a decade ago used to be four to six months long — if not longer — but today, the software delivery life cycle and release cadence is accelerating. The 2019 State of DevOps report suggests that the top performers deploy software 1,460 times per year, which is effectively four deployments per day. Security, compliance, vulnerability management, authentication and authorization all have to move at this speed, otherwise delivery of secure code is just not possible. We see the most innovative CISOs adopt a shared ownership model of security that enables application component owners to detect and fix vulnerabilities. In this shared model, a good balance between agility (so that development is not blocked) and security (so that risk can be managed) needs to be struck.

    Are You Building the Next Big Thing?

    Cloud infrastructure is an enormous opportunity that Gartner expects to grow to $412 billion by 2024 and many enterprises are just getting started. If you haven’t been paying attention, Satya Nadella now runs Microsoft and Andy Jassy will soon run Amazon. Both these leaders are pioneers in cloud, having led Azure at Microsoft and AWS at Amazon, respectively. This shows how much the largest companies, as measured by global market cap, believe in the opportunity related to the cloud. We couldn’t agree more.

  • Languages and DevOps: Mainframe

    Languages and DevOps: Mainframe

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

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

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

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

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

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

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

    So what should you use?

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

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

    And keep rolling.

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

  • How the DevOps Skill Journey Fosters a Learning Culture

    How the DevOps Skill Journey Fosters a Learning Culture

    Human skills, among others, have always been important; now more than ever. Empathy, diversity, creativity, personal commitment have been put to the test. The increase in remote work tends to challenge individuals in unique ways, and these human skills are becoming critical.

    Top 5 Skill Domains for 2021

    This year, 69% of respondents to the Upskilling 2021: Enterprise DevOps Skills Report told DevOps Institute they consider human skills a “must-have or very important” skill for the DevOps human, among other priorities, around skill domains as seen below:

    It is no surprise that challenges around the DevOps journey continue around people, process and technology with all respondents giving them equal weight (33%).

    To continue thriving within DevOps or to initiate a DevOps journey, individuals, leaders and organizations should take action in developing skills across these areas. Right?

    Why, then, are only 39% of respondents reporting they have a formal upskilling program? What is the challenge for the other 61%? Recognizing the importance of these skill domains is one thing – doing something about it seems quite another. Why is so little done about upskilling?

    Can these skills be taught? Well, maybe, or maybe not.

    Research has shown that knowledge and skills can be developed by most people, while abilities, personal capabilities and characteristics are rather innate. Furthermore, existing human capabilities are constructs that facilitate individual learning, adaptability and development and maintain their value even when drastic environmental changes occur.

    When we asked how organizations are prioritizing human skills during our research, we found that the human capability or domain is among the top five must-have skill domains. We also found that organizations have adopted both the concept of the learning organization and safety culture as two important constructs for DevOps.

    3 Things to Understand about Human or “Soft” Skills

    1. The human skill or domain is fundamentally different. While technical skills – such as container orchestration, CI/CD automation technologies and cloud infrastructures – can be developed through training (and these skills can be certified), the human skill domain is somewhat different. First, some human skills are shaped through experience and practice in both our personal and work life. For example, collaboration and communication skills are shaped during projects and can be adjusted according to the culture of the organization. Other skills, such as curiosity, might have been developed during early life stages or are somewhat innate.
    2. Take inventory of your top human skills. Our survey respondents offered great insight on the top must-have human skills within DevOps. Every situation, however, is different, but take a look at these and do a self-check on your human skills.
    3. Human skill development requires coaching and continuous feedback. No matter what methodologies organizations leverage, one key aspect is that individuals and leaders alike should have a coach or mentor who provides guidance and support. And, just as important is continuous feedback around an individual’s personal development. Today’s human resources teams might be able to assist. If not, network with others which might already model the skills needed and that can provide support and guidance.

    Must-Have Human Skills According to the C-Suite

    The graph below shows executives, management and individual contributors all have similar priorities when it comes to human skills. (Blue is executives and management, and orange are individual contributors)

    C-suite Human Skills

    There are some differences in opinion when it comes to multitasking, customer skills, thought leadership, business understanding, creativity, diversity and inclusion, empathy, personal value, communication, interpersonal skills, sharing and knowledge transfer.

    How does one identify an individual’s potential for soft skills and other skill development? Unfortunately, this is not an exact science. One possibility is to understand what DevOps capabilities are needed, first, and then perform a skills inventory check. Then, the question becomes, how can you encourage individuals to develop their skills?

    The Skill Journey Toward a Learning Organization

    A learning organization is composed of individuals and leaders all interested in increasing their capabilities and improving their skills to achieve results they care about. Learning how to do something is extremely rewarding, and, at the same time, achieves specific organizational goals if the learning is aligned to the needed capabilities.

    First, assessing what DevOps capabilities are missing, paired with a skill path for the DevOps team members, is a win-win.

    DevOps human skills

    5 Tips for Your DevOps Journey

    1. Make continuous learning part of the DevOps journey. Continuous learning and education must be a fundamental best practice within your DevOps journey. A first step is always education, providing learning resources and allowing engineers and individuals to participate with and learn from others in the community.
    2. Don’t hide the experts. Another critical step is determining if subject matter experts are being sheltered or siloed away. Instead, learn how to embed those people within teams, so they can spread their subject matter expertise by osmosis to others on the team.
    3. Growth of skills requires time and budget. According to Jayne Groll, “Enterprises should take intentional steps to support the growth of their DevOps humans.” Some may assume that engineers learn organically, but in truth, engineers need time and budgeted resources to develop new skills, hone existing skills, experiment and improve their capabilities. This could be in the form of time to attend a virtual conference, go to a training class, practice in a sandbox and/or doing peer-to-peer mentoring. Just take a look at site reliability engineers, for example, which are tasked with spending half of their time “making tomorrow better than today” by reducing toil through automation. DevOps engineers should be allotted a similar amount of time to do the same.
    4. Adopt a buddy system. The adoption of a coach or buddy system to further aid individual learning and growth is an excellent idea; pair less-skilled DevOps humans and engineers with highly skilled and experienced ones, and watch growth happen. This helps growth on both sides – both for the experienced buddy and the less-experienced person, in learning and teaching.
    5. Equip your leaders. Leaders are expected to know how to do things, right? To have all the answers? Well, not really. Some research has shown that the largest group of leaders today are “accidental leaders,” and 60% of frontline leaders say they have never received any training for their new role. Leaders need to learn and upskill, as well.

    The challenges of the past year showcased the importance of human skills in transformational efforts. Without the spirit, willingness, collaboration, cooperation and competencies of IT professionals around the world, many enterprises would not have been able to adapt to rapidly changing business models in a pandemic-fueled economy. As we continue into this next decade, organizations should plan to invest in upskilling their humans as much (or even more) than their technology.

  • The Human Side of DevOps – Upskilling for the Digital Transformation

    The Human Side of DevOps – Upskilling for the Digital Transformation

    Roundtable 8: DevOps is all about people, process and tools. People, or humans, are critical to DevOps success. Just as we invest in tools and build processes, software leaders recognize it is vital to invest in DevOps skills for their people and software teams.

  • Redis Labs Extends Reach of In-Memory Database

    Redis Labs Extends Reach of In-Memory Database

    At its online RedisConf 2021 event, Redis Labs today detailed how the company’s in-memory database will be employed to drive real-time applications that are at the core of most digital business transformation initiatives.

    Yiftach Shoolman, Redis Labs CTO and co-founder, said there are four initiatives at the core of the Redis Labs effort to replace legacy databases that organizations have historically employed to drive batch-oriented application processes.

    RedisRaft, which will become available with release 7.0 of the Redis database in the third quarter, provides a module based on the Raft consensus algorithm that enable multiple Redis servers to be consumed by an application as if they were one single, fault-tolerant, logical cluster. That capability will provide IT teams with the ability to distribute Redis servers closer to the point where data is being consumed by a distributed application without incurring any conflicts between databases, said Shoolman.

    At the same time, Redis is extending its Active-Active technology to enable integrated data models to be deployed in a way that allows distributed applications to run as close as possible to the point where data is being created and consumed.

    Finally, RediSearch is being updated to include support for indexing capabilities in JSON applications using a nested document model, while a RedisAI capability will add an inference engine for artificial intelligence (AI) applications that can be employed as a feature store through which the deployment of AI models within applications can be managed. That approach also promises to significantly increase the overall performance of AI applications, noted Shoolman.

    Historically, the Redis in-memory database has been best known for the caching capabilities it provides developers. However, Shoolman noted 66% of organizations that employ the Redis database are using it for additional use cases. As microservices that are often configured with their own database become more prevalent, the adoption of an in-memory database platform should only increase, added Shoolman.

    Many of those microservices are being employed within the context of a digital business transformation project. The issue that organizations are coming to terms with is most of those processes need to run in near real-time. That requirement will eventually push more organizations toward deploying a database based on a distributed database running in-memory that appears as one logical entity to an application, said Shoolman.

    At its core, Redis a data store that supports structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. Among other capabilities, it includes support for built-in replication, Lua scripting, transactions and varying levels of persistence. The company claims the core Redis datastore has been downloaded 1.5 million times in the last nine years.

    On top of that installed base, Redis Labs then makes available tools for deploying and managing Redis within large-scale application environments. Most recently, Redis Labs raised an additional $100 million round of financing to bring its valuation to above $2 billion. The company now claims to have more than 8,000 paying customers, with a 54% compound annual growth rate in sales for the past three years.

    It’s hard to say to what degree Redis data stores might supplant legacy database platforms. However, the one thing that is certain is there are lot more databases running in memory that, in many cases, obviate the need for a traditional relational database.

  • Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi announced today it is expanding the scope of its automation ambitions to make it easier to securely provision cloud infrastructure-as-code.

    Joe Duffy, Pulumi CEO, said the Cloud Engineering Platform enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning in a way that can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice, Duffy noted.

    The Cloud Engineering Platform is now generally available on the Microsoft Azure cloud, while a preview edition of the offering is available on Google Cloud Platform. Support for Amazon Web Services (AWS) is planned for later this year.

    The platform itself is based on version 3.0 of Pulumi, an open source tool that developers have previously employed to manage infrastructure-as-code. Pulumi is also making generally available a tool for integrating its tools with more than a dozen continuous integration/continuously delivery (CI/ CD) platforms.

    That capability, coupled with existing support for integrated testing capabilities and the tools for managing compliance-as-code based on identities, provides IT teams with a more comprehensive approach to managing infrastructure-as-code, said Duffy.

    Most cloud resources today are directly provisioned by developers using open source tools such as Terraform. The issue that organizations have encountered is that developers are prone to making configuration mistakes that cybercriminals then exploit. Pulumi is making a case for an alternative approach to provisioning infrastructure-as-code that makes it easier to validate configurations using testing tools, while at the same time limiting who can access infrastructure resources by including support for the secure access markup language (SAML) and single sign-on (SSO) capabilities.

    It’s not clear at what rate enterprise IT organizations will be shifting toward platforms that enable infrastructure to be managed as code in a more robust fashion. Developers that don’t always have the greatest appreciation for cloud security issues routinely employ tools such as Terraform to provision infrastructure-as-code with little to no supervision. Cloud resource misconfigurations often result in ports left wide open, and cybercriminals now make use of tools to scan for those types of misconfigurations.

    Pulumi Packages provides a means for IT teams to exercise more control over the provisioning process, using vetted reusable components in a way that doesn’t compromise the rate at which developers can spin up cloud resources, noted Duffy.

    As organizations focus more on software supply chains in the wake of some recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security doesn’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Many developers assume the cloud service provider is securing configurations, only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

    Hopefully, there will come a day when DevSecOps best practices leverage automation to resolve this issue once and for all. The challenge is finding the best way to achieve that goal in a way the average developer will accept and embrace.

  • AI Reimagines Computation and Improves Software Development

    AI Reimagines Computation and Improves Software Development

    While modern business software solutions unlock organizational efficiencies, agility and the ability to deliver new value to customers, such tools were not available when applications deployed on mainframe systems were being developed.

    Today, many of the Fortune 500 companies, the world’s largest banks and insurance companies and several of the largest retailers in the U.S. continue to rely on legacy programming languages, such as COBOL or Java, to power their applications. However, with new languages coming on the scene and experienced programmers in legacy languages exiting the workforce, organizations find themselves in an increasingly difficult spot.

    Is it a Coding Skills Shortage or a Knowledge Gap?

    As proficient programmers retire or move on, organizations across industries are recognizing they no longer have the specialized domain knowledge of the industry and institution to effectively maintain and support their complex critical systems. To combat what is perceived as a skills shortage, organizations are sinking a significant amount of effort into hiring new developers, teaching them to write in the legacy languages and tasking them with changing enterprise systems.

    Modernizing applications, databases and systems that run well in their current state can be risky and expensive, so building on top of and around existing code can be the better choice. But such workarounds are not always completed in the most appropriate manner. For example, when a developer is cutting and pasting large chunks of code just to change one behavior, the end result is often awkward and unmanageable applications that even the most accomplished developers struggle to deconstruct and understand.

    Understanding the code is not enough. Developers have to know what an application actually does, but if they don’t recognize how altering code in one part of a system impacts another part, the consequences can be devastating. As such, the challenge is not a skills problem — most programming languages are straightforward enough to learn — it’s a knowledge problem that exists across programming languages.

    Goodbye, Years of Language-Specific Experience. Hello, AI.

    The programmers who wrote all those billions of lines of code are still running mission-critical applications, but they are increasingly aging out of the workforce or opting for a new or different career path. This results in legacy systems being less well-understood by the companies that rely on them every day. While many programming languages are meant to be easy to read and understand, unknotting the program logic frequently devolves into a tedious reverse-engineering project in which developers are attempting to unearth the intent of previous developers encoded in the software.

    Rather than relying on aging subject-matter experts to pass along that specialized knowledge to programmers fresh out of college (who are in short supply anyway), organizations might consider leveraging advanced artificial intelligence (AI) tools to automate the process of identifying the specific code that requires attention — no matter how entangled that code is throughout the system.

    While AI can be used to help with the syntactical issues of writing code (much like the Smart Compose feature leverages machine learning to “look ahead” and offer suggestions as you type), the impact of such tools is minimal. AI’s greatest time-saving opportunity lies in automating developers’ steps when conceptualizing and writing code. Whatever the reason — be it poor documentation or spaghetti code — developers spend about 75% of their time in search of the source code that needs to be changed. That source code is likely to be interspersed throughout the code repository, requiring a developer to “think through” what the code does, at nearly every step, to trace out the code detailing the behavior that they seek to modify.

    How AI Overcomes the Inadequacies of Automated Testing

    The goal of many organizations is making changes to systems running older programming languages as safely and efficiently as possible. Some organizations are turning to DevOps to improve agility and accuracy without sacrificing their existing mainframe system’s stability and performance. When it comes to COBOL code, where the problem is more acute than in other languages, automated testing in the CI/CD pipeline is inherently inadequate.

    Once a developer has identified the code representing a behavior that needs to be changed, they’re in a position, in that automated pipeline, to ensure that the corrected behavior never changes. However, because the code describing the behavior in question can be spread throughout the system, a developer will make a change believing they haven’t altered any other behavior, but they may have actually ‘broken the world.’ System-breaking changes can be made to the code -and stay hidden – because testing may not cover scenarios that the developer didn’t consider. Well-constructed automated test suites are data-dependent, but assembling all of the data necessary to get 100% code coverage is, unfortunately, next to impossible.

    If, for example, the application required a security or regulatory change, a developer might think that their correction will be covered by the automated test suite when it’s not. Without copious data in the suite, developers cannot guarantee that a behavior will never be altered. With AI “reimagining” computation as conceptual, developers are able to validate that they haven’t broken the system before they compile or check-in the code — or even run it in debug mode to check it — before running the automated test suite. Once developers are confident their change is isolated, the “conceptual check” of the behavior may be leveraged in the CI/CD pipeline, thereby ensuring the behavior remains intact from that point forward.

    In short, advanced AI makes developers’ lives easier because AI can automatically analyze source code and understand the human intent behind it. Now, developers can collaborate with AI to locate source code in an effortless manner, quickly perform comprehensive impact analysis and make the necessary change(s) without ‘breaking the world.’ The improved productivity and efficiency AI unlocks is critical in maintaining and improving the important legacy and mainframe systems that handle tens of billions of business transactions every single day.

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