Measuring Integration Complexity Part 1 - IT's Complicated!

This is a post in 3 parts:

Part 1: IT’s Complicated!  (this post)

Part 2: The Cost of Complexity

Part 3: Practical applications

IT’s Complicated!

The study of System of Systems is a branch of IT research that I was recently introduced to by Marc Fiammante who has been guiding my research in this area. The concept of a system of systems is a loosely coupled collection of independent systems that all collaborate. However, when viewed at the macro level, the interactions create a new system that is greater than the sum of its parts. The standard example of a System of Systems is the Internet but the theory can be applied to pretty much anything from the collection of a city’s individual services creating an economic power house down to a modern smartphone.

The study of systems of systems looks at the interactions and behaviour of a collection of interoperable systems without exploring the details of the individual systems themselves. In the context of this post the system of systems is synonymous with a large enterprise IT estate.  A large enterprise IT estate comprises of a number of individual systems that are all connected together in some way to achieve a common goal – running the business.

Systems of systems are complex by their definition. This complexity comes at a cost. In the context of a system of systems where the cost is born by a single entity (for example in a large enterprise with a single CIO) then there is need to manage costs.  Reducing complexity would naturally reduce costs.
What is needed is an easily calculated metric for distilling the overall cost of complexity of an entire enterprise IT estate down to a single unit. Once the relative complexity cost is baselined then it becomes possible to create a strategy for cost reduction. The strategy would use the metric to measure the complexity cost delta of specific alternations to the IT estate; thereby making it possible to objectively understand whether a change to the enterprise would be in line with an overall simplification and/or cost reduction strategy.

There is a large amount of research focussed on measuring the complexity of individual nodes within a system of systems but little that focusses on the complexity of the integration between the nodes. I intend to use this post to explore a way of measuring this complexity by extending the use of “cyclomatic complexity”.

Cyclomatic complexity

Cyclomatic complexity (CC) is a metric used to quantify the complexity of a software programme. CC’s use is not limited to just software programmes as it can be used to measure the complexity of any system of connected nodes.  In other words, CC can be used to quantify the complexity of an architecture.

Cyclomatic complexity can be calculated in a relatively straight forward way.  The formula is very simple:

CC = E – N + 2P

Where, in architectural terms:

• E is the number of “edges”; internal interfaces and connections between nodes
• N is the number of “nodes”; blocks of function or components
• P is the number of externally connected components; external interfaces

Consider the simplest of architectures, a single component with only a single external interface:

Example 1

N=1; E=0; P=1
CC = 0 – 1+ (2*1) = 1

The cyclomatic complexity of this simple architecture is 1. Therefore, the lowest CC value is 1.

Even in systems of systems with more than one node, but with minimal interaction then the CC value remains at 1:

Example 2

 N=3; E=2; P=1
CC = 2 – 3 + (2*1) = 1

With increased complexity, the cyclomatic complexity increases:

Example 3

 N=12; E=14; P=3
CC = 14 – 12 + (2*3) = 8

Calculating CC in IT architecture

Cyclomatic complexity is often used to measure the complexity of a function or an algorithm in order to aid optimisation and performance management. However, there is an application of cyclomatic complexity where it is used to measure the complexity of an IT system architecture. For instance:

Therefore, it is possible to measure the complexity of a system architecture using relatively common architectural design work products.  Although far more complex than an individual system by itself, a system of systems can also be documented using a component model and a system context.  Thereby enabling the calculation of the Cyclomatic Complexity of the system of systems.

However, in my experience it is not just the number of nodes and connections between nodes that drives complexity; it is complexity of these interfaces that also impacts overall complexity. In the context of an enterprise architecture cost of operations is also a very important factor. The object of this article is to associate a relative cost to this integration complexity to aid decision making and ultimately support the reduction of operational costs.

In the context of a system of systems and, in particular, an enterprise IT estate, there needs to be a recognition of the cost of integration complexity. In other words, the complexity of the edges needs to be taken into account in the calculation. This integration complexity I have labelled as the “cyclomatic complexity cost”.

In part 2, I will explain how I suggest that we calculate the cyclomatic complexity cost.