Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: The first silicon for Wi-Fi 7, Google’s search quality “is” failing, and what Severance tells us about The Great Resignation. (more…)
Encore has made generally available a namesake backend development engine for rapidly building scalable distributed IT environments across multiple cloud platforms.
Fresh off raising $3 million in seed funding, Encore CEO André Eriksson said the Encore platform analyzes source code to eliminate the need to manually configure, connect and set up portable cloud computing environments.
In addition to being able to automatically setup and manage cloud infrastructure based on the metadata surfaced by static analysis tools, Encore provides access to a built-in continuous integration/continuous delivery (CI/CD) platform, previews of environments, live reloads of cloud environments, authentication, secrets management and automatic distributed tracing capabilities.
Eriksson said the development of the Encore environment was, in part, inspired by how developers of games today routinely use an engine to build application environments rather than presenting developers with a set of text-based editing tools to build those environments using low-level boilerplate code that has to be written by developers for each application instance.
Written in the Go programming language, Eriksson said Encore platform is based on an open source Encore Go Framework that prevents IT organizations from becoming locked into an Encore platform that today can be deployed on Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud services.
The building and deploying of distributed applications has always been a major challenge. Encore is designed to automate most of the routine tasks that DevOps teams today need to manually perform for each distributed application they support. As the number of applications being deployed across various cloud computing platforms increases, the challenges associated with managing those environments increase. Encore is designed to enable developers to easily build and deploy application code in a way that can be centrally managed by a DevOps team, noted Eriksson.
It also takes advantage of the concurrency capabilities that the Go language enables to make it simpler to build and deploy distributed applications in a cloud-agnostic manner, said Eriksson. DevOps teams can also employ Go to extend the Encore environment within the boundary of certain limitations, he added.
Essentially, Encore is making a case for an opinionated distributed computing environment that, in return for less flexibility, promises to make it simpler to deploy complex applications. Eriksson said Encore doesn’t see many DevOps teams looking to deploy distributed applications that span multiple cloud services, but they are being required to deploy more applications on different cloud platforms. Each cloud platform a DevOps team needs to support only serves to make the overall IT environment that much more complex to manage, he noted.
It’s not clear to what degree IT organizations are ready to embrace a more opinionated approach to managing cloud computing environments. However, the concept of relying on one is hardly new. Platform-as-a-service (PaaS) environments have been employed for years. However, with the rise of microservices-based applications that are inherently distributed, the issue may soon be forced as IT organizations find simply no other way to keep pace with the rate at which applications are being developed and then continuously extended after they are deployed.
Quali has added a control plane to its Torque platform to give DevOps teams the ability to consistently provision and orchestrate infrastructure across a heterogeneous distributed computing environment.
Amir Rosenberg, vice president of product for Quali, said the control plane allows DevOps team to centrally manage the provisioning of infrastructure via reusable blueprints accessed via a self-service portal, which individual developers can access. That approach eliminates a bottleneck that occurs when DevOps teams manually provision infrastructure on behalf of development teams, he said.
The latest release of Torque also adds enhanced visibility and cost control capabilities such as the ability to set limits for maximum duration and number of concurrent environments and limits for the total cost of an environment. Also included are cost reporting tools for Kubernetes clusters and improved forecasting and resource consumption policies that can be applied to blueprints, sandboxes and spaces.
Security enhancements include new customizable role-based access to blueprints, API Token Controls and integrations with secrets management platforms.
Through its software-as-a-service (SaaS) platform, Quali makes it possible to access Torque via either a cloud account or a user interface that connects to a GitHub account where blueprints are stored. The goal is to enable DevOps teams to maintain some control over how infrastructure is provisioned without impeding developer productivity, said Rosenberg, noting at a time when more organizations than ever are launching multiple application development projects, there is more sensitivity concerning developer velocity than ever.
It’s a fact that infrastructure misconfigurations happen because developers make mistakes. It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that makes it possible to centrally apply policies that act as guardrails to prevent developers from making provisioning mistakes. An alternative to scripts created using tools such as Terraform, the blueprints can deploy complete application environments automatically. That approach also provides more visibility into how resources are being consumed.
Every minute a developer spends managing infrastructure theoretically is one less minute they could be spending writing code. As application environments become more complex, Rosenberg noted it’s becoming that much more challenging for developers to cope with managing infrastructure as code. The issue is that DevOps teams who could provision infrastructure for developers are being overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, which, Rosenberg noted, leads to more mistakes being made.
It’s not clear when or even whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t rely on developers as much, but most seem to agree that developers have far better things to do with their time.
Will the importance of CX only increase? That’s a safe bet. So how does a business get to Apple, Disney or Amazon-level CX? Reliability is a good place to start.
Reliability—in the context of a digital-first business—is the ability to quickly identify and resolve issues before they reach the customer. Reliability is a critical demand of both consumers and enterprises as they pursue digital transformation, especially cloud migration and automation.
Achieving reliability may sound rather straightforward, but many factors in DevOps often work against reliability. For instance, many DevOps teams focus solely on technical performance metrics but turn a blind eye to CX metrics like churn rate or net promoter scores (NPS). Some business leaders fix this with advanced AI and machine learning technology, but too often those solutions don’t live up to expectations enough to provide a return on investment (ROI).
Observability, on the other hand, is an approach that collects and analyzes data on every component of a system, application and infrastructure—from performance to security to accessibility. This information allows DevOps teams to glean insights on the reliability of actions performed within a unique business environment, such as an interactive voice response (IVR) system or a contact center.
Gartner defines observability as the evolution of monitoring into a process that offers insights to speed innovation and enhance CX. To establish digital observability, DevOps teams should consider the following components.
Every day, companies are losing revenue due to a lack of customer experience observability. Forrester reported that more than $1 billion in potential revenue is being left up for grabs. This is largely due to poor comprehensive customer experience technology investment decisions. As DevOps teams work to deliver new CX innovations—like personalized VR shopping experiences or advanced AI-based chat support functions—they do their best to foresee potential flaws or bugs. However, flaws will inevitably creep in. That’s why consistent observability is crucial. Observability helps DevOps practitioners see these issues quickly and gives them optimum time to respond before it becomes a costly threat to customer experience.
To provide this level of observability, data must be available, accurate and analyzed in real-time. This requires automated solutions because the faster a data set can be analyzed, the more value it will deliver. Automated testing tools work by generating thousands of synthetic omnichannel interactions to test the customer journey from the outside-in—from the network through IVRs to digital apps and routing systems, all the way to agents at their desktops. Automated testing of elements such as connectivity, responsiveness, quality and functionality can help DevOps teams ensure quality is achieved throughout the entire CX development life cycle.
Detecting issues early also requires precision and intentionality that answers questions like: What data will be collected? Who will own and examine the data? Why does that data matter to our business? Being able to analyze, organize, manipulate and share test data helps DevOps teams have greater ownership and oversight over information that’s constantly coming in.
DevOps organizations benefit from using a platform that centralizes all voice call test data for the entire team so that nothing is missed, and the data can cover a wide array of use cases. Typical test datasets might include information on factors such as customer persona labels (for example, Gold, Silver and Bronze customers or labels by Line-of-Business), order status or payment methods. A centralized monitoring and testing platform allows DevOps teams to create and import comma Separated Values (CSV) files to create a test dataset for a specific IVR and then use it to test the organization’s other IVR systems to save time by not re-creating it manually. It’s also important for internal teams to be able to track who is modifying test data, when it’s being modified and which test cases are using specific datasets.
Eighty-four percent of businesses that focus on improving CX report an increase in revenue. Executive investment in CX is critical here and considering the ROI, should not be a difficult sell. To go even further, businesses should consider establishing a leadership role that is responsible for proactively addressing CX and reliability.
For CX digital transformation initiatives to succeed, they must be led by an executive leader who can champion the need to drive cultural change and strategic investments. Appointing an executive to this role will ensure that CX initiatives aren’t siloed from DevOps teams, but also from the rest of the enterprise, including sales, marketing, operations and more.
Some organizations choose to create an entirely new chief CX officer role so that the leader can give their full attention to CX transformation initiatives, processes and technologies. Others, depending on the company’s organizational structure, may decide to appoint these responsibilities to the current COO, CIO or CMO. Whatever the decision, the digital transformation leader must have broad authority that covers budget, people and processes in order to be effective in their role.
Focusing on observability within customer experience technology will help organizations improve their reliability as a brand. With greater observability and automated testing capabilities, DevOps teams will be empowered to innovate faster and deliver higher-quality solutions that will improve customer interactions and solidify brand loyalty for years to come.
DevSecOps is everywhere, and chances are your organization is shifting toward this convergence of development, security and operations. In an on-premises environment, you build your own DevSecOps process by mixing and matching existing and new tools. However, in the cloud, much of the environment is determined by your cloud provider. Microsoft’s Azure cloud is known for its robust security capabilities. Specifically, Microsoft has developed a set of capabilities and services that can help you ease into a DevSecOps workflow without much effort. The tools are pre-integrated and support everything from CI/CD to identity management. Let’s see how they work.
Security is an important part of DevOps. But it can be challenging to ensure that software developed in a CI/CD process is really secure.
DevSecOps is an organizational pattern that can make this possible, even at high development velocity. It is an approach the DevOps team can use to prevent security issues from the outset of the development life cycle, ensuring their software is not only high quality but also secure and resilient to failure.
DevSecOps is a discipline that combines application development, security, operations and infrastructure-as-code (IaC) with an automated continuous delivery cycle. Here are three practices that can help a team move towards a DevSecOps process:
The Azure cloud provides several built-in capabilities that make it possible to adopt a DevSecOps process.
Azure DevOps provides developer services that enable teams to plan tasks, collaborate on code development and build and deploy applications. Azure DevOps supports a collaborative culture and process in which developers, project managers and contributors work together to develop software. You can use Azure DevOps Services in the cloud or Azure DevOps Server on-premises.
You can integrate Azure Pipelines, the Azure cloud’s CI/CD solution, with your Kubernetes clusters. Use the same YAML document to build multi-stage CI/CD pipelines.
Azure Pipelines lets you track metadata, such as commit hashes and issue numbers, from Azure Boards into container images. This provides direct traceability from any security issue to a specific change made in development. It also provides clear, easy-to-read documentation that can improve the feedback loop between development, operations and security teams.
When developing Kubernetes applications, there is a need to test applications locally and understand how they interact with dependent services. You may need to develop and test multiple services in collaboration with other developers or teams.
Azure provides Bridge to Kubernetes, which lets you run and debug code on your development machine while connecting to your Kubernetes cluster. You can test your code end-to-end, set breakpoints on code running on the cluster and share your development cluster among team members. This makes it possible to test and resolve Kubernetes security issues in a realistic environment before deploying to production.
The Microsoft Identity Platform takes the Azure Active Directory (Azure AD) developer platform one step further. It allows applications to accept logins from any Microsoft identity, and obtain tokens that can be used to call Microsoft APIs or APIs created by other developers. This creates a large, interoperable ecosystem.
Azure Active Directory B2C provides B2C identity services—customers get single sign-on (SSO) access to applications and APIs using their preferred social, enterprise or local account ID. Another option is to integrate Azure AD with on-premises Active Directory for hybrid and Azure migration scenarios.
You can also use Azure Role-Based Access Control (RBAC) to manage access to cloud resources. RBAC lets you manage who can access your Azure resources, what they can do with them, and which regions can access them.
You can also use the Microsoft Identity Platform to protect DevOps tools themselves, including native support for Azure DevOps and integration with GitHub Enterprise.
Exposed secrets are a severe security issue that is very common in modern applications. Azure Key Vault lets you manage the distribution of secrets by storing them centrally in Azure Key Vault. Key Vault greatly reduces the chance of accidentally disclosing secrets. With Key Vault, application developers no longer need to store credentials or other sensitive information in their application code.
Azure Policy lets you specify a default allowed configuration that is automatically applied to all cloud resources. This can avoid misconfigurations that violate security policies. Azure Policy works on the basis of desired state configuration (also known as declarative configuration), letting you specify to what degree resources and services should be secured and whether to alert or block/modify deployments in Azure if they don’t meet the policy.
When using Azure in multi-tenant mode, policies can be applied at the management group, subscription or resource group level. You can define specific policies and enforce compliance requirements for test, staging, and production environments.
The Azure Security Center (ASC) and Advisor can also be easily integrated into the DevOps process. ASC makes it possible to augment event streams in Azure with threat intelligence or analysis by third-party security tools.
Penetration testing is the recommended method for examining your environment for infrastructure or application configuration vulnerabilities that could create vulnerabilities that an attacker could exploit.
An Azure penetration test should check for vulnerabilities on endpoints, apply fuzzing (malformed input) to discover business logic vulnerabilities, and perform port scanning to identify network vulnerabilities.
Microsoft provides specific guidance for penetration testing in Azure with recommended products and penetration testing service providers.
To ensure security for cloud subscriptions and resource configuration across multiple subscriptions, you can use the tenant security solution part of the Secure DevOps Kit for Azure (AzSK).
In addition, you can leverage Microsoft security technologies like Microsoft Defender for Cloud and Microsoft Sentinel. These solutions provide monitoring and security features designed to detect and alert on unusual events or configurations that require investigation and possible remediation.
In this article, I introduced DevSecOps and showed how the Azure cloud provides a range of services that let you easily implement DevSecOps practices. These include:
I hope this will be useful as you take your first steps to practice DevSecOps in the cloud.
With the increased interest in DevSecOps, the Cloud Security Alliance (CSA) and Software Assurance Forum for Excellence in Code (SAFECode) brought together a DevSecOps Working Group to identify and share best practices for the development and maintenance of a DevSecOps program. This working group identified and defined six focus areas critical to integrating DevSecOps into an organization; this article will focus on pillar one—collective responsibility
When we look at security historically, we find that it has often been relegated as a secondary objective when compared to other primary objectives like releasing features to market quickly. The rationale is that if we don’t release fast, our competitors will get ahead of us. Unfortunately, that mindset is fraught with security risk as evidenced by the rising number of vulnerabilities in our software. Malicious actors can take advantage of these vulnerabilities to breach critical systems and exfiltrate sensitive data.
Let’s not be too hard on ourselves, however. Security in a DevOps world is not an easy problem to solve. As we continue patching vulnerable code, new flaws emerge just as quickly. In essence, the security landscape is dynamic and continues to evolve. Solving a complex problem like this requires diversity of thought. In other words, we need to include people with different perspectives in the security conversation. Essentially, we need to build a collective mindset rooted in security culture. Security then becomes a collective responsibility rather than the responsibility of a few people.
Now that we’ve agreed on the importance of collective responsibility, the logical question that emerges is, “How do I operationalize collective responsibility?” Pillar one addresses this question. We need to bring together our security and DevOps cultures. No longer can we talk about security or DevOps. It has to be both. This means security must be considered and addressed at every point in the software development and operations life cycles. Extending this further beyond the technical domain, security is fundamentally tied to business objectives, not left as an afterthought or considered a mere cost drain.
Building a security-supportive culture involves three broad phases:
Pillar one reinforces the idea that security responsibility cannot be limited to a few people. Just as software development is no longer an exclusively technical activity, security is no longer a compliance activity. This has a profound impact on DevSecOps practices. Here are just a few areas that are impacted by this shift in mindset and responsibility:
Implementation of pillar one touches on structural issues aimed at removing silos. There are many possible ways to build cross-functional teams. One approach is to have security embedded inside DevOps teams. Another approach is to integrate security as a support structure for DevOps teams. In either case, given the limited number of security professionals, a security champion can help bridge the gap between DevOps teams and security teams. A security champion ensures that the software being built and deployed takes security into account. To achieve this, it is important to set up a security champion for success:
Setting up a security champions program without a clear sense of direction can lead to a lot of wasted time and effort. Collective responsibility rests on teams being able to communicate across functional silos and a security champion is an exemplar of that mindset.
We live in a world where the rate of software development and deployment outpaces traditional security practices. This has come at a cost. Balancing both speed and security is the new norm. The right balance is dependent on each organization. One thing remains the same, however, and that is culture. We need a culture that is supportive of security and views it as a collective responsibility. This takes intentionality. Organizations need to get their executives involved and make sure the program has relevant elements to drive a security culture and has a clear path to business value.
DevOps and cloud-native are key for organization looking to accelerate their digital transformation journeys. Techstrong Live! Days, a two-day, in-person event, explores the latest DevOps, cybersecurity and cloud-native technologies and trends that are shaping the way we do business. The first stop of the Techstrong Live! Days conference tour will take place in Washington, DC on April 13-14 at the Convene Event Center. The in-person event offers educational sessions, demos and hands-on training sessions (certification available) led by top industry experts.
DevOps/Cloud-Native Live! is day one of the conference. The agenda for day one features a mix of topics, including API security, Kubernetes, DevSecOps, cloud security, observability and more.
The sessions include keynote presentations, educational talks and hands-on training with leading DevOps and cloud-native tools.
DevOps/Cloud-Native Live! features an outstanding lineup of innovators, practitioners and thought leaders, including:
Cybersecurity Live! is day two of the conference. The agenda for day two features a mix of topics, including AppSec, software supply chain security, SBOM adoption, cloud security, DevSecOps, cybersecurity threats, 5G security and more.
The sessions include keynote presentations, educational talks and hands-on training on forensics/hacking (certification available) and API security. By attending and participating for a full day at Cybersecurity Live!, attendees will receive a certificate in-person or via email granting seven contact hours for the appropriate CEU/CPE Credits.
Cybersecurity Live! features an outstanding lineup of security experts, including:
Attendees will also have the opportunity to attend networking receptions each day to connect with other IT professionals, exchange ideas and learn from one another. Breakfast, lunch and snacks will also be provided to all attendees.
Join us at Techstrong Live! Days in Washington, DC to level up your existing skills, discover new cloud-native and DevOps tools, improve the security of your APIs and network with experts and peers.
For more information on DevOps/Cloud-Native Live! and to register, please visit the DevOps/Cloud-Native Live! website.
To learn more about Cybersecurity Live! and to register, please visit the Cybersecurity Live! website.
It’s time to rethink how we deliver distributed access to software development environments.
We know how to write code. And there are plenty of well-established tools, techniques and processes for doing so.
We know what kind of code to write: Functional, scalable and efficient code that’s inherently secure and that we can readily modify whenever and however we need to modify it.
We know why we write code. We write it to enhance the value we offer customers, to expand our market reach, outperform the competition, cut costs, minimize risks and otherwise engage in what we call “digital transformation.”
We know who writes code—or, more accurately, the various “whos” who write it. We need developers with a diverse range of skills. And as our needs keep changing, we keep adjusting the mix of in-house and contract developers accordingly.
We also know when to write code—which is now and for the foreseeable future.
The one thing we still struggle with is where to write code. Not ‘where’ in the physical sense; we’re way past that. We know that for development teams to be optimally productive, we have to enable everyone to work from any physical location at any time. COVID-19 has dramatically reinforced this principle.
The ‘where’ we struggle with is the virtual ‘where’ of the developer workspace. Yes, we already provide developers with remote access to development resources. Sort of. But there are a lot—a lot—of problems with the way we do that. These problems adversely impact development every day by, among other things,
Unfortunately, we’ve become so accustomed to these problems that we tend to accept them as normal. But we cannot afford to accept them any longer. Here’s why.
One big problem for both developers and the enterprise is that developer workspaces aren’t fully portable. The methods we use to give developers remote access to their environments invariably come with unacceptable insecurity. There’s also the issue of onboarding. When a developer joins a team—whether as a new hire, temporary contractor or current employee switching to another project—it can take days for them to get them fully up to speed with access to all the project-specific resources they need. That ramp-up time invariably frustrates developers.
On the other hand, offboarding developers can be a security and compliance issue. Piecemeal provisioning of the multiple resources developers need inherently results in the piecemeal deactivation of those same resources. So when a developer quits or is fired—or when a contractor’s contract is up—we can’t be 100% certain that all their permissions have been revoked.
Moreover, what happens when a developer needs to go back into a project that no one has touched in months or even years? How does a developer recreate the full workspace associated with that project and have high confidence that they’re doing it right?
The answer is that we can’t. Instead, some unfortunate developer inevitably has to spin their wheels trying to piece together a long-dormant project. All your aging code is thus guaranteed to become “legacy” (which is just another name for ‘code no one is quite sure how to work on’), thereby guaranteeing that your organization will forever be burdened with an ever-growing mountain of resource-draining technical debt.
So how can we re-engineer the delivery of remote workspaces so we make life easier for developers while also fulfilling the security and compliance requirements of the enterprise?
Here are a few ideas to consider:
And those workspaces don’t exist as monolithic, “all or nothing” environments that you pray you’ve gotten right. Instead, with containerization, you can build project-specific workspaces more quickly, at less cost and with less risk.
Effective hosting of fully portable developer workspaces requires other important functionality as well: Inactivity time-outs, cloud cost/utilization controls, etc. Before addressing these details, however, development leaders must first come to terms with the fact that developers need a much better way to work remotely—and that every remote workspace must be a secure one.
In recent years, our reliance on software has exploded. It has been more than a decade since Marc Andreessen made his prophetic observation that “Software is eating the world.” Today, nearly every interaction is mediated through a screen and backed by software. With the massive shift to remote and digital interactions due to the pandemic, enterprises that were already in the process of acclimating to a digital-first future had to quickly pick up the pace to survive today’s increasingly complex tech landscape, putting an inordinate strain on IT teams.
Developers obviously deliver the most crucial component of the software development life cycle; however, ownership of their developed services and applications is no less important. The idea of ‘full-service ownership’ means taking responsibility for supporting the software and services you deliver at every stage of their life cycle. Excellence in continuous delivery and innovation on them is about speed and velocity while maintaining quality.
At its core, service ownership is about connecting humans to technologies and services and understanding how they map to critical business outcomes. Achieving this level of ownership requires an understanding of what and who delivers critical business services. A clear understanding of what the boundaries and dependencies are of a given service along with what value it delivers is the starting point. And once it’s in production, a clear definition of who is responsible for it at any given time and what its impact is if it isn’t running optimally or, worst case, fails altogether. Empowering developers with this information brings DevOps teams much closer to their customers, the business and the value they create which, in turn, leads to better application design and development.
Building a culture around a full-service ownership model keeps developers closely tied to the applications they build and, therefore, closer to the value they deliver. Within the organization, this type of ownership breaks down long-established centralized and siloed teams into cross-functional full-service teams. For enterprises with deeply ingrained processes, this may be easier said than done—but the outcome is well worth the investment. Following these guidelines will allow even legacy IT teams to create a culture of full-service ownership.
With the pressure to innovate already weighing heavily on software teams, you may be wary about the burden more responsibility might cause. However, the end goal is mutually beneficial: Create clear ownership at real-time speeds. Not only does this allow engineering teams to ship features more quickly but it also empowers them to stay engaged and connected when something goes wrong—reducing hand-offs and mean-time-to-resolve (MTTR). In other words, no panic, no uncertainty and minimal customer impact.
Reworking team structures and technology for full-service ownership may seem overwhelming, but it doesn’t need to be. Traditional function-based silos are a feature of many legacy IT departments. Provisioning infrastructure and resources, developing code, quality assurance, owning the customer relationship, supporting software in production and so on are too often delegated across segmented, centralized teams. Allowing decentralized teams to own the entire life cycle of their services affords them the ability to add value in new ways. The key is to start small and implement changes gradually.
When beginning the process of full-service ownership adoption, pointing to small wins will gain the support of key organizational stakeholders who can then facilitate larger-scale change. Start with non-critical production systems or greenfield applications. Agile methodologies will also be useful in adapting to dynamic development needs and unpredictable events. Remember to be flexible with the timeline in the initial phases and be patient with your team—mastering the life cycle takes time!
Keeping long-term goals in mind, your teams should consider not only “build and deploy” but also “run.” Craft your tech stack in a way that comprehensively shows the entire infrastructure, leverages machine learning to reduce false alarms, and uses automation to conserve the manpower and resources involved in going on-call to support services in production.
A key requirement here is building trust and an accurate system for identifying who is responsible when something goes wrong. Adjusting to a DevOps approach will fail if developers receive false alarms, too many interruptions or are constantly escalated to repetitive fixes. Building and executing on a strong service directory and supporting their preferred schedules is critical. As is ensuring when they are needed, you contact them via the channels they expect. Failing to do this can result in minutes and hours lost and worse yet, frustrated and burnt-out developers. Recent data shows that developers who get called in to support services too often or incorrectly are more likely to leave their jobs, and that’s only going to stall your progress further.
With an accurate service directory in place, it is important to remove the false alarms. Teams must make sure “alerts and alarms” are correlated and an incident is confirmed before you interrupt your valuable time-strapped developers. This involves the right observability and monitoring tools but must also involve strong centralized machine learning augmentation to reduce noise and false alarms. As teams mature, automation plays a critical role here. First, by cutting out the common diagnosis and investigation steps that can burn minutes or even hours. Then, reducing escalations to developers (by over 50%) by putting common resolutions in the hands of first responders or even customer service teams. These collections of technologies are commonly referred to as AIOps and as digital business scales, they become a foundational requirement.
Today’s digital ecosystem is more advanced and more complex than ever before. Maintaining quality digital services is not just a competitive differentiator, it’s the backbone of your corporate reputation. Recent high-profile outages and cyberattacks have catapulted the fragility of the software supply chain into the international spotlight, meaning the margin for error is slim. Resolving issues proactively and in real-time before they impact customers is critical.
Transparent accountability and decentralized ownership ensure that teams have a deeper knowledge of issues when trouble strikes and can take swift action. Revealing to technical teams and developers the direct impact they have on business outcomes enables high-quality, innovative code that delivers on its promises.
As more organizations focus on digital transformation as the centerpiece of their growth strategy, software developers and IT teams are under heightened pressure to perform—quickly and efficiently.
That begs two questions: Can we do better? And if so, how can we do better?
The answers can be elusive, especially for DevOps teams that have over-relied on processes and models that, while previously successful, may not be as relevant for today’s projects. Of course, the point about relevance has been further magnified during the pandemic, when sudden shifts to remote working left many teams scrambling to ensure they had the capacity and infrastructure to support massive work-from-home cohorts.
Software development and IT operations support teams that are winning by doing better in this new era are truly embracing Agile. And that means taking to heart the definition of “Agile,” which is a mindset of values and principles to continually evolve your way of working (WoW) to ensure your productivity and value are tailored to fit the tasks at hand.
Conversely, teams that have relied on their go-to framework or approach for every assignment are often missing the boat with respect to efficiencies, effectiveness and even ROI. This is because they aren’t assessing whether their proven WoW is useful for their current projects.
That can lead to underwhelming results. A report from Digital.ai revealed that while over 90% of software development teams take an Agile approach to their work, a whopping 96% of their digital transformation projects have failed or been delayed. Clearly, that suggests Agile has worked for them in the past, but the nature of digital transformation projects is calling for teams to adapt to new or hybrid approaches that may differ from their go-to WoW.
While there is no quick fix to attain true flexibility amid complexity, the journey begins with the recognition that, yes, you can do better. And to do better—to become an adaptive, lean, responsive and learning organization under any circumstances—there are a number of steps to take to ensure your journey to Agile freedom is successful.
Here are five that I believe must be considered for DevOps teams to become better and more effective:
In the long run, the framework or approach you choose isn’t as important as your willingness to be open-minded in applying Agile frameworks to projects on a case-by-case basis. As you become more comfortable with new or different approaches, you will promote continuous improvement through carefully considered experimentation.
That means you’ll become a learning organization, one that is open to change and evolution. With that mindset, your development and IT ops team will do better—guaranteed. Because true agility comes from freedom, not frameworks.