Have you ever stopped to consider how business continuity could be affected by newer approaches to IT management (ITSM), such as Agile and DevOps? If you stop to think about it for a minute, are organizations that have introduced Agile or DevOps methods missing a trick by failing to ensure that their new practices also help to ensure that IT and business services are available in all circumstances? And why is business continuity sometimes only considered important after the fact, i.e. once the worst has happened?
To help your thinking around this, this article considers how business continuity capabilities should change in light of Agile and DevOps.
Keeping Up with Business Change
Your organization’s business requirements are probably changing rapidly. The annually-refined strategic plan of old is now probably out of date within a quarter. With Agile and DevOps practices adopted to help resolve complex business issues through technology improvement at speed while still providing an increased certainty of intent, quality, and safety.
But what about the impact of Agile and DevOps on business continuity practices?
I’ll start by getting us on the same business continuity page.
A Quick Business Continuity Overview
Your organization’s business continuity policies, plans, and practices should:
- Provide it with the ability to adapt to meet competitive, regulatory, organizational, technology, or new market opportunities
- Provide its stakeholders, suppliers, customers, and staff with the assurance that it will remain a “going concern”
Both of which are great.
But does your business-continuity ecosystem really understand and reflect the status quo. For example, if you mapped the processes and key technologies used inside a particular department would it be more “complicated” than previously thought? Perhaps you might discover that they download data from a corporate application, port it into Excel or another tool, and then manipulate it for their own purposes. This is the “real work” and if this data is lost, the business continuity impact might be severe.
Applying DevOps to Business Continuity and Vice Versa
The Agile and DevOps methodologies promote that your organization designs, creates, tests, and releases technology changes in rapid cycles of two weeks or less. Which is great. But is your organization keeping up with the fact that any technology change will probably have a business-process, and thus a business-continuity, impact?
Then the flipside is how is business continuity steering DevOps activity? For instance, for business-critical applications/services, whatever’s released needs to be ready for production. But how do you provide such assurance? This is one way:
- All “epics” – the high-level business requirements that have been broken down into smaller “stories” – should also include a simple statement highlighting the business impact
- All user stories should include tests to confirm the work is as-requested and that it would be usable no matter where needed, with feedback provided to the development, infrastructure, and cloud provider teams, plus the product owner, on the success of the tests
- All issues should be resolved before the work/change is released, with the issues and other lessons forming part of the backlog of new work
- If a continuity test has not been performed, then the user story is prioritized for near future sprints
Asking the Right DevOps Business Continuity Maturity Assessment Questions
There’s a quick way to understand how well your organization’s business continuity capabilities stack up in the context of DevOps – just ask a number of focused questions (but please ensure that these are asked to people who should be able to provide the answers).
You can start by asking:
- How often do you test your code as you create it? (“Oh yes, we always do that”)
- Do you always test before you go live? (“Oh yes, we always do that”)
- How many of your developers create their code in environments that replicate, as close as possible, the production environment? (“Hmm, no our environments are all different”)
Then take it up a notch with two “killer” questions:
- How do you ensure that releases are “safe”?
- How do you know that business operations will not be adversely affected by the change or that the likelihood of a business continuity situation is zero?
Understanding Your Organization’s Reliance on Technology
Business continuity is ultimately about keeping your business in business!
Thus, there’s a need to truly understand how its technology is employed to support different aspects of business such as:
- The required access to your products or services
- Competitive advantage
- A safe place for your people and suppliers to work
- Regulatory compliance
To do this, follow the following four steps:
- Map the various value streams of performed work across your organization
- Map the technology used, including each business function’s workstation applications
- Assess the impact of each stream being blocked, or unavailable, by technology issues
- Create a plan to make that value stream as available as required (by the organization)
Ultimately, it’s important to invest in keeping your business in business! With your DevOps practices another element to factor into your organization’s business continuity management policies, processes, and practices.
Sarah Lahav
As SysAid Technologies' first employee, Sarah Lahav has remained the vital link between SysAid and its customers since 2003. She is the current CEO and former VP of Customer Relations at SysAid, two positions that have given her a hands-on role in evolving SysAid solutions to align with the dynamic needs of service managers.
