Software development is undergoing a revolution. We’ve reached a critical period in which development, operations and business teams are coming to a head. There’s hardly a company — a successful one at least — that isn’t relying on software, meaning that software quality, security and efficiency are increasingly becoming essential to running an effective business.
For organizations that have been around for decades or longer, it means they not only have to funnel investments into technology innovation, but they must also modernize and maintain their existing software systems. This presents a challenge for IT budgets but also for recruiting top developer talent. Why would a top-performing software engineer want to work on refactoring old stuff when they could be contributing to the future of self-driving cars or digitally-connected cities that help us live better lives? But what if the constraints of working on antiquated systems foster a new innovative approach to suppress this burden for the generations to come?
Enter self-healing software. Just a decade ago, the tech community was abuzz with excitement over the possibility that a software system could use advanced logic not only to identify its own failures but also to automatically fix them with little to no human intervention. Apply self-healing software to today’s world, and relying on the technology to ease and simplify software modernization becomes an interesting use case.
The self-healing concept has progressed in the infrastructure world to prevent things like cyberattacks or widespread system outages that can cause disruption to customer service. Data centers are commonly equipped with fail-over instructions to automatically keep operations in service, and corporate networks have firewalls sensitive enough to detect malicious activity that doesn’t follow regular protocols. Containers and cloud services go one step further to keep applications and services from failing in case there is a sudden increase in the number of transactions, for example.
We believe the next step in self-healing is applying it directly to source code to aid in software development and improvement initiatives.
Consider IBM Israel’s SHADOWS research project, which published results back in 2010. The initiative proposed to remove a big hurdle of modernizing and fixing old software, which traditionally calls for engineers to spend hours manually sifting through old code and act only when they detect something has gone wrong. The idea was to emulate how the human body behaves and apply those principles to software. While the project worked “from the outside” with no modification of source code, the full potential could only be achieved if developers still took the time to “stuff” the code with instructions to direct SHADOW for quicker and better diagnoses.
The team’s work was certainly promising, but it was too costly and too early for the market at the time, particularly when offshoring was at its height and workforces in countries like India were expanding to maintain legacy software. But seven years later, the situation has changed. Offshoring costs is not as effective as it once was, and the business world has changed to become much more agile. Companies are more accustomed to handling quick changes across all levels of the IT system, from the front end to the back end. Now just might be the right time to reinvestigate the concept of self-healing software.
Regardless of your team structure or current development process, start on the path of self-healing by following these three steps to relieve pressure on maintenance efforts and give developers more freedom to focus on innovation:
1. Identify ‘Disease’ At The Source Code Level
Step one in the self-healing process is to identify patterns that are prone to creating insecure applications or introducing weaknesses into the application. These are often difficult to identify on the front end because they are revealed only once the application is in production and under pressure by users. Community-sourced organizationslike MITRE’s CWE and the Consortium for IT Software Quality (CISQ) have established common languages and standards for measuring software quality that will help get you started. Establishing a baseline of system efficiency, resiliency, maintainability and security is the foundation of building self-healing software.
Once these measures are established, teams can start adding systematic measurement to do trend analysis and identify common causes of application failures and service disruptions. This will also pave the way for machine learning to further automate pattern analysis and predict system failures based on a growing and accurate repository of root causes for bad code.
2. Divide And Conquer While Keeping The Big Picture In Mind
Teams that have already started to implement microservices (which involves breaking applications down into smaller and more easily changeable components) will have a much easier time implementing a noninvasive self-healing process. However, at some point, these components must be put back together to form a fully-functioning application. Using system-level analysis as a quality gate before putting a self-healed system back into production will help guarantee that new software defects or bad code will not make it back into the system. Another way to think about system-level analysis in this case could be creating an architectural blueprint before going back into production.
3. Use Self-Healing As A Springboard For Innovation
Incorporating the automation characteristics of self-healing can help establish the basis for additional innovation within your organization. For example, programming software to self-report irregular activity or logic that doesn’t follow a set of rules could streamline efforts like cloud migration. Currently, the act of migrating software applications to a cloud environment involves a separate analysis and rework of code to ensure the application will operate correctly in the cloud. Imagine if these cloud-ready apps could self-analyze and proactively tell the development team what needs to be fixed prior to migration. This could save countless man hours and prevent business disruption throughout a cloud transition.[“Source-forbes”]