Last update PvD

Process Model

When defining or describing processes, or collecting information about processes, there are a lot of aspects with varying relevance to characterise that process.  It is not obvious how various aspects should be categorised.
This document should provide some guidelines with respect to categorisation on interfaces.  You may choose to extend it with a (sub-)categorisation suited for your environment.

The term Process in this context stands for any process, i.e. an automated process (i.e. without human interaction), a manual process, or a mix of both.

Basic Process Model

Every process obviously requires input, and produces output (one might say it converts input into output).  However, a process relies on services or facilities to carry out its task; these are usually also processes but at a lower level of abstraction.  And, in turn, our main process may provide services to one or more processes at a higher level of abstraction.  So, the basic process model can be depicted like:

The main process interfaces are:

• Higher Level process interface:  receiving requests/­commands/­calls, and sending responses/­notifications/­call-backs;
• Input interface:  e.g. raw material, components, data;
• Output interface:  e.g. products, assemblies, information;
• Lower level process interface:  mechanism, e.g. services/facilities.

As the input and output interfaces are self-explanatory, we will elaborate the Higher Level and Lower Level interface categories.  Note that:

• the interfaces to higher and lower level abstraction levels are similar, though at a different level of abstraction;
• there can be several (process) layers of abstraction;
• the interfaces to higher and lower level abstraction levels are always bi-directional, whereas input and output interfaces are usually uni-directional (regarding information; communication may use a bi-directional protocol to assure that information is correct and delivery is succesful);
• the interfaces between layers are of the client/server type, i.e. requests going down, and responses and notifications going up;
• the lower level resource may come as a cost (you have to pay for it), and not all requests may be met ('insufficient resources').

Lower Level interface

The main process has its own logic, but to carry out its tasks it needs the lower level mechanism.  The process(es) at the lower level provide resources –services and/or facilities– to our main process, and forms the infrastructure for all processes at the level of our main process.

Examples of lower level infrastructure:

Resources

people, components, budgets, organisation, etc.

Procedures

the detailed rules (scripts, instructions, but also the unwritten rules and conventions) how to do a task (at a lower level of abstraction)

Infrastructure/services/facilities

anything to make life easier and the process more efficient.  In general floor space, desks, software, reference data, roads, power, sewer, etc. and in particular equipment (i.e. non-human resources) and supporting departments.  Commonly a general infrastructure is needed with some additional process-specific components (i.e. 'tools').

Computer software

'abstract machines'.

Sometimes the distinction between Input and Resources (infrastructure, non-human resources) is not very clear;  for example tools which are used-up (e.g. expense material like stationary).  Basically Input is consumed and Resources are temporarily allocated.  However, that often depends on how logistics are arranged.  Some straightforward reasoning like "when it is on the Bill-Of-Material, it is Input" may help to categorise.
It also occurs that some part is used both as an Input component and as a tool (Infrastructure), for example a software platform.

Note that the Lower Level Interface is commonly ignored as an interface.

Higher Level Interface

There are 2 types of higher level interfaces:

1. here our main process provides services just like the lower level provides it to the main process.  In this case the interface to the higher level is similar to the interface at the lower level when ignoring the difference in abstraction.
   A characteristic is that the Input and Output interfaces hardly exist;  input is a Request coming from the higher layer, and output is the Response to the higher layer.  Also, there are probably more higher level processes requesting services from our main process.
2. the higher layer interface is a Management interface.  Our main process works more or less autonomous, 'converting' input to output, but is managed by the 'higher layer'.  The 'manager' may instruct the main process to start or stop a task, change priority, set parameters, monitor, ask for a report, etc.
   A characteristic is that the Input and Output interfaces clearly exist at the lower ('working') level, but not at the higher ('management') level.  And commonly only a single object at the higher level manages multiple lower level processes.

Management versus Control

Both Management and Control are used to control the operation of a process.  Management and Control are doing a similar job, however at distinct levels of abstaction.  Control, also indicated as Command & Control, is directly controling a process, whereas Management is monitoring another process from a higher level of abstraction (more from a distance).  More specific:

Control

The internal intelligence to make immediate decisions regarding the operation of its own process.  Control is absolutely required for the process to function properly, and therefore considered an integral part of the process.
If the main process contains subprocesses requiring response on a (much) smaller timescale, it will have specific controller(s) with dedicated communication channels (e.g. busses).  Then the main controller gets the characteristics of a management process, however still providing response within a defined time limit (a managed process can not rely on the management process being on-line).

Management

The capability to intervene in the operation of some other process (or multiple other processes).
The management process is supposed to be at a higher level of abstraction, and has a responsibility which is broader than the individual managed process (e.g. the overall flow).  It may instruct the managed process to start or stop a task, change priority, change parameters, ask for a report, etc.  It may even ignore the managed process, or decide to stop and restart the managed process using 'force'.  The management process does such based on reports it receives –sollicited or unsollicited– about the managed process.  Typically also, is that any intervention may have a considerable latency.

For reliable functioning of a system (of processes), management is required (basic inability to establish the disfunctioning of a process by itself, e.g. looping or crashing).  For immediate response, decisions must be made by local control.

Continuous Processes

When a process needs to run (nearly) continuously, it is hard to make any changes to the way it operates.  With a normal processing, you can modify (start-up) parameters before you activate a particular program, but this process is already running.  As it is running continuously, it probably is performing a vital role in the system, so forcing it to stop and restarting it again is highly undesirable.

Such a process needs a management process;  it allows to interact with the continuous process without disturbance to the normal process flow.  The interaction is probably based on messages which shouldn't be a problem as the continuous process is most likely processing messages anyway.  Of course processing of messages from the management process should have priority over normal processing, and the managed process should refuse management messages from others than the authorised management process.

Typical interactions are to start or stop logging, start/stop tracing, modifying parameters, etcetera.  Or even to (hot/cold) restart or reload the process (the continuous process should try to do so with minimal disturbance to normal processing.
Of course the continuous process may send unsollicited messages to the managing process.  But it should never rely on the managing process being active. 
A clear example of such a process is a routing function.

Process / Job States

A single process –or job– may have various states.  They are indicated below, with the potential transitions.
 

Undefined			job does not exist yet
↓ define			exact job is determined
Defined	←	←	job is defined, but no plan for execution yet
↓ submit		↑	schedule/enqueue/plan the job
Scheduled		↑	job is scheduled for execution (e.g. included in a planning, or entered in a queue)
	→ cancel	Cancelled	job was scheduled but hadn't yet started;  now removed from schedule (potentially back to 'defined')
↓ run			job is started
Active			job is active (i.e. processing)
	→ suspend	Suspended	active job is halted (frozen, paused)
	← resume		suspended job continues execution
↓ terminate, abort		↓	job terminates;  either by itself, but potentially aborted (forced ending)
Completed			active job has finished, potentially not as desired:  abnormal completion, e.g. failed/crashed or aborted

When a job is Active, processing may be temporarily halted as the job has to wait for an event (in computer processing typically I/O).  This is however still considered Active in this context.

Basic Computing Functions

Basic computing function types are:

Transformation function

The conversion of 'input values' to 'output values' (through 'processing' as in a simple program).
Regarding performance, such a function may be a bottleneck (CPU as resource, latency).

Communication function

The communication (interfacing) with other components or the 'outside' world (other components, foreign systems, man/machine-interfaces).
Regarding performance, such a function may be a bottleneck (bandwidth, latency).

Storage function

The (semi-)permanent preservation of data, commonly in a structured way (i.e. database).  This does not include the intermediate values which may occur during computing (i.e. in the Transformation function).
Regarding performance, such a function may be a bottleneck (availability of scarce resources, latency).

Not all components need to have all three Basic Computing Functions present;  a module typically fulfils a single Basic Computing Function.

=O=