No/Low Touch Automation and Experience
In a previous blog I briefly talked about No/Low Code Abstraction and Programming. The principle of no/low code is “anyone can code”. There is another related trend that is not as viral as no/low code viral but is extremely important: no/low touch. Here the “touch” is “human touch”. The goal here is to eliminate or minimize human involvement in many of the activities. There are two areas where no/low touch are needed: no/low touch automation and no/low experience. In this blog I will focus no/low touch automation.
Let us look at the word automation. According to the Webster Dictionary one of the relevant definitions is the technique of making an apparatus, a process, or a system operate automatically. The word automatic means many things and I prefer this definition for our purpose: having a self-acting or self-regulating mechanism. The adjective automatic or adverb automatically is related to the word automaton which means a machine.
A key question that most of us want to know is “what can an automaton or a machine achieve?’” The answer to this question contains two parts: (1) human thinking and (2) computational limits. Human thinking is what makes us humans. Humans always want something better every day. Necessity is the mother of invention. Well humans have the God given ability or craziness to spend time thinking on how to solve persistent problems, whether the problems are repetitive tasks or curious hard problems. Our body does many things automatically from heart beats to blinking of eyelids; we would not exist if we did not do these repetitive tasks automatically.
Computational limits take automation only so far. For instance, it is a futile human exercise to develop automation that can tell whether a give program that processes some data will terminate in finite time, which involves solving an impossible problem called the halting problem.
Let us see if we can come up with a simple definition of automation. We will use the term bot to indicate that the entity or agent is non-human.
Let P be a process or set of activities or tasks. Let h be a human agent and b a bot agent. We define automation A as a mapping or transformation pb = A(ph) where pb, qh is a subset of P so that some well-defined productivity measure M defined on pb and ph satisfy the relation that M(pb) better than M(ph).
Basically, automation is a transformation or mapping of human activities to bot activities so that we improve some productivity measure M defined on pb and ph.
In no/low code framework the goal is to increase the number of citizen programmers (remember “anyone can code” model). In no/low touch automation the goal is to increase the number citizen bots. But what are these citizen bots. Remember citizen programmers are domain experts who want to code instead of asking or explaining the domain problems to coding experts. Similarly, citizen bots are automaton which are experts in domains and can eliminate humans from doing repetitive tasks. There are many tasks that are repetitive in nature but then are gotchas baked into these repetitive tasks:
- The repetitive task has a drift and when a drift happens, the automation may fail.
- The repetitive task has a shift and at the point shift the automation may not work.
- The repetitive task contains multiple embedded tasks creating a complex repetitive task.
- The repetitive task is triggered based on external events and when the external events fail (say due to network connectivity failure) the automation may not work.
There are many more gotchas that are domain dependent. No/low touch automation cannot be designed later in the development cycle as an add-on to a solution already deployed. All automation follows key principles from Systems and Control Theory. The following figure illustrates the basics of control theory. In open-loop control system there is not feedback loop and so no controllability.
To handle some of the complexity of automation we need to create a no/low touch framework that allows automation builder to create reconfigurable automation. There are three things that needs to come together to build reconfigurable automation: (1) define objectives and key results (OKRs), (2) ability to observe drifts or changes from defined OKRs (observability), (3) control inputs to systems to control or error correct the drift or changes to OKRs (controllability). Controllability is often hard to achieve (or even impossible in some cases). Open loop control systems are simpler to build and when there is non-linear trajectory of the repetitive tasks, we should develop trajectory optimization method. The state-based approach used in Kubernetes are simpler differential convergence between what is expected and what is the current state.
No/Low touch automation and optimization is still in its infancy stage, and cloud computing is providing new capabilities to create citizen bots that will eliminate human touch. Legacy systems will continue to see lot more human touches since automation are created after the fact. It is extremely important, when developing new (cloud-native) solution, to bake citizen bots right from the design phase and not later after the solution is deployed. In API-first approach APIs are treated as first class citizens. There are many frameworks to enable API-first solution. Similarly, we need no/low touch automation and optimization framework that will help solution designers to includes observability and controllability, when possible, into the solution from day zero. Every solution that we develop should have citizen bots as a first-class persona baked into the solution. I am currently exploring no/low touch automation to help our clients.
