OpCon 18.1: Autonomics for a healthy business

Around the turn of the century, Autonomics was all the rage in computer software, and I was a passionate believer. I’ve also been obsessive about automation since getting into programming in 1980 with a program that played a card game called Whist and later building a full simulation of a sausage production line. This was used by engineers to model the real production processes and enabled them to tweak parameters to see what would happen. I was aware of boundary conditions and set limits on inputs, otherwise, I could easily create a scenario that had no meaning in the physical world. Later I developed quite a few numerical analysis solutions, and then an enterprise scheduler became my first paid programming assignment. I believed that whatever program I was writing should never fail and should make intelligent decisions whenever possible. In my mind, the program was only finished when it was self-contained and easy to use. If something happened like a bad input, and the program couldn’t complete, that was OK in my young mind so long as the program tried to correct it and manage the situation. I also wanted the screens to be intuitive, have as little text and inputs as possible and not consume the user’s brain trying to work out what they should be doing. In short, I wanted autonomics, but I’d never heard that term. I guess I was not unique in these desires.

These early beliefs and impulses crystalized and became real driving forces behind the enterprise software products I was writing, and without realizing it I was designing and building autonomic software products. Eventually, the software industry caught up (wink), and autonomics was all the rage. IBM almost owned the term and issued a detailed description covering self-configuration, self-healing, self-optimization, and self-protection. It was an exciting time in software development, and autonomics pointed to the future resiliency of cloud. The breadth of autonomics rapidly expanded to include such things as self-learning, and the number of self-isms grew to 11. These are still the pillars of autonomics and should be a foundation of enterprise-class software if not indeed all software.

Unfortunately, I rarely hear the term now except in conversations about the human body or nervous system. Debating with a medical friend, I recently learned that mother nature invented autonomics billions of years ago. In the body, autonomics is constantly active in regulating things such as breathing, metabolic processes, and heart rate. Signals from all kinds of different sensors within our bodies provide the information and the involuntary nervous system issues instructions. For example, if we get too hot, blood flow is increased to the skin that helps cool us down.

In SMA’s latest release of OpCon, we took another interesting journey down the path of business autonomics. Service Level Agreements (SLAs) are frequently used to measure business or IT services against agreed levels. Logically it’s important to know if you are not getting the service you paid for; however, waiting until the service is over is not ideal. You really want to know in plenty of time, so you have a chance to make corrective actions. With the new self-optimizing SLAs in OpCon Vision, you can be notified if a workflow is going to be late to start or automatically adapt processing. Perhaps by directing print jobs to a backup device, delaying non-critical processes or failing over in extreme cases. The point being that these autonomic actions adapt and protect the critical processes to keep your business healthy just like human autonomics.

It’s easy to overcomplicate technical subjects, so I like simple explanations. Autonomics is essentially a system that is automatic, adaptive and aware. I now like the explosion of data and IoT sensors and information as the inputs which systems should use to provide far more autonomic applications and systems and indeed many have appeared. The growing complexity of business and IT ecosystems almost demands a higher level of intelligence, and I think it’s high time we really focused again on autonomics. Pure automation is great for controlling and responding to failure, but adapting to failure is stronger and more resilient, and is less likely to have cascaded failures which are almost inevitable with unbridled automation. Perhaps this is the end game for intelligent automation, perhaps extreme automation really needs autonomics.