Reducing Support, maintenance and QA Costs (RTB) with Self-healing software

In the recent past organizations always focused on efficiency and effectiveness. This in turn put a lot of focus on time to market and productivity however the quality and consistency aspects of any software delivery somehow always took a back seat.  A focus on time to market is extremely important to be an early adopter and reap benefits of market leadership and revenue share. 

So many delivery teams are forced to select either one and oftentimes sacrifice on quality and consistency of delivery to customer. Over the years quality was thought to be brought in by encouraging the usage of application development frameworks, library functions, re-usable code snippets, sample design documents, design patterns and so on and so forth. This is the view from a development standpoint.

Maybe the above was not so effective and that is when independent QA/ testing became more popular and many customers adopted the black box functional testing to ensure that the business requirements are properly met as per user expectations.

Despite these approaches code still fail in production, support and maintenance costs are still required and considered as a necessary business operations expense.

The inherent knowledge that is present in a SME is revealed only when he handles specific challenges on production code under SLA/penalties. Given a situation they take certain steps and resolve the issue and sit back and relax. This knowledge somehow is not reusable to others as it could be specific to certain customers, projects or environments and also shrouded in data privacy and legal commitments to the customer. However the question remains how to reduce the RTB costs or cost of software maintenance while leveraging existing knowledge?

One thought to reduce this cost is to design self- healing software?  Is it possible, can software heal itself?

I might have wondered the same if I did not know about self-sealing tyres in the event of a puncture. If a running part like a tyre in a high speed automobile can be designed to heal itself in the event of a puncture, then it should be possible to do the same with software – it should be able to recover itself, diagnose the cause with metadata and execute alternate recovery code to run business as usual parking the exception for a later recovery/resolution.

This metadata is the knowledge that is required to process the event, the physical actions taken by an SME to resolve will be the diagnostic steps. Once the event and steps are captured as actions in a database, theoretically software can be built to heal itself temporarily until a permanent fix is done.

A solid Knowledge Management (KM) program should not try to extract knowledge explicitly, it should capture the actions as meta data then and there as the event or action occurs and is resolved. Neural networks can be constructed that can further learn from the actions taken by the SME.

Suppose we are able to create such a KM diagnostic software on a commercial “ticketing application” as a wrapper, this provides all the metadata required to build the self healing intelligence into the base application that is reported into the ticketing application. The neural network in turn can provide predictive capabilities.

Futuristic applications will soon have self-healing capability. To build self healing software we need meta-data, a neural network and a database that captures SME actions until such time we have enough actions to create diagnostic programs..

This may sound a bit far-fetched but that is what man thought about air travel a hundred years back.