A process is a plan for action put into action. A process can be classified as a system. It is something with functioning, purpose, structure and boundaries. While purpose is the essential characteristic of any system, providing the context for the other elements; the emphasis for a process is on the functioning. The purpose, structure and boundaries are assumptions to the system (held relatively stable or constant), and a process is defined by the transformation by the system on its inputs and outputs, as well as within the system itself.
If a process is a system, then what is a plan? I assert that a plan is also a system, and that the purpose of a plan is to guide the actualization of a system; that is, to put a system concept into operation.
For any plan to be a guide, it must precede the system itself. It must come before in some ordinal sense. It must be assumed, or act as an assumption to the system itself. The concepts of ordinality, priority and (ultimately) serializability are central to my praxeologic schema of pursuing value. Far more important than I want to justify here.
I’ll exclude for the moment the terminology that accepts “plan” as the documented schematic or description of a system as it exists (or as-built; as if on a plane or flat surface). This is the origin of the term, but in a break from my usual “etymology shows cultural corruption of communication” crusade; I accept the use of plan as a scheme of action which has largely overtaken plan as a flat drawing to the extent that technical parlance has moved onto similar terms like planimetric or schematic to describe what would otherwise have been simple “plans” centuries ago.
Used here by me, plan requires description before actualization…or more compactly “the” design concept (or model) for a system. Axiomatically, plans are a precursory given for a system.
In this sense, a plan’s primary function is to encode, memorialize, or serialize a representation of the system in such a way that the plan can be used as input to an assumed reader-processor of the plan to produce the system’s functioning and generate the desired output. A plan should: include assumptions that define boundaries of inputs and outputs; describe how parts of the system are structured and interrelate; and show how the dynamic internal changes (processing) and externalities (functioning) transform the system itself or its environmental resources and product.
In this above sense I’ve partially unrolled, software becomes the plan for a running process. Software defines how general purpose processors (whether they are CPU, GPU, PLC or FPGA, or the like; all being “general” in some sense) should respond to particular inputs and consume environmental resources to perform internal state changes generating externalities of output for purpose. The scales and lifetimes of these processes may vary from blocks of code and class instances, through libraries and frameworks, to service hosts and networks of interconnected systems; but they are all software in some sense.
I specifically focused on this sense of plan because I wanted to emphasize not the artifacts of a software “development” process (the source code, “binaries” or script-files, etc.), but the purpose of software itself: describing how a process should function before the process itself is actually functioning. Software is the plan for running an (automatic or self-governing) process.
Pursuit of Value 