Organizational requirements change rapidly. The strategic plan you created in the past and previously only updated annually is now out of date within a quarter.
Agile and DevOps practices have been adopted to help resolve complex business issues in these times of flux through technology improvement, providing organizations with an increased certainty of intent, quality and safety.
However, integrating the potential impact of Agile or DevOps into business continuity practices isn’t always considered a sound and highly valuable idea. The continuity of an organization is often considered important only after a crisis has occurred—the proverbial closing of the gate after the horse has bolted.
Below are a few ways that business continuity capabilities need to change in light of the impact of Agile and DevOps.
First, a Business Continuity Primer
Maintaining business continuity in your organization:
- Provides the ability to adapt as required to meet competitive, regulatory, organizational, technology or new market opportunities.
- Provides your stakeholders, suppliers and, most importantly, customers and staff with the assurance the organization will remain a sound, going concern.
For example, many organizations have a data repository in an application such as SAP, Oracle or SharePoint. This repository is saved into the cloud or other media daily or as needed.
That is great. But if you mapped the processes used inside a department, you might find that employees download this data into Excel or some other tool and manipulate it for their own purposes. This is where the real work is being performed, and if this data is lost, the business continuity impact could be quite severe.
DevOps and Business Continuity
Agile and DevOps methodologies suggest that you design, create, test and release your technology changes in rapid cycles of two weeks or less, with any technology change introduced probably having a business process—and thus business continuity—impact.
Therefore, whatever you release must always be ready for production. But how can you provide this level of assurance? This is how:
- All “epics”—high-level business needs that are broken down into smaller stories—should also have a simple statement highlighting the impact of request.
- All user stories should have tests to confirm the work being performed is as requested but also that they would be usable no matter where needed.
- Feedback is provided to the development, infrastructure, cloud provider and product owner regarding the success of the tests.
- Any issues need to be resolved before the work/change is released.
- Issues and other lessons become part of the backlog of new work.
- If a continuity test was not performed, then this user story is prioritized for completion in near future sprints.
DevOps and Business Continuity Maturity Assessment Questions
There’s a relatively simple way to understand how your organization’s business continuity capabilities stack up: Ask a number of focused questions (to the people who should be able to provide suitable answers).
Start by asking:
- How often do you test your code as you create it? (“Oh yes, we do that.”)
- Do you always test before you go live? (“Oh yes, we do that.”)
- How many of you create your code—be it infrastructure virtualization, new applications, internet, etc.—in environments that replicate, as close as possible, the production environment? (“Oh, hmm, no our environments are all different.”)
Step it up with the “killer” questions:
- How can you ensure that what you’re about to release is safe?
- How can you ensure that the work you’ve done is not a waste?
- How do you know that your organization can be kept “in business” and will not be exposed to an adverse effect from the change, or a business continuity situation?
Understand How the Organization Relies on Technology
As mentioned, business continuity is ultimately all about keeping your business in business, and thus there’s a need to understand how technology is employed to maintain:
- Regulatory compliance.
- Competitive advantage.
- A safe place for your people and suppliers to work.
- The needed access to your products or services.
And thus, you will need to:
- Map the various value streams of work performed.
- Map the technology used at each step, down to workstation applications.
- Quickly assess the impact of that stream being blocked or unavailable by a facilities, people or technology issue.
- Create a plan to make that value stream as available as required.
Organizations that have mature business continuity practices will, of course, also use technology to automate these activities. But they will also ensure that changes needed are tested as soon as possible in the product life cycle.
If your tests are not performed in a production-like environment continuously, then how do you know you are ready and safe to go live? Go-live should not just encompass the new code but also the processes, training, security, continuity testing, organizational change and supplier update, if needed.
Fortunately, the DevOps tools that support these capabilities are readily available and thus need to become part of any development, testing framework or infrastructure.
Ultimately, it’s important to sufficiently invest in keeping your business in business. DevOps practices are another element to factor in to your organization’s business continuity management policies, processes and practices.
