Most business models are documented. The modeler writes text that explains the model. The text serves as an introduction to others who later explore the model, trying to understand what it does and how it works. Of course the later explorer may be the modeler himself, forgetting the details he created a few weeks or months ago. (I am famous for not understanding models I built myself, only days before.)
What should be documented? Every named model element needs some explanation: every activity and gateway in a business process model, every rule and noun concept in a business rule model, every objective and opportunity in a business motivation model, and every organization and role in a business organization model.
In the book, we describe model documentation, including providing advice about what should be documented: “… every named model element should have a written description. The description of a model element should be a paragraph or two that is easy to read and easy to understand by someone who is not a modeler. Any model element should be a good starting point for a model; someone should be able to start his tour of a model by examining any model element, reading its description, and working out across its associations to other model elements.”
Some people think that every assumption in a model should be documented. Documenting assumptions has never made sense to me. A model is made out of assumptions. Assumptions are the bricks and mortar of modeling. It is assumptions all the way down. So documenting assumptions means documenting everything in the model, not a completely different idea than documenting every named element, but not entirely helpful as advice.
But there is a useful related idea about model documentation, a way to think about assumptions and documentation that yields particular insight. In his book The Black Swan, Nassim Taleb introduces the term platonic fold, “the place where our Platonic representation enters into contact with reality and you can see the side effect of models.” The platonic fold is the gap between model and reality. He described his work as a Wall Street trader as studying “the flaws and limits of these models [by which others valued financial instruments], looking for the Platonic fold where they break down.”
In the capital markets, Taleb noted that price changes were modeled as Gaussian distributions, with frequent small changes and infrequent large changes. Extremely large price changes are then extremely infrequent. But Taleb suspected that such extreme changes are not as infrequent as the models predict, infrequent to be sure, but to a lesser degree than predicted. Taleb investigated the platonic fold between the frequency predicted by the models and the frequency actually experienced.
So what? So what if the capital markets don’t behave like the model? In the capital markets, the existence of the platonic fold is an opportunity to make money (or to lose it). Financial instruments that benefit from these very large price changes are underpriced, worth far more than their price because they were priced by people running models that dramatically underestimated the likelihoods.
And of course Taleb made money. He made a small fortune in 1987 on the 23% one day decline in the stock market, a decline that some models predicted would happen once every trillion days, i.e. once since the beginning of the universe. Clearly the models were wrong. They grossly underestimated the likelihood of that event. Taleb made piles of money again in 1998 with the collapse of Long Term Capital Management, a model-based hedge fund that lost $4.6 billion, despite a staff that included brilliant mathematicians and two Nobel prize winners. This year Taleb is a star. His black swan ideas and his critique of corporate risk management have been proven right in the financial collapse we are all experiencing. 2008 was greated as the year of the rat, but it has become the year of the platonic fold.
What does this mean for us business modelers, for those of us who model businesses not capital markets? The idea of the platonic fold is useful for us. When we create a model, we are aware of the simplification we are performing. When we model the organization of an insurance company, we are aware that our clean and simple model ignores the ad hoc task force established by the Director of Human Resources to reduce recruiting cost. That ad hoc task force is in the platonic fold of the model: it is not part of the model but it is part of reality. Of course we could model the task force, bringing it out of the fold and into the model, but much else will still stay in the fold. All models are wrong; some models are useful.
We are aware of the platonic fold when we model, but our awareness is fleeting. Soon we move on from modeling the insurance company, and the ad hoc task force is forgotten. Others who examine the model will not know. If the model is deployed in a software engine, the ad hoc task force will be forgotten, and hence unsupported. The platonic fold fades into invisibility.
But we can do something about the platonic fold during our fleeting awareness of it. We can document it. We can write some words about the ad hoc task force, explaining that it exists in the world but not in the model. Others who later examine the model can read about our realization of the fold. We can make the fold visible.
When we document the platonic fold, we are writing not about the model, but about how the model is wrong. This is a curious kind of documentation. It is like an antiresume, a resume of one’s failures, shortcomings and lack of experience. (The antiresume is another Taleb idea, and an amusing one. What if everyone maintained an antiresume? Mine would include an utter ignorance of both business law and accounting. What’s in your antiresume?)
Documenting the platonic fold is a bit like the (mistaken) advice of documenting assumptions. It’s a similar idea, but to my mind documenting the platonic fold is much more useful. Anyone who uses a model will want to know its limitations.
Leave a comment