Complexity - Part I: What would IT Marketing do without it?

For all its press coverage, little effort has been made in defining "Complexity" in a manner that is relevant to the modern enterprise.

So here goes...

We'll start by imagining two abstract distributed "systems"; each system an infinite 3 dimensional lattice, each in a 3 dimensional space -- we'll avoid distractions caused by none-euclidean geometry :).

However, whereas the first lattice comprises of regularly spaced identical nodes, the second lattice has randomly spaced identical nodes.

Here is the crunch.

Whereas the first regular lattices may be simply, and completely, described in-terms of,

* A description of a node
* A description of the offset of a selected node from your chosen co-ordinate system, and
* The 3 parameters that describe the spacing between the nodes.

In contrast, the second random lattice needs an infinite number of spacing parameters to describe the system to the same level of accuracy.

By choosing to model each system in this manner, the first system is seen as trivial, whereas the second is infinitely complex!

Now, let us assume that relative node position is not important, and that instead we use an emergent property; in this case the density ( the number of nodes within a given volume of space).

Now the amount of information required to describe each system, is identical, and reduces to

* Composition of a node
* Density of nodes in a given volume of space.

Whilst "density" is only an abstract concept, it never the less captures important characteristics of each system with minimal information, so hiding in the case of the random lattice an infinite amount of structural complexity.

I'll now define System Complexity as, a measure of the amount of information required to describe a System; but crucially, with respect to the System Properties that are of interest to us. Furthermore, by defining/modeling a system w.r.t relevant Emergent properties, we can dramatically reduce the amount of information required to usefully describe the system. The model, representing the System and it's emergent properties, isolates us from potentially vast amounts of internal structure / complexity.

Also, for a given System, the abstraction / model that optimally describes the relevant emergent properties, with the least information; provides the least complex representation of that system.


Back to IT

Whilst IT provisionals are no longer required to understand:
* The arrangement of silicon atoms required to produce semi-conductors
* The detailed architecture of the processor or memory chip in use
* The firmware used
* The specific considerations in an OS kernel design

The resultant distributed systems are still "complex"; complicated by the fact that they consist of many inter-dependent components and services, each of which must continue to function within a volatile runtime environment.

The response to this "complexity" can be seen in every FT/Fortune 1000 company.

* Attempts are made to lock down the runtime infrastructure, to completely describe it, and prevent changes to it. More recently, attempts are made to virtualize / abstract to runtime infrastructure in a manner that presents an unchanging persona to the static business systems.
* Meanwhile, software middleware is treated as strategic investment - with physical silos of grid computing, ESB's and data caching introduced into these environments, the mandated then made that these infrastructure services must be used.

What is wrong with this consensus approach? Quite simply, as with the random lattice example, organizations are viewing their systems and so associated system complexity in the wrong frame of reference! And then attempt to address perceived complexity issues with a series of measures that actual drive up operational costs whilst impacting service agility and availability.

Enough for today - next blogging session I'll provide, what I believe to be, the answer ;)