12.4.7. Modelling freedom
The exploration above gives us considerable leeway for modelling, because we can see several techniques on the horizon that will make models practical that otherwise might seem wieldy and inefficient. The model repository is an example. The most straightforward way to describe the exchange and exploitation of models would give the modeller and the end user a role in some context that represents a particular model. That context would obviously also include a role for the model itself, in its various versions. We would further include some constructs to record end user payments for the model, etc.
But this would quickly become a burden for the author of a popular model. His THP would become buried under thousands of end user in the role of client. Update information would have to spread to them, invoices, etc., in volumes that could grow into a problem for the modellers laptop.
We now know that we can ‘offload’ such transaction handling to dedicated servers. This is exactly the business use case for repositories as a kind of app store, their raison d’ etre.
In other words, by implementing the above features, we further separate the conceptual modelling of co-operation from issues of scaling and deployment.