The Importance of Play
That’s my response when I hear about the basic rules engines folks have written on their own. I love hearing about them—especially the stories behind the discovery of the pattern and the problems developers have solved with it. Most of the engines grow from simple pressures and find resolution from architectural principles—separation of concerns, encapsulation and SOA. I can tell that the folks telling the story love what they have, and by the end of the conversation they understand the limits of what they implemented. They are sitting (and running) on a tipping point of capability. When I ask, “can you include business users into your change cycle?” The response is often “Not yet, that’s when we will come to you guys.”
Rules are inherently social. The business wants to read through them, write them, and play with them. In fact, playing is the understated requirement. The act of playing embodies all of the aspects of experience and feedback loops that folks need to fail, explore, discover and improve. I don’t know anyone who knows exactly what they want (including myself) and yet our customers have business analysts who are constantly required to figure out the requirements of their business. Playing with logic is probably the only way to achieve desirable outcomes from rules technology. Folks need to lose themselves in a creative act, try it out, and run again really fast and without friction. When they are done, most folks want to share. They share example rules, decisions, notes, metrics and possibilities. That’s when the business starts to hum along with a new round of inquiry and the whole thing starts all over again.
Circle back to my conversations of late with architects running their cool engines, I should simply ask “can the business play with it?”