Business Continuity as a Systems Development issue.
Published:
Content Copyright © 2009 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt
I was rather interested by a press release from the Chartered Management Institute (CMI) today, about its ‘A Decade of Living Dangerously’ report (published by the CMI and Cabinet Office). It points out the usual failures in Business Continuity Management (BCM); which is, as I see it, an aspect of Corporate Governance (and it relates to IT governance, since most businesses depend on software these days). Just three of many failings identified are:
- Poor protection: just 38% have a plan in place to cope with disruption and 1 in 3 don’t bother testing plans if they have them
- Weathering the storm: 35% of business are worried about extreme weather, but just 16% of organisations have plans in place to continue work in poor weather
- Possessions not people: Employers in the manufacturing sector seem more concerned with protecting physical assets such as IT (30%) than they do their people (17%).
But why am I interested in all this, as a Practice Leader for Development, which means IT systems development, at Bloor? Well, because I think businesses want us to develop holistic business systems these days, not just pieces of software. This isn’t to say that IT developers should do everything but they should look at the “business outcomes” when designing an automated system. So, in the context of the above points:
- The analysis for a new automated system should look at the associated risk profile, associated with its use in the business. If it is “business critical”, existing business continuity procedures should be reviewed and changed requirements (or increased risks) flagged to the appropriate people.
- If extreme weather is a recognised risk to the operation of the business, then perhaps a system design should take account of this and design in a capability for (well-governed) home and distributed working.
- The model for an automated system must include the manual (people-based) processes around the automated process—if a business outcome is to be guaranteed. For instance, if the design of a financial system is well-secured in a technical sense—strong encryption, robust identity management and so on—then criminals will be forced to target the people involved (we’ve already seen cases of managers’ families being taken hostage and used to force someone to give them access). Unless the system design includes coercion procedures and similar provisions, that discourage the targeting of people, the system’s security is compromised (not least because if you are seen to be putting staff at risk, they will soon stop taking your security policies seriously).
This focus on “business outcomes” is not new, of course—it is a fundamental tenet of here (pdf file). It deals with the practical state of BCM in the UK today. BCM is “based on the principle that it is the key responsibility of an organisation’s directors to ensure the continuation of its business operations at all times” (quoting the report) and I think that IT systems design has a key part to play in implementing BCM.