Business continuity – the art of keeping the business in business – is nothing new. But how is business continuity affected by newer approaches to IT management such as Agile and DevOps? And how should organizations be adapting their traditional business continuity capabilities in light of these approaches?
Why do many organizations know that without fit-for-purpose technology they would not exist, and so introduce Agile or DevOps methods, but still fail to ensure that their new practices help to ensure that their technology is available in all circumstances?
And why is it that ensuring 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?
This blog looks at how business continuity capabilities need to change in light of the impact of Agile and DevOps.
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 already 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.
But why isn’t integrating the potential impact of Agile or DevOps into business continuity practices always considered a sound and highly-valuable idea? I think it is. So please read on for more on why Agile and DevOps also have a part to play in this IT discipline too.
Maintaining business continuity in your organization:
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.
Which is great. But if you mapped the processes used inside a department, you might find that they 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.
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:
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:
Step it up with the “killer” questions:
As I already 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:
And thus, you will need to:
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 lifecycle.
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 need to become part of any development or testing framework or infrastructure.
Ultimately, it’s important to sufficiently invest in keeping your business in business! DevOps practices is another element to factor into your organization’s business continuity management policies, processes, and practices.