Decision models are the requirements language for DI apps

The software engineering revolution is happening again.

I was a coder before software engineering, and it wasn’t pretty.  When we needed to build a new program, we’d get together with the end customer, and ask a lot of questions, then go back to the office to write code.  It didn’t go very well.  It was like construction without blueprints, manufacturing without CAD.

It was kind of like this:

So my friends invented software engineering, which borrowed from engineering disciplines to spec and design the system before we built it. We learned about the 1:10:100 rule (a bug fixed during requirements takes 100th of the time to fix than required if you find the bug after delivery, and a tenth of the time to fix if it’s in the code before delivery), the difference between functional and non-functional requirements, the importance of clear documentation, and more.

And we learned object-oriented development and UML – the unified modeling language – thanks to Rumbaugh, Jacobson, and Booch – which allowed us to build a visual design working with the customer, before we started to code.  That went a lot better.

One of the key insights to OO was that it was an “adapter” of sorts: a language that users of software could think about as well as the coders.  The world is made of objects, objects have attributes, and they’re connected in certain ways.  OO is centered around this handful of concepts.  Objects in reality correspond to “objects” in code, which are mini-models of their real-world counterparts.  The vast majority of modern programming languages use this metaphor.

Mark and I were walking up Castro street earlier today (smells of curry, basil, flowers, and sage, oh my) and I realized that a Decision Model serves the same role, for world-model centric software.  Here’s a little diagram to explain:

This shows that anybody thinking about decision-making uses the metaphors of decision levers, outcomes, intermediates, externals, and dependencies.  As with UML, these elements correspond to their counterparts inside World Modeler (which is equivalent in its role to Rational Software as a design aid).  See our book for more details.

The neat part is this: since Mark and I are software engineers, we designed the above template to be compatible with OO.  Each of those boxes: we call them attributes. And they can be attached to objects.  Indeed, you can think of decision-model-centric software as layered, with the information architecture on the bottom, and process- and decision models sitting above them.

So whether or not you use World Modeler to do it, To specify or to design decision-centric software, use a decision model Click To Tweet

Do you agree?