Category Archives: Structure determination

The processes by which the structures of systems are determined.

Modelling structure-determining processes

by Philip Boxer

What do we need to learn about complex systems? We need to learn how to work in the ‘collaborative’ quadrant, which in turn involves us in having to model structure-determining processes as well as the familiar structure-determined processes.

This is not easy, because it implicates us as modellers – even as systems developers constrained to satisfying a user’s requirement, we are structure-determining in the way we do our work. How are we to give an account of the dynamic effects of those with power over what happens?

Quite a good place to start is with Zachman, who pioneered work on Enterprise Architecture. Why with Zachman? Because Zachman does a good job of modelling Architecture under conditions in which a symmetric relation to demand can be assumed. Thus in the introduction to the Zachman Institute’s Architecture Framework, it is proposed that the Enterprise…

“…must produce the models in order to deliver systems implementations in the short term, and at the same time for the long term, instantiate the Architecture process in order to ensure on-going coherence of system implementations and to build an Enterprise environment conducive to accommodating high rates of change.”

These “models” are models populating the different squares of the Architecture Framework, the underlying presumption being that the work of the Enterprise as a whole must be to ensure the on-going coherence of its Architecture. Why? Because the presumption is that the behaviour of the Enterprise can be structure-determined by this Architecture. But the question I want to address in this blog is what happens to that framework if we need to assume an asymmetric relation to demand.
What happens in the ‘collaborative’ quadrant is that the Enterprise can no longer be assumed to be structure-determined by a superordinate Architecture. This requires that the Zachman framework be modified with some additional rows and columns:

zachman.jpg

The additional row introduces the collaborative model through which different architectures are brought into relation with each other. And the two additional columns introduce on the left the models of events of which the data column is itself a representation, and on the right the contexts-of-use in relation to which behaviours are generated.

We see now across the top the four ‘colours’ needed to give an account of taking power to the edge. The addition of the ‘red’ WHO/M column situates the relation to demand (see more on this here), and the ‘black’ WHY column is now assumed to include asymmetric assumptions about the bases of competitive advantage.

So what does this tell us about modelling structure-determining processes?

We can now summarise the above modified Zachman in terms of the following four directions of elaboration, which relate back to the N-S-E-W framework for thinking about different forms of governance:

modality.jpg

The ‘South’ direction is unchanged, concerning itself with the detailed method of modelling, but the ‘North’ direction is generalised from the governance of the particular Enterprise to the context-of-governance emerging from collaboration between Enterprises. The ‘West’ direction is largely unchanged too, the addition of models of the events emphasising the particular modality of reality within which the models are being built (i.e. what are the forms of knowledge that we are interested in modelling). The greatest change is the ‘East’ direction, which now emphasises the asymmetric nature of the contexts-of-use in relation to which the collaborative behaviours are being constituted.
What does this tell us? In modelling structure-determined processes, we can take the ‘North-South’ axis as a given, and elaborate the ‘East-West’ axis within its terms. But in structure-determining processes, we have to start with the particular ‘East-West’ relations to context-of-use, and then examine the ways in which they are supported and/or restricted by the ‘North-South’ axis: in responding to asymmetric forms of demand, governance shifts from being an a priori to being an a posteriori consequence of the way we want to be able to respond to the particular demand. This is the challenge of taking governance to the edge.

What do we need to learn about complex systems?

by Philip Boxer BSc MBA PhD

There was a time when organisations could define exactly what it was that they expected from their systems. The job of the designers was then to couple systems’ behaviors that they created and/or inherited in such a way as to over-determine the behaviour of the resultant complex systems and thus satisfy the organisation’s requirements.[1] In judging the actual performance of these complex systems, this same presumption of over-determination allowed the behavior of these complex systems to be modeled independently of their contexts-of-use, enabling the risks to be identified of something accidental happening. In the 2 x 2 below, we are in the right-hand column.

But now we want our systems to be agile and responsive, capable of supporting demands on them not previously anticipated. Service-oriented architectures (SoAs) introduce under-determination into the ways systems can be coupled together,[2] while agile software development processes bring the spirit of mash-ups and bricolage to the just-in-time assemblage of workable solutions. Reducing the way a system over-determines its uses in order to enable its users to extract greater economies of scope from it is one of the primary aims of SoAs, but has the effect of reducing the North-South dominance of the way the system may be used.

In the place of a centrally defined requirement, the user now find himself or herself at an ‘edge’, where the organisation meets a new kind of demand on it. Judging performance under these conditions of under-determination now requires him or her to include the governance mechanisms that are determining those particular responses at the edge. Are they appropriately under- or over-determining?[3]

So how are we to model and simulate such governance mechanisms alongside the behaviour of the systems themselves? The answer is that we have to be able to include the context-of-use itself, which is constituted both by the organisation’s construction of its own role as supplier, and also by the client/customer’s construction of demand.

What do we need to learn about? We need to learn about how to model the structure-determining processes of the organisation-in-context as well as the structure-determined processes of the systems the organisation uses. We need to learn about modelling the left-hand column.

Notes
[1] to over-determine) is to impose equifinality aka the game is rigged always to produce the same outcome… for example, the corporation wanting to guarantee outcomes that serve its interests.
[2] to be under-determined means that the subject-user experiences choices in the way s/he can use the system. This is what Humberto Maturana meant when he said that there is no such thing as power, but only obedience to at least implicit power/knowledge (he was speaking about being threatened with a gun by the police in Chile). Such choices may emerge, however, through encountering an undecidability. At this point, the question arises: is there a flaw in the design of the system, in the subject-user’s model of how to use the system, or both. Whichever it is, under-determination places the onus on the subject-user to decide, potentially facing his or her with a 2nd crisis in the three moments, when s/he comes to realise that s/he is never going to be able to work it out, but instead must act. ‘Wicked’ problems fall into this category of being undecidable (see the wickedness of socio-technical ecosystems).
[3] Challenges to meet new kinds of demand are thus also always potentially disruptive of existing governance relationships.