How was Training?

more

Intense and in all parts applyable to my own organization. - Enterprise Architect, Malmo, Sweden, Oct 2013

Recommend PEAF?

more

Yes - n/a - Director, Technical Planning & Standards, EIS, Providence Health & Services, USA, Jan 2015

  Introduction   Context   Methods   Artefacts   Culture   Environment   Adoption  

Desktop

Mobile

 

<< Previous <<

>> Next >>

All things have a level of Structural Complexity

Structural Complexity is not the same as size or quantity but can be related. Structural Complexity is more a function of the number of different things and the number of relationships between them.

For example, a typical car park might contain 500 parts (cars) but the car park has low complexity because a) they are all cars - things of the same type and b) the only relationships that exist between them are from each car to its immediate neighbour or from each car to a map.

On the other hand an typical car contains around 10,000 parts (components) but most of those parts are different and the relationships between them are many and varied, from obvious/direct relationships like the accelerator is related to the throttle body to subtle/indirect relationships such as the cooling output of the air conditioning unit is related to the number of people in the car.

From these two examples, it can be seen that Complexity is also a function of how deep we look into the "thing" in question. If we take the example of the car park and say that the thing in question is not only the cars but also the "things" that make up the cars, then the car park changes from having a low complexity to a high complexity.

Transformational Volatility merely refers to how often the "thing" changes - its rate of change.

In fact, increasing Structural Complexity can be very beneficial, for example the structural complexity of most back seats in cars today is very high compared to their structural complexity 40 years ago. But this increased complexity exists for a purpose - to allow an end user of the car to convert the car to a van easily without having to go back to the factory to have them do it. So there is a notion of good and bad complexity.

Good or helpful complexity is defined as:

      Complexity which exists for an identifiable benefit.

      Tends to be created on purpose - by explicitly architecting or designing it into things when they are created or changed, although can also be created by accident (e.g. implicitly by the good working practices of individuals).

      Created with the knowledge of, and acceptance of, its implications.

      Tends to increase the effectiveness, efficiency, agility and durability of the thing in question and its transformation.

Bad or unhelpful complexity is defined as:

      Complexity which exists for no identifiable benefit.

      Tends to be created by accident - by the passage of time, although can also be created on purpose (e.g. explicitly by the self-interests of individuals - in which case it would be viewed as good complexity by that individual).

      Created without little or any knowledge of, or acceptance of, its implications.

      Tends to decrease the effectiveness, efficiency, agility and durability of the thing in question and its transformation.

 

Are you aware of your Enterprise's Structural Complexity?

How would you define it?

How would you measure it?

Do you care?

 

 

2008-2016 Pragmatic EA Ltd