THE BIG IDEA
Legally binding contracts can be designed with greater speed and precision using an architectural framework.
I have long been impressed by the way software design methodologies can cope with the translation of rich requirements sets and turn them, quickly, into an app. A lawyer, on the other hand takes a rich set of client requirements and tries to turn them, quickly, into a contract. The difference is? Very little, really.
SOFTWARE v CONTRACT DEVELOPMENT
Process aside, the software developer has to implement an app within a complex governing framework of coding semantics and rules. The lawyer has to draft a legally binding agreement within a governing framework of laws, semantic guidelines and regulations. The key difference is that the software developer has to develop something that is useful, meaningful and practical to the user whereas the lawyer’s client won’t usually be able to understand what they’ve got and generally takes it on trust.
With this in mind I’ve adapted Phillipe Krutchen’s 4+1 design framework to contract drafting. I’ve always liked 4+1 as a framework for design as it forces the architect to separate the logical from the physical. It’s not too heavy and it’s not too light. This is invaluable as a lawyer because it forces me to create a logical implementation of the client’s goals (the preferred operating model) and then implement that in physical terms (the contract clauses). It forces me to concentrate on what is important to the client – the business objects (products, services and IP capital) – and not on the law. It makes me get the point – and get to the point fast and effectively.
THE PREFERRED OPERATING MODEL
The collaboration (the subject of the contract) is a business thing but the contract is a legal thing. Or is it? The contract should be a business thing. A contract is the instantiation of the client’s preferred operating model. It should not be a legal creation although it is legal documentation. It represents how the client wants to do business with the other party and what is important to them. It is the agreement over how 2 parties wish to be bound as they collaborate over a thing. As a commercial consultant I have worked in companies on contractual disputes where neither party had read the contract, nor were they using it to solve the dispute. This was multi-million GBP stuff and nobody cared about the contract. Contracts should be about the business, they should be about how we manage things and people and they should be dynamic and usable (more on that another time).
THE ELEMENTS OF THE FRAMEWORK
The design framework above closely resembles Krutchen’s framework but with 2 key differences. Firstly, the physical implementation is not a technical architecture but the contract clauses themselves. Secondly, I needed to take account of time so I added a Change View.
The fundamental aspect of a complex evolving system is how it changes over time. When constructing a building the architect’s plans will change subtly as the engineers work around issues, materials are too expensive and delays are managed. The contract may be varied formally, informally or not at all. In all complex contracts the stakeholder landscape morphs over time. The contract must take time into account and few, if any, contracts ‘do’ time well.
In order to do time well we need to understand how the business objects in our contract change over time. By this I mean the physical and conceptual fruits of one’s labour. This could be a car or a computer program. If you need to redesign a car over time to keep it competitive then these changes need to be taken into account. If you need to upgrade computer software, or train call centre staff in the delivery of a service then this all needs to be taken into account. If things change and are not taken into account then much future action may be outside the scope of the contract. Worse, there is potential that your products and IP are not being protected or that you have your eyes on the wrong ball. Traditionally, lawyers would insert a general statement to say that you own something now and forever in the future. But what if your product has changed so much that the thing you’re delivering is no longer within the scope of your original contract? How do you define or negotiate on the basis of detailed subtleties?
I work around this by specifying the relationships as part of the contract construction and the meaning of the terms. As in our example above, if I am selling Product A to Supplier X and I need to rely on the components then I need to specify both their relationships with Product A and with each other – over time. I need to specify the state they will be in when they are no longer part of the system. If I specify the unique operation of the components together then I will know what it is I am protecting. If I make this part of my delivery processes then I will be able to guard against copyright theft and trademark infringements.
The Process View shows the client’s preferred operating model and service delivery scheme. Once again, it is not simply the processes themselves which need to be specified but how the processes interact and their dependencies which gives the contract its unique flavour.
Most importantly, the processes describe how we are going to manage our business objects over time. In the process view we match our delivery processes/operating model to the objects. This is crucial. A traditional legal drafting view would be to impose a ‘we own everything ad infinitum’ perspective. However, if you know how your stuff/services are going to be used you can give lesser elements away as negotiating collateral. You can negotiate and contract with precision and fine distinction that manoeuvring into your preferred contract become less art and more science. You also now understand what will trigger management action, what elements of the contract need to have embedded links to the contract management/procurement/financing etc. The process view lets you define exactly how you intend to control your IP collateral and assess the actions of your partners and suppliers.
The Implementation View holds the actual contract clauses. This is where the ‘rubber hits the road’. In this view we take the information from the other 3 views and blend them together to build each clause. We take the structure of all our business objects, ensure they have the right relationships the client wants (and they are correct over time) and we make sure they are accounted for in the operating model and any service delivery processes. More importantly, the clauses are derived from and traced directly back to the technical and business architectures. You now own your contract and you know exactly what it does and how it takes care of you.
In summ, if we have focused on the business objects and not just the law then we are in a better position to control how our products and services are used. We won’t need to be heavy handed with our customers and stifle our communication and stunt our growth. An architectural process not only allows us to contract in a faster, more precise way, it also integrates the business allowing greater analysis of dependencies, impacts and trade offs. In short, such a contract design framework represents practical steps towards a business driven, seamless end-to-end architectural process.