Category: DevOps Culture

  • The Next Phase of Pandemic Tech Transformation

    The Next Phase of Pandemic Tech Transformation

    Last spring, we were inundated with headlines, tweets and Medium posts applauding the rapid digital transformation that businesses were going through—almost overnight—due to the pandemic and the shift to remote work. It made for an interesting feel-good narrative at the time, but it didn’t paint the full picture. Companies were thrown into the deep end; many barely staying afloat by implementing quick-fix, surface-level changes that they assumed would only be needed for a short time. Turns out, the “transformation” touted was just the tip of the iceberg.

    More than a year later, the workforce is still in flux. The reality is, some form of distributed, hybrid work is likely here to stay. Employees will continue to expect remote options and customers will want seamless, digital ways to interact with businesses, pandemic or not.

    As a result, companies must move past the temporary, band-aid solutions of last year and make those sweeping changes permanent. It’s time to move forward with true, sustainable change: Technical, experiential and, most importantly, cultural. Every company will need to become a modern technology company capable of delivering first-class digital solutions to customers, partners and employees—or risk becoming obsolete.

    Transactional Vs. Transformational Change

    The good news is just about every company understands the value of leveraging technology. A recent 2021 State of the CIO survey found that 82% of CIOs said they implemented new technologies, new IT strategies and/or new methodologies over the past year. The issue is how companies go about their technology deployments.

    People talk about digital transformation all the time, but it’s been used so much that it has become an unhelpful misnomer. More often than not, the change that companies are implementing isn’t truly transformational, but rather transactional or just slightly incremental.

    When companies have a transactional mindset, the focus is on immediate, simple and predictable changes. The purpose—or, more importantly, the outcome—is simply to continue business-as-usual. This is reminiscent of many companies last year turning to technology just to keep the lights on. A transformational mindset, on the other hand, aims to disrupt this business-as-usual and fundamentally change the paradigm in how the company operates through ways of working, use of technology and culture. It’s purposeful, aiming to solve business problems holistically and spur long-term growth.

    To be successful in today’s climate and to gain a competitive edge with customers, companies must strive to be transformation-focused.

    How to Move Toward True Transformation

    Here are three examples of how companies can shift from a transactional mindset to a transformational mindset.

    Cloud Migration vs. Modernization

    Often, when companies talk about their use of cloud, they tout that they’ve “moved to the cloud.” But all too often, it’s treated as a one-time event; a destination to reach and a box to check. At the outset of the pandemic, we saw so many organizations quickly mobilize to shore up their digital strategies and ensure they were thinking about the limitations of doing business in a virtual context, but their cloud strategies didn’t evolve to rethink these paradigms, as well. They simply accelerated their migration strategies to get out of their physical data centers and into the cloud.

    The opportunity to leverage the cloud is so much bigger than that. It can unlock greater efficiency, flexibility and growth and underpin new digital experiences and revenue opportunities—exactly the kind of strategies most companies envision. For example, health care leader InnoCare was struggling with outdated clinic management software. Instead of just moving the old bits to their cloud provider, they adopted a broader digital strategy to modernize their delivery capabilities and reimagine both the patient and clinician experience, setting new industry standards in the process. This is what we refer to as modernization and it is what leads to transformation.

    Software Engineering vs. Product Engineering

    With the rapid growth of software, it’s no surprise that software engineers are in high demand. The U.S. Bureau of Labor Statistics projects that software engineering job openings will grow 22% through 2029. And while software engineers will play an irreplaceable role in helping build innovative solutions, transformational-focused companies know to bring more people under the tent. By combining software engineers with other cross-functional experts who bring a different level of artistry, design and audience understanding, the end result is a more engaging, customer-centric product that evolves and grows over the entirety of its useful lifespan.

    This is exactly what fitness giant Nautilus did. They brought together a team of engineers, data scientists and machine learning experts to help bridge the gap between their equipment manufacturing prowess and their digital experience and software development goals. Collectively, they produced a total platform that integrated hardware, software and data to create a dynamic workout regimen that impressed users and fended off competitors.

    Moving Beyond Proof-of-Concept to Long-Term ROI

    A proof-of-concept (POC) is a rite of passage in the tech world. It’s how a company or team demonstrates that their idea is feasible and can work in a real-world application. But POCs alone are insufficient; they are transaction-minded and don’t focus on achieving lasting business outcomes or generating deeper ROI. Rather, they mostly focus on technical feasibility. The key to upleveling toward transformation is by focusing on the processes, not just the end product. When testing features in a real-world setting, make sure that you’re proactively measuring not just that they work—but that they contribute to business imperatives, meet customer expectations and strategic outcomes. And if they don’t, go back to the drawing board and optimize with those higher-level goals in mind.

    Culture is Key

    As you can see, the difference between a transactional and transformational mindset is more about culture than technology. A culture of innovation and modern ways of working leads to transformation that fundamentally shifts the way technology is conceptualized and created. It isn’t solely about gaining efficiencies or cutting costs—instead, the focus is on making the lives of customers, employees and everyday users better. Transformation-focused companies believe in the promise of technology advancements, but they believe that it also can make operations smoother, customer relationships more meaningful and increase revenue when implemented with the right combination of skills, disciplines and organizational buy-in over time. It’s those companies who will thrive in this new era.

  • The Key Benefits of Observability for SREs

    The Key Benefits of Observability for SREs

    In today’s technology landscape, organizations strive to champion innovative ideas, techniques and technologies to achieve success and outshine their competitors. For this reason, site reliability engineering (SRE) has become one of the fastest-growing enterprise roles and a set of organizational practices for fast and reliable software delivery. 

    SREs use various tools and practices at their disposal to manage services at scale, such as observability. Observability is the ability to infer a system’s internal state(s). It provides actionable insights into when errors occur within a system and, more importantly, why they occur. For SREs, this actionable data can be important to providing secure and reliable applications. 

    To gain more insights into the benefits of observability for SREs, I asked SKILup Day participants and DevOps Institute Ambassadors to weigh in. Here’s what they shared: 

    Sponsor, Priya Satheesh, CEO, Instana 

    “As their name implies, site reliability engineers are tasked with keeping the applications, architectures and websites up and available. Observability solutions put alerts in front of them at the first indications of trouble, with proper context and information so they can take action before issues become incidents and start affecting their customers. In addition, AIOps and machine learning help them to predict events and standardize responses for common occurrences to reduce response and repair times.”

    Helen Beal, chief ambassador, DevOps Institute 

    “Embracing observability supports SREs’ goals by:

    • Reducing the toil associated with incident management—particularly around cause analysis—improving uptime and MTTR.
    • Providing a platform for inspecting and adapting according to SLOs and ultimately improving teams’ ability to meet them.
    • Offering a potential solution to improve when SLOs are not met and error budgets are overspent.
    • Relieving team cognitive load when dealing with vast amounts of data–reducing burnout.
    • Releasing humans and teams from toil while improving productivity, innovation and the flow and delivery of value.
    • Supporting multifunctional, autonomous teams and the ‘We build it, we own it,’ DevOps mantra.
    • Completing the value stream cycle by providing insights around value outcomes that can be fed back into the innovation phase.”

    Mark Peters, technical lead, Novetta

    “True system observability means any process or event within any operational or development phase can be monitored by SREs. Systems with built-in observability provide SREs, as subject matter experts, the opportunity to examine events from different perspectives. The more observable the system, the more different places can be examined to help improve the overall flow. SREs can then create the feedback and design experiments to observe from different perspectives. If the event is showing functional difficulties and the only monitoring point is the input/output of the function and there is no process observability, SREs have to go back to the beginning to find events. If they can observe the entire process chain from commit to deployment, one can find the different areas. Think about the A/B cycle: Limited deployments are planned, and the load shifted gradually to ensure the new system can handle the increased functions. If the SRE cannot observe the function, then they cannot help improve reliability.”

    Ryan Sheldrake, field CTO, Lacework 

    “If you can ‘see’ or observe the complex and ever-changing environments that SREs are tasked with managing, creating and perhaps destroying, you can manage the associated risk posture associated with those environments and corresponding workload.“

    Vishnu Vasudevan, head of product engineering and development, Opsera

    “The top benefit for site reliability engineering (SRE) teams is the opportunity to work collaboratively with the business stakeholders and technology stakeholders to set goals and continuously improve. Based on these goals, SRE’s can create an approval process, which will help them understand where they are with respect to their own planning, security policies, quality metrics and operations practices. The ability to measure every release and verify the project helps improve speed to market and other factors once a robust observability practice is achieved. With DevOps orchestration across all the DevOps tools, applications being released and the different teams involved, SRE teams can then turn observability practices into a competitive advantage.”

    Sushant Mehta, senior manager, application development, Diyar United Company

    “Using observability, SREs can achieve a number of objectives in their day-to-day work, like identifying the root cause of production issues, faster resolution of issues and striving for self-healing infrastructure setup with no-code.”

    Tiffany Jachja, engineering manager, Vox Media

    “Every team that delivers software should be taking responsibility for their contributions to a software service. For SREs, having observability into an application means having the systems in place to help developers gain insights into how software applications function. Ultimately, it’s about building better software.”

    Parveen Arora, co-founder and director, VVnT SeQuor

    “SREs teams can leverage observability to get the following benefits:

    • To keep SLOs intact by detecting customer-affecting issues faster and rolling back before an issue affects the SLOs.
    • To have real-time health updates and transparency of information with regard to a service’s status. 
    • To create better workflows for debugging, optimizing workflows and resolving issues rapidly.
    • To simplify root cause analysis and investigation of hypotheses.”

    Jose Adan Ortiz, solutions engineer, Akamai Technologies

    “SREs are mainly concerned with the reliability of systems and usually monitor practices of toil, SLO, error, budget and stability to maintain systems working as expected.

    You could ask, ‘How can an SRE achieve such an integrated view of all systems components?’ The answer is observability. Without observability tools, it was impossible for an SRE to provide an effective response, fast RCA and analysis of data to improve SLOs.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “It can provide several advantages, including:

    • Detecting customer-impacting errors faster and reverting before SLOs are broken.
    • Fostering transparency and delivering real-time updates on the status of a service. This allows SREs to be more productive and saves a lot of time.
    • Developing better methods for debugging, optimizing and quickly addressing issues.
    • Allows for feedback loops, which are crucial in the SRE role.
    • To avoid downtime, the relevance of observability rises in real-world production systems. There should be proper notification processes in place.”

    Maciek Jarosz, DevOps and process expert

    “The benefits are quite great, I’d say. Unless one is living under a rock with one local system, then it’s rather inevitable that there will be dependencies here and there. And if you’re an SRE, then I’d say that you’d rather know a bit more about dependencies from other branches of your system—or other systems altogether—than less.

    Learn more about observability and similar topics by registering for an upcoming SKILup Day. 

  • DevOps World 2021: 3 Sessions for Successful Scaling

    DevOps World 2021: 3 Sessions for Successful Scaling

    Your business has grown from a startup of five people to a full-blown organization of 100 … congrats! But, now what? The practices that worked for a smaller company may have worked as you first started growing, but now it’s time to scale operations to fit your new needs. Just like a kid outgrowing their clothes, your organization needs a new “wardrobe,” and scalability is key for long-term success.

    This year’s virtual conference—scheduled for Sept. 28-30—will offer a number of breakout sessions, panels and keynotes focused on scalability within enterprises. If you’re ready to scale within your business, here are a few sessions from this year’s conference to help get you started.

    From Startup To Enterprise—Sustainably Scaling

    Many organizations struggle to scale DevOps culture as they grow. Now it’s time to say goodbye to the startup phase and hello to thinking like an enterprise.

    Alston Rousseau, director of software delivery at Campspot and Kailene Cloud, director of talent acquisition at Bonusly, will walk attendees through the investment needed to sustainably scale operations, development and culture. Plus, they will share tips for finding more value in existing commitments to money spending, time and diversity in DevOps and how this approach applies to organizations with and without high compliance requirements.

    Scaling up Car Configuration: From a Statically Hosted Front End to Universally Rendered Services

    Over the past year, tech company Code Orange made the transition from a traditional API/SPA split to a much more technically challenging server-rendered SPA with full cache handover.

    In this breakout session led by Niels Hoiting, a developer at Code Orange, attendees will learn more about Code Orange’s transition from API/SPA split to server-rendered SPA while analyzing the pitfalls that can arise in the transition and how to optimize compute spend to best handle a specific workload.

    Leveraging CloudBees to Scale Satellite Ground System Emulation in Multifaceted Virtual Environments

    Aerospace and defense technology manufacturer Raytheon Technologies has successfully implemented CI/CD pipelines for the test and near-operational integration of both software and hardware for a global satellite ground system.

    In this breakout session led by Casey Jackman, deputy of GPS Product Factory at Raytheon, attendees will discover how Raytheon uses simulated satellite control stations in virtual private clouds for CI, test and check-out. Additionally, Casey will share how the team met challenges in initial pipeline generation between multiple disparate target environments with AWS and on-premise data centers.

    Think it’s time to scale your organization? Register now for DevOps World 2021 to get started.

  • Avoid Security Apathy with DevSecOps

    Avoid Security Apathy with DevSecOps

    Against the backdrop of rapid digital transformation accelerated by the pandemic, every industry has seen an increase in high-level cybersecurity breaches. As organizations continue to support distributed and remote work, organizations must address the risk of incomplete security policies and procedures resulting in exposure to IT risk of all kinds. SolarWinds recently revealed findings of its SolarWinds IT Trends Report 2021: Building a Secure Future, which analyzes the degree to which organizations are prepared to manage, mitigate and prevent risk in the future.

    Measuring Risk

    The survey found 46% of tech pro respondents admitted to having medium exposure to enterprise IT risk over the past 12 months. The level of perceived risk differs by size of the organization, where a sense of high or extremely high-risk exposure is perceived at enterprise organizations (19%) compared to their small business (11%) and mid-sized business (7%) counterparts. With the rise of high-level cybersecurity breaches this past year, this is a concerning reality for security within enterprises.

    However, the findings highlight a possible disconnect—although enterprise IT risk exists within their organizations, tech pro respondents are confident in their risk management and mitigation preparedness strategies. In fact, 73% of tech pro respondents “agree” or “strongly agree” their IT organization is prepared to manage, mitigate and resolve risk factor-related issues due to the policies and/or procedures they already have in place.

    How to Avoid Security Apathy

    As a tech pro, it’s easy to think of security as an afterthought or to expect ownership to fall solely on the shoulders of a dedicated security team. This is especially true for tech pros who have been with a company for a long time and are resistant to change.

    As we emerge from the pandemic, those continued perceptions reflect apathy and complacency when it comes to security and will only increase their business’ level of risk. They’ll be more apt to limit exposure to new technologies, ignore better ways of working, or worse continue to be oblivious to other areas of less obvious risk within an organization. Something needs to change.

    Tech pros must shift their mindset and accept security as one of their responsibilities. To start this process, IT teams must examine current processes from the outside in and apply rigor when evaluating solutions. Since it’s common to be bombarded with marketing messages, this means spending time verifying a tool or solution’s functions and capabilities to help separate fact from fiction.

    Next, tech pros must focus on providing complete visibility into all systems to identify areas of risk and opportunity. Even small adjustments, like speedier upgrades and patches, the adoption of password managers and multi-factor authentication (MFA) solutions can help improve an organization’s overall security posture.

    Most important of all, tech pros should be continuously assessing their risk management, mitigation, and protocols to avoid complacency and becoming “blind” to risk.

    After a year of “crisis mode” induced by the pandemic, it’s easy to be complacent and sidestep the responsibility of risk assessment and aversion. As the security landscape continues to evolve, tech pros must remain vigilant and deploy solutions that provide better visibility into systems to identify risk and opportunity. This year’s study reveals the opportunity ahead for tech pros and IT leadership to align on priorities and policies that can best position not only individual organizations but the industry at large to succeed in managing, mitigating and preventing risk in the future.

  • How to Successfully Scale Agile

    How to Successfully Scale Agile

    Agile has proved its value to businesses across industries and geographies. In fact, the pandemic elevated it to an absolute necessity for organizations’ success and survival. Business leaders around the world invested aggressively in Agile transformation as they scrambled to meet changing customer demands through newly hybrid and remote workforces. Not surprisingly, the faster they adopted Agile methodologies at scale, the higher the value it delivered for them. Research indicates that the value Agile delivers can be a chance to grow ahead of peers as high as 63%.

    What enterprises in the U.S. now need is to move the right Agile levers to maximize business outcomes. The same research prescribes an agenda to make that happen:

    Mapping Customer Journeys

    This involves assessing what purpose the company’s offering serves and how value flows through the systems that surround it to the customer. By identifying the critical path of value flow and prioritizing Agile investments at the nodes of value, both volume and velocity of value to customers can be impacted. For example, at Marcus by Goldman Sachs, every team, no matter which department they belong to, responds to the question about what they do with an answer that has clear customer focus: Enabling customer onboarding, improving the customer service experience or helping with the customer password journey.

    Using Customer Insights

    This can be achieved through A-B testing techniques and analytics platforms to unearth the attitudes and motivations that cause customer churn, build loyalty and convert emotions to action. This involves gathering customer feedback through surveys, discussions, and, in the case of digital channels, insight from the channel itself. Additionally, this lever enables diverse perspectives as customers are onboarded, with inputs all the way from design to operations. Kraft Heinz, as an example, leverages Snowflake’s platform to leverage data to drive new digital experiences for consumers. Snowflake gives them real-time ability to sense, respond and evolve, with insights resulting in more meaningful interactions with customers.

    Organizing Teams Around Offerings Rather Than Functions

    This involves bringing together skills and capabilities to launch disruptive products in the market and win back market share. Product-centric agile value delivery is especially helpful in scenarios that involve multiple handovers between internal teams that could lead to delays and siloed developments. For instance, Daimler draws on the principles of swarm to pull in expertise from various departments and create cross-functional teams to collaborate when developing new products.

    Upskilling the Workforce

    It’s imperative for organizations to upskill their workforce for continuous delivery, strategic vision and skill alignment within autonomous, cross-functional teams. The rapid pace of development required to meet changing customer needs often creates a skills gap that needs to be bridged. Siemens is a great example. They accelerated their digital transformation journey in 2020 and realized how vital it is for every employee to easily access upskilling and reskilling opportunities. To stay ahead of the curve, they deployed an agile digital learning platform for their employees while leveraging and simplifying their existing learning ecosystem.

    Taking the Minimum Viable Product (MVP) Approach

    This lever assesses real value delivery, validates hypotheses and enables quick course correction as required. Budgets are always limited, and an agile MVP approach also maximizes investment value with faster delivery, optimized processes and increased flexibility. A recent case in point is the approach bp took when started work on an integrated energy-as-a-service (EaaS) offering that will provide end-to-end management of a customers’ energy assets and services. Their first step was to pilot the plan in an innovation center/work campus before exploring opportunities to manage energy more broadly at industrial and business parks.

    Expanding the Agile Workplace

    Companies need to extend and adapt the agile workplace concept for a hybrid reality by creating remote analogs for meetings, sales execution and IT support along with advanced collaboration tools. A great example is GE Appliances; at the very start of the pandemic they accelerated their workplace with automation-driven agile services support across their global command centers and service desks.

    Amplify Agile with Cloud

    Scaling Agile without sound cloud infrastructure is a good job half done, especially when firms want to buttress speed and utility with business resilience. In fact, the very best firms stand to take a good share of the $414 billion in profits cloud generates across industries and regions every year.

  • Majority of Software Engineers Want Remote Work Options

    Majority of Software Engineers Want Remote Work Options

    The pandemic brought unprecedented change to the digital ecosystem, impacting users, companies and software engineers alike. COVID-19 accelerated ongoing digital transformation and forced many organizations to innovate rapidly. Newfound reliance on digital experiences increased demand for software programmers, exacerbating demand in a market already short on talent. In this era, work-from-home (WFH) became commonplace and most engineers moved toward full-time remote work positions.

    Having had a taste of freedom from corporate settings, most developers now want remote work options in a post-pandemic future. A significant amount also desires to work 100% remotely. As a result, many companies have instituted permanent work-from-home policies. Yet, they are still grappling with the repercussions of a fully remote workforce. For example, there are differences of opinion about whether to adopt location-based salary adjustments and whether or not those remote workers should be granted unique employee benefits.

    The 2021 State of Remote Engineering Report, conducted by Terminal, surveyed 1,100 software engineers in North America and explores how the pandemic has affected the remote developer workforce; showcasing both the positive and negative effects of remote work on engineers. Interestingly, the report exposes international talent’s declining interest in physically moving to the U.S. as domestic conditions worsen and remote work becomes more globally accessible. Below, we’ll explore the key takeaways from the study to posit how this new normal is influencing the productivity, morale and recruitment of software engineers in North America.

    The New Normal: Remote Work

    The new normal has dramatically shifted the status quo. Impressively, findings show that 86% of engineers are currently working 100% remotely. This is in stark contrast to the pre-pandemic numbers, which showed 19% working remotely 100% of the time. Many of these employees prefer to keep these new working arrangements and standards in place going forward. The study found that 80% of engineers surveyed want options for working from both home and the office, and one out of three want to work remotely 100% of the time.

    There are many reasons why engineers prefer the flexibility of remote work to the traditional workplace. For one, there is no need to commute, thus saving time and energy. Engineers also cite an improved work-life balance and appreciate the increased autonomy. It also appears that many organizations handled the shift to remote work effectively—74% of engineers say their companies adapted well to remote work. Due to these positive results, 76% of engineers would be happy working fully remote 60% of the time or more.

    Remote work not only benefits software engineers but could also bring productivity enhancements to help achieve business goals. Without workplace distractions, 70% of engineers surveyed reported they are more productive when working from home. Yet, this new normal isn’t without its drawbacks. As the traditional corporate firewall diminishes, CISOs struggle with a dilemma: striking an ideal balance between granting new IT freedom and locking down systems and restricting access to adopt a zero-trust mindset.

    Issues With the Pandemic and Remote Work

    Of course, there are some other drawbacks associated with full-time remote work. A lack of day-to-day interaction with coworkers is a challenge cited by 58% of participants in this study. For 39% of engineers, it’s harder to collaborate or feel part of a team in this new dynamic. Burnout or lack of motivation and home-based distractions can also be barriers for remote-working engineers. The loneliness of at-home work can take its toll; 38% say their mental health has gotten worse amid the pandemic.

    Companies also face challenges recruiting within this new paradigm. The talent shortage remains a big issue for many companies trying to rapidly deliver new software; 64% of engineers say there is a software engineer shortage and 65% say this gap holds back technical development. Though there is a clear skills gap, most companies are not offering adequate benefits coverage to entice full-time workers. Of these benefits, 23% of engineers would like a home office stipend for utilities, internet and other expenses; 22% also want more flexible work hours and 11% desire new technology and productivity tools. And 26% of engineers also ranked support for mental health as one of their top three sought-after benefits.

    The report also addresses some inefficiencies associated with hiring engineers for remote positions. For 59% of engineers surveyed, recruitment involves far too many interviews. Many of us working in IT can likely attest to being approached by LinkedIn scouts with irrelevant offers. As such, 40% of engineers say they are often interviewed by people who don’t understand the technology. Other recruitment issues include generic interviews and long delays, both of which could frustrate candidates. It appears companies must fix their hiring practices or risk losing potential talent.

    The Era of Employee Choice

    If anything, the State of Remote Engineering report drives home the imperative to consider full-time remote work as a viable option for prospective hirees. To fill engineering labor shortages, some U.S.-based companies have historically flown in international talent. Yet, the desire to move to work in the U.S. is declining. In fact, 39% of engineers have no interest in moving to the U.S. for a job. Engineers cite crazy politics (56%), gun violence and safety concerns (55%), racism (47%) and mishandling of the coronavirus (51%) as reasons not to move to the U.S. The idea that employees must remain in physical proximity with a company’s headquarters is changing; thus, companies will have to go where the existing talent already lives.

    In addition, today, engineers have more bargaining rights than they did in the past. “The era of employee choice is here,” said Clay Kellogg, CEO, Terminal. If we’re in a seller’s market, engineers are the ones to profit. Increased bargaining rights could mean remote engineers may demand equal pay, no matter their location. The study found that, on the whole, engineers are not in favor of location-based salaries; 49% say they would only accept a location-based salary if their cost of living dropped by 20%.

    In addition to offering competitive wages, teams are finding creative ways to maintain culture and avoid burnout. For example, 55% of engineers think virtual get-togethers like happy hours and social activities help stave off burnout. With all these findings in mind, companies should consider instituting a work-from-anywhere policy wherever possible and provide additional benefits and support for remote workers to attract more engineering talent.

    The State of Remote Engineering surveyed over one thousand software engineers across the U.S., Canada and Latin America. For more granular details, consider viewing the full report here.

  • How to Prepare Your DevOps Environment for DevSecOps

    How to Prepare Your DevOps Environment for DevSecOps

    The COVID-19 pandemic has created a deep, irreversible change within work environments, as most organizations are reimagining this “new normal” with a combination of fully remote or hybrid work. DevOps practices are being increasingly normalized and relied upon to respond to the needs of modern, digitized companies. Coming out of the pandemic, organizations now better understand the need to efficiently deploy the software applications necessary to thrive in this new world of work.

    This isn’t surprising given organizations have realized the value of DevOps to help product teams deliver quality code at a fast pace. DevOps enables them to be more agile and move more quickly to respond to evolving market changes and business demands. To maintain the speed of software delivery, product teams are integrating various tools within their CI/CD pipelines and minimizing tool citations and validations outside of their pipelines.

    As the rate of change increases alongside these DevOps practices, automating compliance to enterprise security controls becomes more important than ever, especially given that security vulnerabilities in code and configurations present dire business risks. For DevOps to truly succeed, organizations need to modernize and automate security processes, making them an integral part of the DevOps build and delivery pipeline—readying the overall DevOps environment for DevSecOps.

    But successful DevSecOps deployments depend heavily on the maturity of an organization’s current DevOps environment and security operations workflows. This includes prioritizing the core principles of automation, measurement and collaboration because these same principles also drive positive security outcomes. Referencing these principles, here are four best practices organizations should consider incorporating when evaluating how to mature their DevOps ecosystem and security operations processes to be ready for DevSecOps.

    Embed Security Tools in Developer Workflows and Governance Processes

    The first step in the journey prioritizes a “security-first” mindset and related skills for development teams. Security shouldn’t be an afterthought, and development teams shouldn’t rely on security teams to check vulnerabilities later in the life cycle. Instead, security experts need to become an integral part of the development phase so that the code accounts for security from the get-go.

    This can be achieved either by moving responsibility for security skills into the development teams or by having the security team play an advisory role earlier in the life cycle. Development teams can then automate the necessary security vulnerability checks—like static application security testing (SAST), software composition analysis (SCA) and dynamic application security testing (DAST). But more importantly, sharing insights and streamlining communication between development and security teams is crucial to ensure policies are working and are being consistently applied across the organization.

    Continue Automation Beyond the Pipeline

    Puppet’s 2020 State of DevOps Report revealed that organizations have matured their DevOps environment by improving governance processes such as change management, preparing enterprise infrastructure and applications for organizational change. In fact, they found that organizations with automated change management and governance processes are nearly three times more likely to outperform competitors in DevOps transformations.

    This is because automation improves change management processes, which in turn eliminates barriers to applying governance to DevOps. This is also backed by Puppet’s survey, which cited that automation makes organizations more confident that their change management solutions are effective. A comprehensive, automated change management process instills governance by applying policy-based rules to a code or configuration change before allowing it into production. It does this in real-time by leveraging data collected from the pipeline. When applied correctly, DevSecOps tools prevent vulnerabilities and automated change management conducts a ‘last mile’ check to ensure the correct scans were run and adhere to compliance policies.

    Provide End-to-End Traceability Across DevOps

    Product teams—and all involved in the delivery of an application—should have an accessible audit trail, providing visibility into security checks, users, code and configuration changes, code quality, testing and more. This paints a clear picture of what happens to the software from ideation to production. In an ideal world, product teams include both operations and security personnel, but these functions often remain siloed in large organizations.

    Companies can break down these silos and make it easier for teams to collaborate by centralizing visibility. Providing visibility and centralizing security policies makes it easy for teams to efficiently operate the delivery process of software since they are provided a single source of truth. Additionally, an automated system for gathering audit data improves the consistency and reliability of audit information. Automatically collecting data from the entire pipeline and eliminating the need for developers to enter information diminishes the likelihood of data anomalies—saving valuable time and resources.

    Empower Cross-Enterprise Collaboration to Address Security Issues in the DevOps Pipeline

    Applying artificial intelligence and machine learning to DevSecOps processes helps organizations quickly identify and remediate security issues before they are manifested in production, enhancing proactive and actionable collaboration and coordination across product teams.

    As Puppet cited in its 2019 State of DevOps Report, sharing and collaboration are two of the most impactful things teams can prioritize to improve DevOps initiatives, including DevSecOps, and this still holds true today. The 2020 survey results signaled how many more organizations are reaching this peak point of DevOps maturity.

    Ultimately, we’re already seeing how operational activities—like checking software for security vulnerabilities—are moving into the DevOps pipeline and are being handled as “code.” But organizations should take this a step further by keeping in mind factors such as reliability, predictability, measurability and observability across DevOps deployments to foster more secure environments and pipelines.

  • MediaOps and DevOps Institute Earn Inc. 5000 Honors

    MediaOps and DevOps Institute Earn Inc. 5000 Honors

    I am really proud to announce today that both MediaOps and DevOps Institute have been honored by Inc. and earned inclusion in the Inc. 5000 list of the fastest-growing companies in America.

    For MediaOps, this is the second year in a row we have earned this honor. For DevOps Institute, it is the first year they have been honored. First of all, congratulations to all of the great people who work at and make both MediaOps and DevOps Institute the great companies they are. None of the success of these companies would be possible without their talent, skills, hard work and dedication. Thanks to all of you.

    Secondly, as the founder/co-founder of both of these organizations, I can’t tell you how proud I am that both of these companies have not only had the success they have (as evidenced by this honor) but that they have done so in the middle of a global pandemic. It really makes all of the hard work and the long days and nights worthwhile.

    For anyone who has ever started a business, you know that you put a certain amount of your blood, sweat and tears into any venture you are involved in. It is no different here! Since 2014 I have put everything I could into growing MediaOps into the company it is today. For DevOps Institute, I was lucky to have my partner Jayne Groll, DevOps Institute CEO, take the lead in making DevOps Institute the leading member organization/certification authority in the DevOps space today.

    Yes, you hope the monetary rewards of founding a company make it all worthwhile. But this kind of recognition is also very gratifying. It gives you the extra spring in your step and makes the load lighter.

    These awards also highlight something else. The ascendancy of technology. It is no coincidence that both of these companies play in the digital transformation space and have seen such success. Digital transformation is driving the world right now. Software is driving digital transformation, and DevOps, cybersecurity and cloud are driving software.

    At the end of the day, it is a great honor to have not one but two companies you started win this award at the same time. I think it speaks volumes about the future of both of these organizations. More news on that front is coming, so stay tuned for more great things coming from MediaOps and DevOps Institute!

  • Measuring Value Streams by Analyzing Flow Metrics

    Measuring Value Streams by Analyzing Flow Metrics

    There is increasing pressure and demand for IT administrators to bring software to market quickly and cost-effectively. To achieve that goal, IT departments frequently compile various metrics that measure specific development processes.

    Data and metrics are important tools, but administrators sometimes don’t think to look at projects through a wider lens—by measuring total production workflows. This can curb production and adversely affect business outcomes as inefficiencies go undetected across the value stream.

    In other words, total visibility across the entire value chain is needed to accomplish lean project management and optimize DevOps workflows.

    Let’s talk about the different kinds of flow metrics, why they matter and how to begin measuring them.

    Flow Metrics: What do They Mean?

    Flow metrics indicate the rate of value delivery with regard to desired business outcomes. This allows organizations visibility into production at a macro level so that they can make more effective decisions. Flow metrics can also produce an analysis of historical performance over time, which can be valuable for businesses that focus on continued growth.

    IT leaders now widely use flow metric analysis to bridge the gap between business teams and technology, because it can uncover a variety of problems that affect critical objectives. For instance, teams can identify prioritization challenges, why projects take longer than expected, pinpoint technical debt and more.

    When evaluating flow metrics, IT departments measure individual work units—also known as flow items—that clients or product teams hand over to their colleagues. This may be a request for a new software feature, a security flaw or something that needs a fix.

    What Are the Different Kinds of Flow Metrics?

    With a better understanding of flow metrics, we can now delve deeper into the five flow metrics that organizations should assess throughout the development process.

    1. Throughput

    Throughput measures the rate at which total number of flow items are completed. By measuring this, throughput can determine the total amount of value attained and distributed during a specific project.

    Throughput is generally measured week-over-week. Measuring and evaluating throughput on a historical basis also helps work out how clashes in priorities affect value overall.

    Optimizing throughput results in greater end user experiences and customer satisfaction, which naturally drives revenue and growth.

    2. Cycle Time

    Cycle time is the speed at which an IT team can deliver value. This means timing how long it takes for flow items to progress from work start to work complete, taking into account active and wait times.

    Cycle time is just as important as throughput when it comes to driving revenue and growth. Measuring cycle time can streamline the process of determining project estimates and allocating resources, resulting in stronger workflows and enhanced efficiency.

    3. Flow Efficiency

    Flow efficiency is the proportion of active time to wait time. Measuring flow efficiency uncovers where roadblocks are happening and whether process waste is rising or falling. The desired flow efficiency rate should be higher than 15%.

    Most flow time comes from waiting, resulting in roadblocks and increased production costs. Measuring flow efficiency can enable teams to pinpoint when workflows are taking too much time, and they can then take active measures to accelerate individual processes.

    4. Work in Progress

    Work in progress involves measuring demand. Teams achieve this by measuring the amount of flow items either pending or in active development within a value stream. Measuring work in progress generally enables IT leaders to identify whether value streams are overused or underused.

    Nobody’s perfect. That’s why leaders have to be conscious of how each employee’s time is being used. By doing so, they can systematically assign workloads and enhance quality where required. This, in turn, lowers burnout and turnover while also cutting down on mistakes that need to be reworked.

    5. Work Profile

    Measuring work profile is important when determining priority alignment. It’s analyzed as a ratio of the four other flow items completed in a specific time period.

    Assessing work profile allows for optimal quality and productivity. This raises customer experience (CX), which results in better retention and reviews.

    Why Should I Track Flow Metrics?

    In the past, DevOps professionals largely went without the necessary tools for tracking and enhancing flow metrics, but recent improvements in tracking these metrics have made the process much more efficient and easy.

    There are three key reasons for flow tracking:

    1. Boost Communication

    A lack of communication can be a common issue between business and software teams. Flow tracking enables IT administrators to delve into flow metrics and gain insight into the value stream. This helps teams provide accurate project estimates along with real-time updates, which makes communication with stakeholders much easier.

    2. Determine Desired Business Outcomes

    Having total visibility across a value stream helps IT and business leaders cooperate on identifying and prioritizing key projects and establishing goals.

    Improving software quality could be a goal, for example. Teams can examine various flow metrics to determine what is causing issues in software quality, how to fix those issues and how prioritizing adjustments to software quality could affect other workflows.

    3. Act on Intelligence

    Software organizations spend a lot of time and money attempting to expedite software development. They hold meeting after meeting, hire consultants or even bring on new team members, but the solutions they need to streamline workflows can be simple. They just need to be discovered.

    Organizations can gain total and real-time visibility into the value stream with flow tracking. This makes it quick and simple to act on intelligence and enhance development, leading to accurate, data-driven decisions that don’t require guessing.

    Elevate Your Value Stream With Flow Metrics

    Achieving optimal efficiency in workflows requires end-to-end visibility, which is made easy by analyzing flow metrics.

    Using flow metrics to maximize the value stream improves visibility, accelerates development and cuts software production costs.

  • How Third-Party Security Assurance Enhances DevSecOps

    How Third-Party Security Assurance Enhances DevSecOps

    Enterprises are constantly trying to do more with less today, and do it faster to gain competitive advantages and grow revenue. Nowhere is this more prevalent than in their internal software development processes. The movement to third-party or external sources of code is a natural reaction to “faster” release cycles. However, this need for speed can have unintended downstream security consequences for application development teams.

    As cybercrime has grown parallel to the explosion of digital processes in many enterprises, “security by design” needs to go from a nice-to-have concept to a hard reality. This is the reason DevSecOps has gone from buzzword to practice for many development teams. Implementing a software security assurance program, which embeds security as part of the coding and assembly process rather than a separate, after-the-fact quality testing function performed by security staff, is vital to limiting the cost of fixing vulnerabilities and preventing data breaches.

    Software Attacks are a Growing Problem

    One of the recent and most high-profile cybercrime incidents involved hackers using the SolarWinds software platform as a launching pad to breach companies. With threats specifically targeting software on a growth curve, organizations need to secure both the software they develop and that which they acquire from suppliers. This often includes a lot of reused code picked up from vendors and open source libraries that offer the building blocks for software and applications to help developers work faster and cheaper—but with a potential security cost.

    Maintaining software security has become more complicated as enterprises rely more on third parties for the components to develop software faster and cheaper and keep up with digital disruption. The share of code developed in-house for enterprise software has dropped from 43% to 38% in the last five years, while the use of commercial and open source software has grown in its place. Rather than rely on custom code, many developers are leveraging open source components or API libraries to build applications. Some software vendors provide application libraries that can have third-party components purchased by that vendor for their customers.

    Leaning on third-party code can leave software open to abuse, as developers have less visibility into the content of the components they use as the building blocks of their programming. Some vendor libraries get reused by the vendor for different applications, and some use open source components in their code; a developer may be using third- and fourth-party code from who-knows-what source. Vulnerabilities can be hiding many layers deep in the code, and unless developers know the source, they are difficult to detect.

    This is where a well-established software security assurance program can reduce the risk of cybersecurity incidents and the impact of security weaknesses. It protects users and the enterprise by establishing cybersecurity practices, fulfills the organization’s risk management and compliance requirements and offers the C-suite visibility into the process.

    A Checklist for Software Security Assurance

    A well-organized security assurance program ensures that security requirements have been established for the software and the software development process and that any software deployed is free from vulnerabilities. If any are found, it also establishes remediation steps to handle them.

    Some important practices:

    ● Trust but verify: Ensure that a security evaluation has been performed for the software throughout the software development life cycle (SDLC). Proactively validate the security and integrity of software code and provide results identifying any vulnerabilities found and assign remediation steps to correct them before release into production.
    ● Know what’s in the software: Since many developers and software vendors rely on open source and third-party code more frequently, it’s more important than ever to know what those components are and where they come from. Software security
    assurance should include the software bill of materials (SBOM) for any open source code and third-party components.
    ● Put it in writing: Produce documented proof, such as the SBOM mentioned above, and generate a vulnerability report proving the integrity of the software. If vulnerabilities are found, determine the cybersecurity risk and the potential impact based on the Common Vulnerability Scoring System (CVSS) score, an industry standard, to guide remediation.

    A good software security assurance program makes sure that each software review or audit includes an evaluation of the security requirements for the enterprise. These can vary by industry—and even within the organization—based on which function the software is running. A program running mailing lists for a power generation company is not as mission-critical as the software running the power grid.

    With all industries in the crosshairs of cyberattackers, an effective and diligent software security assurance program will make it harder for them to find a back door and can help keep your organization safe.