Business Continuity with your Software Delivery Pipelines

We are certainly facing challenging times as a society throughout this global health crisis. The only time I’ve been exposed to a Business Continuity Plan was when my business travel was limited to two corporate people being on the same flight.

Business Continuity Plans, or a BCP, is required for regulated industries and governmental organizations. BCPs focus on the entire organization vs just the uptime of your IT system which is more focused on in a Disaster Recovery plan. To implement a BCP, you need an inventory for a baseline then analysis around strategy. 

The 1,2,3s of a BCP

If you are green to a Business Continuity Plan, heading over to ready.gov has a pretty good primer on BCPs. A Business Continuity Plan is just that, designed to keep the organization going. BCPs are certainly methodical and designed to limit emotional decisions in times of crisis. For example, airline pilots have Quick Reference Handbooks [QRHs] which are check-lists of necessary practices to run during an emergency to make sure no steps are forgotten which are the ethos of a BCP. 

Designing your BCP starts with taking inventory. You don’t know what you have to continue and protect unless you have a good idea of what you have. Software assets can be hard to track as we are constantly spinning up and down services and crossing potentially multiple cloud/infrastructure providers. Organizations could potentially have an IT asset management [ITAM]  approach for classifying applications as assets but the inventorying the underlying infrastructure to application relationship can be challenging.  

The analysis portion is where the bulk of the BCP will be drafted and ratified. Impact analysis/scenarios are the meat of the overall BCP strategy. Like a Mean Time to Recovery [MTTR], the Recovery Time Objective [RTO] is a primary metric during the impact analysis. Your RTO is the maximum amount of time to recover after a disaster scenario. Organizations will design your strategy to meet an RTO. For software systems, this can be potentially changing infrastructure / bringing up a DR site to even limiting/prioritizing applications and requests. 

BCPs are designed to handle the chaos that is out of our control or disaster scenarios not thought about when going about our tactical day-to-day activities. The Harness Platform can help with your BCP goals. 

Here’s 3 ways Harness can help you with your BCP

Many of Harness’s clients use the Harness Platform as a system of record of their applications since we are the platform orchestrating the deployment/release process. First is taking inventory of what you have is easier with the Harness Platform with the service inventory dashboard. In the service inventory dashboard can tell what infrastructure your applications are deployed on. 

Above and beyond taking inventory, Harness integrates with popular ticketing tools such as Jira and Service Now so not only the tangible IT assets are easily trackable but also the change control process and rationale is there and trackable for the deployments. 

Second, the Harness Platform abstracts away infrastructure so a multi-cloud deployment is as easy as deploying into your own data center.  The Harness Platform abstracts most of the pieces you need in a pipeline with our CD Abstraction Model.

As a testament to the ability of Harness to support this pillar, we ourselves moved public cloud vendors in 76 minutes from soup to nuts. A pillar of a BCP is the ability to re-platform as needed.

The CD Abstraction Model allows you to quickly piece together the needed confidence-building steps and infrastructure for a successful deployment. 

Third, the Harness Platform provides convention-based ways to confidently deploy and with clearly defined convention on when to roll back when there is a problem. With the potential loss of institutional knowledge during a BCP triggering event, judgment calls around roll backs or even promotion of deployments through environments could be lost; Harness provides a systemic resource for the institutional knowledge.  

Rollbacks can be a breeze with the Harness Platform, for example, one customer testimony where a production roll back took only 32 seconds. The investment in being prepared with the Harness Platform can help mitigate unforeseen risks that BCPs might exclude, the future of making changes in your applications. 

Preparedness

If we take a look at IBM’s Tiers of Disaster Recovery, clearly we would all aim for the highest tier “highly automated, business-integrated solution”. Our applications should be so automated that there will be no interruption in uptime. That is much easier said than done. 

The goal is great but pulling off is complex and that is why a “highly automated, business-integrated solution” is the top tier out of several tiers. The infrastructure and platforms to allow for hybrid cloud workloads are usually pretty complex. Ironically those systems become a single point of failure in themselves in a BCP as it requires a pretty sophisticated skillset to create, administer, and maintain. 

Eventually, a person will have to intervene and make some sort of change. If the new resource has limited experience in the platforms that he/she is interacting with, not impossible to learn but will certainly take time and potentially make changes that experience would have known not to make. Disaster Recovery plans can be pretty baked to recover uptime but to recover the ability to make change is a challenge and at Harness, we are poised to help. 

Business Continuity + Harness

Let’s take a look at a somber occurrence that is currently happening to our travel industry. 

There are a flood of requests in the travel industry that travel organizations and providers have to process. For example, airlines are waiving fees, etc to cope with the global event. Though that requires changes in features in systems that the airlines have invested in over the years which typically levy a charge for changes. Adjusting your business rules in your application platforms might not be an obvious area for planning in your BCP to meet your RTOs.  

Harness as a platform is designed to deploy and release applications of all sizes and varying stacks with convention and consistency. In this example let’s say the resources who are most familiar with deploying to an airline’s billing engine are in a reduced capacity and another set of engineers step up. Designing the change to remove the billing rule might not be hard locally but deploying to the production systems that potentially process millions of requests is where the skill would fall short. 

The Harness Platform can help democratize those deployments so someone with budding experience in the deployment process can pick up and move forwards to a successful deployment. A release/deployment can have several disparate steps. Even under an emergency release scenario where certain approval steps are skipped, getting feedback if a deployment is successful can be stressful especially for someone running the first time.

As additional strain is put on infrastructure, moving to a more available or performant piece of infrastructure will occur more rapidly. Harness is committed to you and your organization to continue to foster a democratized delivery pipeline. 

Harness is here to Partner

As the current global situation continues to take its course, many more organizations big and small will be formulating or strengthening their BCPs. Harness is here to help partner with organizations of any size and vertical. 

Applying different deployment strategies and targets is easy with the Harness Platform since we abstract away the infrastructure provider. Moving from specific data centers to different cloud vendors is a simple change in a Harness Pipeline. Lastly, since the Harness Platform is easy to consume and convention-based, if you had to pick up a deployment for a co-worker the learning curve would be very quick. 
‍