By Martin Atherton, 12 August 2008 16:56
COMMENT
Few outside the IT department realise just how much effort goes into making sure systems don't fail. If more board members understood that, we might see a greater business emphasis on robust systems, says Martin Atherton.
Software resiliency has been a challenge for so long many organisations just accept it as part of using IT. But there is no need for that inertia - there are a number of steps organisations could take to reduce failures.
Exclusive column: The Naked CIO
See what this CIO really thinksÂ…
The Naked CIO: Why boards get IT spend so wrong
The Naked CIO: Tech's weasel words
The Naked CIO: Poisoned BlackBerrys
The Naked CIO: Enemies of the state
The Naked CIO: Service level disagreements
The latest research from Freeform Dynamics discovered 24 per cent of organisations suffer disruption caused by software failure every week. A further 33 per cent said once per month.
The worst kind of disruption - with financial or legal repercussions or resulting in damaged reputation - is suffered by 20 per cent of organisations at least once per quarter. Some 1,200 IT professionals took part in the research.
Organisations are aware of the issue, if not its scale. Research has shown repeatedly that organisations rank IT high on their list of business risks. Indeed, system downtime comes second among the factors most frequently considered in formal risk planning.
Given those facts, why are so many organisations gambling with software systems availability?
First, the accepted inevitability of software failure is not really good enough for modern business. The statistics certainly suggest scenarios that no business would consciously accept.
It is more likely that organisations have little idea of the effort required by their IT department to deliver the levels of service they are used to.
A second reason is that software resiliency is not given the consideration it needs as a business requirement during the application development lifecycle.
So can the business help address this area? Furthermore, is it a business issue anyway?
The answer to both questions is undoubtedly yes. The IT department is tasked with the operational management of software applications but it is the business that suffers when they fail.
Opportunities exist for the business to contribute in several places. Research suggests it is not aware of the relative importance of the tools it uses - the applications and processes - to its business goals.
In addition, green computing among other things is bringing IT service-based accounting closer. The specific attributes of services delivered by IT will soon become very relevant. The business needs to get a head start and work out what's really important.
The next opportunity for change is at project level. Typically, a software project takes an idea or requirement through specification, development, testing and roll-out. By and large, resiliency is an after-thought and does not figure highly when it comes to budgetary planning.
Obviously, the business has a say on functionality, timing and audience. It should also be able to give guidance on the relative importance of a software application to the business. Then, requirements for stability and protection can be factored in instead of assumed or, worse, ignored.
Introducing the topic of resiliency early in a project lifecycle would be a major change for most organisations. But from a practical point of view it should be an easy one to make. It would also go some way to reducing the frustration that exists in the IT department. Operational IT teams often feel their views are only taken into account after a software failure.
Furthermore, research shows a strong correlation between the consideration of resiliency early in a project and reduced software failures. They are more likely to find their way into budgetary scoping too.
The level of software failure is likely to remain high until knowledge and experience from the operational IT side of the business is captured and acted on more effectively.
The business is the primary beneficiary of software systems robust enough for their designated tasks. It needs to become a stronger advocate for the role that operational IT can play early in the software lifecycle.
If it does not, it will continue to experience the software resiliency it deserves.
Martin Atherton is principal analyst at Freeform Dynamics.
Comments
There are 2 comments. Join the discussion
1. A Network Guy
I fully agree with this. Far too often is the request to get the functionality live 'ASAP'. Then guess which department gets it in the neck because there is no resilent procedure in place when something unexpected happens.
PS. Was the real intention of this article to see if you could make the Naked CIO's head explode? :)
(See the Tech's weasel words article if you don't get the above...)
2. Dustin McNabb
Even with the best designs and most careful plans, well-built production business applications can deteriorate in quality over time as fixes and enhancements are applied. So, while IT service quality improvements can be obtained through better development processes and technologies, process and technology improvements need to carry through to today’s IT operational environment as well to achieve long-term IT service quality improvements.