THE BIG IDEA
Designing legal clauses should be an extension of the architectural process. The contract then should be about 75-85% by design directly from the business and technical architectures and the taxonomy (terms). The rest will be terms of art (contract construction, jurisdiction etc).
WE ALREADY DO IT
The first thing people say to me when I set out this proposition is that it’s obvious and sensible. So, why isn’t it done already? Well, to a certain extent it is, we just don’t know it. Secondly, it’s not intuitive – it’s not the logical next-step when we’re doing the work. Firstly, we do already do it: most commercial and technical managers already understand a great deal of the law surrounding their areas and simply design around it. Secondly, commercial architecture – cost models, program plans etc which are just the attributes of the other architectures – have no spatio-temporal extent. We can’t see, feel or touch them like we can the stuff we’re engineering and therefore our understanding is governed by how we construct these concepts and thoughts in our mind (Wittgenstein).
THE COUNTERINTUITIVE BIT
The counterintuitive bit is that many commercial entities are actually separate things – they are relationships to an entity. In ontological terms they are ‘tuples’ and instantiated on their own. In the same way that a packet of cornflakes has a cost and then the manufacturer puts a price on it.
The price is a different thing but related to the cost. We know that the price, in turn is related to their profit margin which in turn is related to their overheads which in turn are made of R&D costs, admin, advertising etc. All these elements are part of the business architecture which influences the commercial (financial and legal) architecture of the given project.
Risk is the key relationship we are modelling. It is best to see risk as a relationship rather than a property. Widget A does not have risk in and of itself. Widget A does have risk when used in a certain machine, in a certain contract. This is important to note because in later whitepapers I will talk about the need to separate the logical and physical commercial architectures in order to make trade-offs and impact assessments.
Risk links to architecture through a series of relationships. Ultimately, if we look at components in a database then the relationships I would draw would be:
REQUIREMENT > ELEMENT > CONTEXT > RISK > MITIGATION > MITIGATION INSTANTIATION > CONTRACT CLAUSE.
In the above the ‘context’ is the domain architectural instantiation (the physical architecture) we are modelling, for instance, Architecture A or 1 etc. This allows us to compare risk profiles across different possibilities and then make trade-offs. The difference between the ‘mitigation’ and the ‘mitigation instantiation’ is merely logical v physical. Logically we might wish to insure against a risk but when it comes down to it physically we are insuring part, funding part with a bond issue and hedging against the rest. The point is to identify clearly in the model what is mitigated and what is not. In a large and complex model of thousands of elements we will want to make sure that all mitigations are accounted for and their are no overlaps. If we’ve overlapped mitigations (insurance, loans etc) on a number of parts then the cost could be astronomic. The calculations will be clearer in later whitepapers when I explain how to aggregate derived risk.
The physical mitigations are the most important things to agree on. These are the processes and the structures that the business must agree on. This will be a collaborative effort of legal, financial, technical and programmatic. They must be realistic, sensible and accounted for in the program plan. Once clearly set out then a precise and specific contract clause (not a mopping-up clause) can be tightly crafted around each and every one. These clauses must have triggers built into the program plan and each trigger must have adequate information derivation for decision making (ie, you need to know when the clause might need to be used).
The trick in all of this is not in deciding what to do but in identifying the risks in the first place but that is for examination another time.
HOW TO MITIGATE
Repackaging risk to mitigate effectively will be the topic of another blog.