perspective Software resiliency has been a challenge for so long many organizations just accept it as part of using IT. But there is no need for that inertia--there are a number of steps organizations could take to reduce failures.
The latest research from Freeform Dynamics discovered 24 percent of organizations suffer disruption caused by software failure every week. A further 33 percent said once per month.
The worst kind of disruption--with financial or legal repercussions or resulting in damaged reputation--is suffered by 20 percent of organizations at least once per quarter. Some 1,200 IT professionals took part in the research.
Organizations are aware of the issue, if not its scale. Research has shown repeatedly that organizations 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 organizations 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 organizations 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 organizations. 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.
Play video
Are your systems falling down on resiliency?
I see it two ways. One is the level of IT person's knowledge will directly effect a networks lifespan due to their purchasing and skill level. But the flip side is the poorly written code for alot of niche and non niche software. Some software failures I have seen are with large name vendors that are updating a product after microsoft alters a code "for security" reasons causing the other software to fail or become unstable. You can see more examples at techdeuce.blogspot.com
Posted by TD on Saturday, March 28 2009 11:58 PM