The Understanding Group loves models. We teach them, we use them to grasp understanding internally, we use them to describe and gain consensus with our clients. What is notable about us, however, is that we don't have a model methodology that we describe or recommend as a standard in our process.
People are often surprised by this! When most people are talking about formal models, they are talking about a modeling LANGUAGE or a METHODOLOGY, such as UML 3.0 or TOGAF matrices or ER diagrams.
We are familiar with many of these modeling languages, although certainly not as practiced in them as dedicated or credentialed experts. But we tend not to use any given language or format with much regularity. That’s because of the nature of the problems we have to solve, we want to model for rigor, not formality.
“Formal” and “Rigorous” Modeling
“Formal” is a defined way of doing things to ensure sufficiency and understanding, whereas “rigorous” is an exercise in thoroughly testing a concept. They are not exclusive, nor are they dependent; a model can be both formal and rigorous. But each effort takes time to do, and each has its pros and cons.
Folks often conflate these two terms to mean, basically “properly done”, but that is missing the point. Properly done is contextual! Sometimes you need to be very, very sure about what you are talking about; sometimes you need to be certain that how you are talking about it is clear. Rigor is the former; Formality is the latter.
So how do you decide? Well, Broadly speaking "formal" systems allow consistent understanding of more established ideas; "rigorous" systems allow thorough understanding of less established concepts.
By this reasoning, new problems in business — especially in internet-heavy contexts, where the concepts involved are changing at massive speeds — are the kinds of problem sets that demand rigor. Rigor is a way to validate, verify, and align their understanding of complex concepts. Only after the "what" is developed and the "how" begins to come up during design and creation should formal models get in the driver's seat.
Yet the modeling approaches we see business users encouraged to use are surprisingly formal: they provide a common language of assertions that don't demand a lot of testing or verification. They are collections of just-so stories that model known specifications, but don't invite close inquiry.
What we at TUG have discovered - and what we teach - is that creating rigor in models requires a framework. That framework should:
easily lends itself to ceremonies, rather than relying on trained experts to create and draft,
have a general purpose tool that is easy to learn,
allow people to use a common language of understanding for figuring out WHAT is being described and WHY, so that everyone on the team can get alignment on what's next.
Rigor as Organizational Revolution
What if, instead of starting with relatively inflexible, formal models, organizations tried rigor framework instead? Early rigor could change your organization. Anyone in a position to make something or spec out something to be made could use rigorous modeling to mutually explore, understand, and resolve complex situations. Rigor scales, too, and it can be applied at any scale within the organization and at any level from the executive to the execution team.
If you want to see how your organization can benefit from a rigorous modeling framework, check out our modeling workshop.