In conventional models and metamodels, links between items are kind of binary: if they exist, they apply every time, and if they aren’t in the model, they’re deemed not to apply at all. It fits well with the standard rule-based world of IT, which is why we see them so often in all manner of IT-type models, from data-models to process-models to ArchiMate layered models, and so on.

The catch is that that isn’t how things work in the real world. The reality is described well in Volere requirements modelling: rather than a simple true/false or ‘is-required’ / ‘is-not-required’, the template allows for at least five levels of ‘bindedness’, in two different directions (satisfaction if present, and dissatisfaction if absent). Even the old-style requirements techniques allowed for at least two levels, described via ‘shall’ (mandatory) and ‘should’ (desirable or highly-desirable). Yet another variable bindedness is the ‘MoSCoW’ set applied to requirements in some Agile software development styles:

• Must – mandatory
• Should – highly desirable, strongly recommended
• Could – desirable, recommended, an option known to work in this kind of context
• can Wait – a ‘nice-to-have’ that can wait until a later iteration (known as ‘Waiting Room’ in Volere)

Much the same applies to reference-models: these too need similar contextual bindedness. Compliance to some parts of the reference model may be mandatory in law; we don’t have any choice about that, and these are the same straightforward true/false links as in standard software models and the like. But for the rest, it’s really about risk-management and levels of risk: we can move away from the standards specified in the reference-model if we must – perhaps because of practical constraints, or because what we need simply isn’t available and can’t be bought or built within reasonable cost at the present time – but every deviation from the standard represents increased risk. High bindedness indicates high risk from any deviation from the standard; low bindedness indicates low risk. In enterprise architecture, we document the deviation by a formal ‘dispensation’ or some other equivalent risk management mechanism.

Which brings us back to models and metamodels, because in the standard rather IT-oriented approaches to modelling, there’s no way to describe this variability of bindedness: we’re stuck with true/false, mandatory or not-required-at-all. The OMG’s Semantics of Business Vocabulary and Business Rules specification is one existing definition that goes part of the way there, but it uses horrible formal-logic terminology such as ‘modality’ (meaning bindedness, but a word which has many entirely different meanings in other contexts) and ‘alethic’ versus ‘deontic’ (true/false versus slightly more variable than true/false), and I haven’t seen any modelling technique – with the possible exception of ORM, or Object Role Modelling – which actually applies it. Even then, it still doesn’t carry through either the simplicity or richness of the bindedness of a reference model, but instead again drowns us in the impenentrable rigidity of formal-logic.

To me it’s just laziness that we’ve stuck with the crude true/false links for so darn long, because they don’t fit what we actually need, and they’re often dangerously misleading in practice. It shouldn’t be hard to define and implement variable bindedness in a metamodel: at its simplest it’s just a straightforward categorisation of link-strength, and could be displayed in a modelling notation by thickness of line or by colour-coding or the like. I’ll have a go at building it into the metamodel for enterprise architecture that I’m working on at present, but it would be good to avoid reinventing the wheel if someone else has done it already.

Advice / suggestions, please?