A Discovery of Process in Digital Farming: The Operational View
Every endeavor in farming starts with a discovery of process. Before we can do anything we need to know how things are, and must be, done. What is little understood is that the process and the functions that activate it has not changed in the decades, even in the centennials and millennials of time in which that endeavor has been undertaken.
Why, you ask, is this important? It is important, especially today in digital farming, because we start many of our developments with an examination of operational functions and the allocation of requirements to the functions, the elements, of the process in an activity called systems engineering. Systems engineering is itself a process with well defined requirements and functions. These requirements specify the functions to be performed, they flow from other requirements, and they establish the performance metrics for those functions. They are dynamic. However, the functions to be performed are well-defined and have been clearly laid out for decades. Yet with all we know about these functions and have repeatedly codified, every effort starts with a new discovery of process; a new examination and re-discovery of the functions that we need to perform, that we have known for a long time.
What solutions we use to do that process, and execute the functions that make up that process, have changed but what we have to do and the order of precedence of those actions has not. In fact, we have not seen these functions change at any time through those decades. How we do these functions has improved in digital farming, and the tools that we use are more powerful. This is reflected in our requirements. But, the process has not changed. This fact has not been abstracted and connected to the real world of organizations, missions, development, or planning, for example.
In the world of development, the development starts with generating what might be called an Initial Capabilities Document or a Marketing Request Document. It is incrementally a statement of the system need; the functions and their operational requirements. This Initial Capabilities Document is the process or operational view of the mission as amended to add, subtract, improve, or modify a need through its explicit change in requirements. It does not state a solution; rather, it is an explicit compilation of the requirements and the changes. Further, this document is a representation, in textual form, of that architectural modeling called the operational view. This operational view must be expanded to include desired performance capabilities which are the required enhancements in operational capabilities.
MORE BY MICHAEL R. COLLINS
In my previous article, I discussed the transformation from a text model to a graphical model and vice versa. This operational view has been expressed many times in layers of textual description, recursively to the lowest level, hundreds if not thousands of times. It has not changed over time. This operational view is everywhere already. It is in publications, training materials, and other doctrinal materials. Its elements can be abstracted from every document, aggregated to put like functions with like functions, and graphically modeled hierarchically. This links functions parent to children and functions to functions via the output and inputs of those functions.
The graphical model is the pictorial abstraction of the text. By linking the graphical model elements to the textual elements that describe them, we demonstrate the direct correlation between text and graphical model elements. This closes the loop on the effort and validates the model. Ultimately, it closes the loop on the knowledge of the system and with each linkage and each new textual descriptions of the model and its elements, the full intellectual property of the endeavor, i.e., mission, is captured.
In another previous article, I examined another repeatable process. That repeatable process is the OODA (Observe, Orient, Decide, Act) Loop, and it is a highly repeatable mental model that can be used over and over again to establish decision processes and the time frame in which they must occur. OODA is not the only repeatable process. There are many unique mental models that have evolved to support decisions or other functions in the endeavor. The next step in the building of these models and the recognizing of their repeatability is the linking of these in such a way that they are executable and providing measures of effectiveness. These processes are not only repeatable, they are auditable and they can be analyzed, estimated, measured, and evaluated.
In my past, I witnessed several instances of this. I witnessed it when I was researching the amphibious assault mission area. I noted this repeatability and, when I spoke with one of the trainers in this area, his comment was, “We are doing amphibious assault the same way today that we did on Omaha Beach in WW II.” I saw it in my early architecture framework discussions about discussions of operational activities and operational nodes. It showed up in operational planning when we discussed the planning functions to support mobility and logistics. Since then, I have witnessed common repeatable functions at all levels of the operational view of a development, and other endeavors. Most interesting was the fact that the repeatability of the operational model is replicated millions of times a year in digital farming and precision agriculture.
In every instance in digital farming, the processes were identical. This enabled the building of mental models and the translation of these into system models. It enabled decisions, gave timelines to the process, and revealed expected or required actions. It enabled the adjudication of Measures of Effectiveness (a combination of Measure of Efficiency and Measure of Performance) and it enabled decision processes that assessed solutions based upon their Measure of Suitability. At its core, there is a pattern, and it is replicated. It can be modeled, simulated, audited, and reused in repeatable processes.
Recently, I stumbled upon a more unusual and abstract example (Check it out on Wikipedia). Vladimir Propp, a Russian, analyzed Russian fairy tales and he discovered this proposition about repeatability. He uncovered other useful corollaries. Every endeavor, or class of endeavors, shares a fixed and finite number of functions. There is a fixed set of functions; it is not an unlimited set. These functions don’t change. Nor do the lower levels of endeavors, and while every fairy tale (endeavor) may not have all of the lower level functions of the endeavors, they will all share some of those in the finite set. Even more interesting is that these will all enjoy a similar order of precedence. This is like my earlier observation of precedence of functions linked by an output to input relationship. One function will always follow those in front of it. Many even share the same essence or cardinality of function.
Of equal interest is that these are compound functions that occur at any single node. The node becomes an aggregation; a synthesis of, or locus of, functions. When viewed through this lens, modeling becomes a multi-threaded set of functions each with their own orders of precedence. The modeling of this is the foundation for most if not all planning endeavors. The same high level functions must be performed, they are compound in nature, and they are, each, recursive and repeatable. This is most apparent in training materials and mission planning documents. We repeat the same mental models and execute them in similar processes.
There is a lot more that can be said about this ‘repeatabilty’, but it remains to the reader to validate this concept. Then, once it is validated, the reader needs to ask the question, “Why if this doesn’t change and it describes my operational functions; why don’t I have a persistent instance of this and why isn’t it created, managed, and continuously modeled for the organization to use in the evaluation of new business, search for new opportunities, and improvements in IT and system processes?
Subscribe Today For
