Dependency and resilience in enterprise-architecture models

This one’s back on the metamodel theme again, and is a follow-up to a query by Peter Bakker in his post ‘Thinking about Graeme Burnett’s questions‘, in reply to my previous post ‘EA metamodel: two questions‘.

Peter wrote:

I think that the most important question of all is still missing, namely:
— What do you rely on?

(The ‘you’ here is the entity-in-focus, as with Graeme’s original two questions of “tell me about yourself?” and “tell me what you’re associated with?”.)

Peter’s right, of course: it is one of the most important questions we need to ask. It’s one reason why I generally extend Graeme’s second question to “tell me what you’re associated with, and why?”. Yet there’s a practical concern here about just how where the intelligence needed to answer that question should reside – and I don’t think it belongs in the metamodel.

To explain why, we probably need to do a brief detour into modelling in general within enterprise-architecture, and in particular our modelling of dependency and resilience. As I see it, there are two key aspects to Peter’s “What do you rely on?” question:

• dependency – about what this entity relies on, within the shared-enterprise
• resilience – about what this entity needs to do, or can do, to get back on track if what it relies on isn’t there

In a systems-theory sense, the first answer to Peter’s reliance-question must be “Everything!” 🙂 Any shared-enterprise represents a system, and by definition everything within that system depends on the presence of everything else within that system (otherwise it wouldn’t be part of that system). So in practice, from a modelling perspective, there are two additional aspects to the dependency-issue:

• distance from ‘self’ (where ‘self’ is the entity that’s our current focus of attention)
• criticality to self – the risk or opportunity represented by the presence or absence within the system of another entity

To illustrate distance-from-self, consider a typical biological-ecosystem: for example, the world of a dung-beetle:

• distance-1: the dung-beetle relies on the presence of dung
• distance-2: the dung-beetle relies on dung-producing-animals
• distance-3: the dung-beetle relies on fodder for dung-producing animals
• distance-4: the dung-beetle relies conditions that support appropriate fodder for the dung-producing animals in the ecosystem
• (and so on…)

So if we have an invasive species of vegetation that out-competes the existing vegetation and is either toxic or non-palatable to the local cattle, our dung-beetle could be in trouble… Yet on its own it may have no way to know this, because the connections to the critical issues are indirect, several steps distant-from-self. And the greater the distance-from-self, the more whole-of-system knowledge any given entity will need, in order to understand its contextual dependencies, opportunities and risks.

(By the way, this is one of the main reasons why I’ve been pushing so hard for a ‘notation-agnostic’ metamodel for enterprise-architecture and the like. For example, a UML diagram typically shows only the direct point-to-point connections; so we’d typically need to be able to swap out of that diagram and into, say, a Senge-style systems-dependency model or fishbone root-cause model, using the same entities, in order to understand the systemic interdependencies of each of those items. Currently we can sort-of do this in some of the EA toolsets, though typically only within a single notation-set such as UML: my point is that we need to be able to do this, cleanly and consistency, across all and any notations in the EA space. The base for all modelling should be the entities and the relations and flows between them – not the notations with which we model them.)

Criticality is closely related to specialism; and in turn, resilience is closely related to criticality. The catch is that that criticality can occur anywhere in the system. For example, our dung-beetle may need larger piles of dung for its larvae to live in. As long as it doesn’t need specific nutrients that only come from one species, it’d probably be happy with any of the larger herbivores: cows, buffalo, camels, elephants, whatever. Even forest-clearance mightn’t much affect it, because to our dung-beetle a cow is much the same as a giraffe: criticality for that kind of change is low, hence resilience might seem to be high. Yet if there’s a change from cattle or camels to ‘pellet-dung’ producers such as sheep or goats, our dung-beetle could well be in trouble, because that kind of dung is too small to work with. And without the dung-beetle, the nutrient-recycling processes within the ecosystem may be too slow for self-renewal. Hence not just the dung-beetle but its entire ecosystem may be at risk from arbitrary decisions made by humans in ‘markets’ that may be tens or hundreds or thousands of miles away.

These whole-of-system dependencies and resilience-issues are classic simulation / systems-theory territory, illustrated well by the old military adage of a century or so ago:

For want of a nail, the shoe was lost;
for want of the shoe, the horse was lost;
for want of the horse, the rider was lost;
for want of the rider, the battle was lost.

Whole-of-system resilience is also a common concern in studies on complex adaptive systems, where resilience in one area can sometimes even enhance resilience in other more apparently-fragile areas. And there can also be dependency/resilience issues between nominally-interdependent systems that are in ‘system-of-systems’ relationships with each other: these are common in military contexts, though Nick Gall gives a useful non-military example in the section ‘Models of interdependent networks‘ in his seminal ‘Panarchitecture‘ paper for Gartner.

Identifying those kinds of dependencies usually requires a lot of ‘whole-system intelligence’ – in other words, cross-mapping of dependencies and criticalities that may be many steps distant from each other. There are two classic approaches to this:

• ‘inside-out’ – each entity knows everything it needs to know about its own system-context
• ‘outside-in’ – an external observer assesses the interactions across the entire system-context

In practice, neither of these approaches work well, especially for any large real-world system. The ‘inside-out’ approaches assumes high intelligence and information-gathering capability in each entity, which certainly doesn’t apply down at the level of bacillae and bacteria in living ecosystems; the ‘outside-in’ approach requires phenomenal computing-power, and probably can’t cope with any kind of non-linear relationships anyway; and both demand vast cross-context information-flows that can rarely if ever be seen in real-world systems.

Instead, what actually works is observation of patterns of emergence: the ‘intelligence’ – so to speak – arises from the network of relationships, rather from any specific entity either within or (nominally) outside of the system.

Hence, to bring it all back to the EA-metamodel, I suspect that the question “What do you rely on?” may actually be a bit misleading here: it’s certainly a question that we need to ask, and answer, but it’s not a question we can meaningfully answer at the metamodel level. Some kind of intelligence would definitely be needed in order to assess contextual concerns such as whole-system interdependence and resilience: yet the metamodel itself doesn’t have any intelligence as such – it’s just a means to structure information.

Hence for any given entity, it would be meaningful to ask directly each of Graeme’s questions:

• “tell me about yourself” typically identifies the immediate content of the item [and in this metamodel, also the content of any items within the scope of its related-items list]
• “tell me what you’re associated with” identifies the immediate (‘distance-1’) relations in which the item is referenced
• “…and why” identifies the reasons given within those ‘distance-1’ relations

Answering those questions doesn’t require much intelligence: we could easily embed that within an object-method for entities, for example. But as soon as we step beyond that immediate ‘distance-1’ level, the relationships and dependencies become very complex, very quickly – and I don’t think we would be able to embed that within the entities as such. (Okay, we probably could do it, but I doubt that doing so would be effective enough to worthwhile in a practical sense.)

Hence I would suggest that at the metamodel level we should stick to Plan A, and keep everything as simple as possible: Graeme’s two questions (in that slightly-amended form) should be enough to cover most if not all of what we need to support an emergent view of enterprise context.

Your comments on this, of course?