Typed up this post to provide background reading for my coming talk on Systems of Action at the Saturn 2015 conference.
For years, if not decades, one of my professional passions has been to answer the question: How to create software systems that actively support operational decision making in time critical domains. At Statoil we decided to call these kind of software systems «systems of action».
The terms «systems of action» originated from a need to differentiate this type of software from record keeping software, also known as «systems of record». In an upstream oil and gas company there are wide range of record keeping systems, spanning from SCADA historians through drilling operations reporting to financial accounting.
Systems of action
Systems of action are by any norm an emerging group of systems that consists of three building blocks. Firstly they can sense or observe a phenomena, process or machine, secondly they can process their observations in search for anomalies, undesired state changes or other underlying deviations that must be dealt with, and finally, they recommend / execute actions to bring the observed phenomena, process or machine back to its desired operational state. In addition they observe the effects of their actions and are able to re-plan and adapt their actions based on observed effects.
Systems of action will operate with some level of autonomy; they will interact with human operators in trust based collaborations and they can be tasked with missions. Trading robots, tasked to observe market and to buy and sell shares to maximize profit is a good example of a “system of action” implementation.
Other examples include unmanned vehicles and robots such as NASA’s Mars Rover Curiosity and DARPA’s DART (Dynamic Analysis and Re-planning Tool) used for military logistics (supply chain optimisation). Systems of action are built with dynamic models, physical and/or statistical, models with their scientific basis in cybernetics and artificial intelligence research.
To be trustworthy their decision making mechanisms need to be transparent (humans must understand why a specific action is recommended / executed, included its intended effect, cost and risk). They can be fully autonomous, meaning they can be tasked to solve a particular task, but most likely they will be used to reduce the workload on human operators tasked with the control of dynamic high risk tasks.
In the conference talk, we have used drilling as case. The reason for using drilling is two fold. One, it is a domain where such capabilities have meaning and will be very useful. Two, it is a domain that is easy to explain to lay people.
The stack model
One of the challenges we faced talking about the value of system of actions was to have good means to conway their value so subject matter experts understood their potential.
It was in this context the stack model was created. We discovered a need to create a graphical picture illustrating what systems of action offers and how the need to be built with respect to capabilities.
The stack model was the result of this work. So for those attending Saturn 2015, come and learn more about systems of action and their architecting challenges.