Computation, Data and Connections

My ageing brain sees things in what feels like an overly simplistic and reductionist way. Not exactly the truth so much as a simplified version of reality which I can understand well enough to allow me to function (to a degree).

So in computing I see everything as being composed of three fundamental (overly simplified) elements; computation, data and connections.

Computation refers to those components which do stuff, essentially acting on data to transform it from one form to another. This may be as simple as taking data from a database and returning it as a web page or as complex as processing video data to identify and track movements of individuals.

Data is the information itself which critically has no capability to do anything. Like Newtons first law, data at rest will remain at rest until an external computation acts upon it. Data may be in a database (SQL or NoSQL), file-system, portable USB drive, memory etc. (memory is really just fast temporary data storage).

And connectivity hooks things together. Without some means of connectivity computation can't get a handle on the data and nothing much happens regardless. This may be a physical ethernet cable between devices, logical database driver, a file-system handle etc.

So in every solution I can define each component (physical or logical) as fulfilling one of these three core functions.

The next step from a non-functional perspective is to consider a matrix of these elements and my four classifications for non-functional requirements (security, performance & capacity, operability and form) to discuss the key considerations that are required for each.

For example, backup and recovery is primarily a consideration for data. Computational elements have no data as such (log files for example would be data output from compute components) and so a different strategy can be adopted to recover these (e.g. redundant/resilient instances, configuration management, automated-build/dev-ops capabilities etc.). Like wise, connectivity recovery tends to be fairly manual since connections can traverse many components, any one of which could fail, and so more effort is required to PD (problem determination) and identify root cause. A key requirement to aid this is a full understanding of the connections between components and active monitoring of each so you can pinpoint problems more easily - unfortunately it's naive to think you understand all the connections between components in your systems.

The matrix thus looks something like this:

	Computation	Data	Connections
Security	Computation v Security
Performance & Capacity
Operability	Redundancy, configuration management, build automation.	Backup, recovery, resiliency.	Connectivity model, monitoring.
Form

 

Now I just need to fill the rest of it in so when I work on a new solution I can classify each component and refer to the matrix to identify non-functional aspects to consider. At least that's the theory...