As a developer, you have likely experienced expedited product launches, continuous feature releases, instant patches, and a host of other software innovations. But amidst all these disruptions, the expectation for you to maintain velocity and security only keeps growing.
This post was originally published in DevOpsDigest
The “Shift Left” approach is the outcome and epitome of this accelerated pace of software development. In this instance, tests and validations are conducted early in the development cycle to arrest any risks associated with software quality. This post will unravel the opposite (and perhaps obvious) “Shift Right” concept to understand its implications on the software development lifecycle and its approaches and benefits.
Why “Shift” and in Which Direction?
The “Shift” refers to a variation of the SDLC progression, in which certain phases are shifted to achieve better testing to improve software quality. However, to fully understand this relation between the shift and quality, we need to look at how the perception of software quality has evolved over the decades.
Traditionally, software quality was measured as the degree of compliance with a set of formally defined requirements. This approach was prevalent in the waterfall model. Developers emphasized achieving 100% requirement traceability with adherence to coding standards.
But today, software requirements are defined informally as a general explanation of features. Developers work with vaguely defined features, which are improved upon through a series of iterations. Also, the scope of software quality has widened beyond the requirements and coding practices. It extends to deployment behavior since most software applications are deployed as a service in a cloud environment. Therefore, the availability of service and a reasonable response time are also part of software quality.
Due to these ever-changing perceptions, the modern SDLC approach under Agile needs a multi-dimensional checkpoint to tackle feature requirement expectations and meet the service needs as part of every release.
That’s where we need to shift. The “Shift Left” improvisation allows development teams to perform tests earlier in the SDLC to mitigate requirement ambiguities. The “Shift Right” approach mandates extending the tests into production to handle deployment and service uncertainties.
The Rise of the “Shift Right” Methodology
In the Agile approach that is prevalent today, the SDLC is a continuous DevOps cycle, split between development and operations functions that work in conjunction to release one incremental feature or change in the software.
There’s no requirement analysis phase here. Instead, requirements are drafted on the go as general feature overviews and a sequence of user actions constituting a set of user stories. All of it happens in the planning phase. Non-functional requirements are tracked as part of the ops to ensure deployment service quality after every release. These include response times, service availability, and security-related parameters that control user and data access. The “Shift Right” strategy entails extending the testing across ops to address these service quality issues.
Similarly to “Shift-Left”, this is also an SDLC process improvisation. “Shift Right” focuses on testing the non-functional quality metrics within the production environment to ensure optimal service parameters for the deployed software.
Should We “Shift Right” Our Approach?
“Shifting Right” offers numerous benefits for organizations. First and foremost, it builds a forward-thinking, proactive process culture that focuses on software operations and deployment challenges rather than development challenges. This culture change is achieved by leveraging and combining a few technology interventions with automation, resulting in closed cooperation between development and operations teams.
One way of achieving “Shift-Right” is to let the developers take the responsibility of analyzing the runtime performance of software directly in production. This approach relies on innovations around dev tools to allow developers to scan, monitor and observe the production runtime environment. Additionally, these tools enable ops-free interventions for developers to reduce manual overheads, reducing the code rework or bug fix cycles.
Another way to achieve “Shift-Right” is by replicating the production environment into staging, debugging, or other temporary runtime environments. This technique leverages cloud-native technologies to replicate cloud environments instantly. As a result, it eases the time-consuming tasks related to testing exceptional deployment scenarios such as chaos simulation, heavy user traffic, and security attacks. In addition, it allows developers and testers more time for experimentation and continuous learning.
Overall, the “Shift-Right” approach helps teams deploy software products with consistent service quality while keeping up with newer feature additions. As nearly all software is offered on an “as-service” model, we are seeing a significant paradigm shift in SDLC to reduce overhead costs of production bug fixes, leading to reduced MTTR.
Towards a Harmonious Shift
“Shift-Right” can co-exist with “Shift-Left.” They are not mutually exclusive. Both shifts complement each other by spreading the testing responsibility across the entire SDLC process to address a software system’s most pressing quality concerns: requirement compliance and service consistency.
However, developers also need to meet stakeholder and customer expectations beyond the technical and quantitative parameters of the software requirements. These expectations are qualitative in nature and are mostly expressed in terms of physical and mental effort, such as developer burnout (on our side) or dissatisfied customers (on the flip side).
Addressing these expectations requires a “Shift-Up” approach, which aims to measure the commercial performance of the software and associate it with customer interactions.
In essence, the “Shift-Up” acts as an umbrella supervision layer over the SDLC process that intelligently captures the software’s business and user interaction parameters. Plus, it loops into the development and operations teams to incorporate the feedback into the “Shift-Left” or “Shift-Right” processes stages.
If you get this far, it is safe to assume that your SDLC process is operating at an optimal level, which takes care of the software quality, ensures good service health, and, most importantly, is loved by customers.
