Comment on Why Does DMN Have BKMs? by Bruce Silver
Blog: BPMS Watch - Bruce Silver
In reply to Ryan.
Ryan
Thanks for your comment. From your affiliation I assume your questions are more to provoke than inquire. But that’s ok, it’s an important discussion so I will take the bait. Although BKMs are normally used in places where you would want to use a function, in FICO’s original methodology they were intended as a way to allow the overall decision modeler (on the business side) to delegate implementation to a subject matter expert and have the two work independently, i.e. not involved with reuse at all. So that is how they got into DMN1.0 in the first place, as specialized “knowledge” not as “functions”. I wasn’t there at the time but you can ask James.
OK to your second issue, which is I suppose the real one. There are two views of business’s role in DMN. One says they should just create requirements, the DRD, and hand them off to technical modelers (programmers) to create the value expressions. I believe that is your companys approach and actually it is an unstated assumption of the FICO methodology, i.e. the implementation does not use DMN but some proprietary rule language. So you could say the real intent originally was a way to map FEEL variables in the DRD to the proprietary language of the BKM. Of course vendors don’t like to put it in such stark terms but that’s the idea.
The second view, which is the one I ascribe to, is that business should be able to do the implementation as well as the requirements. In fact, without that, the requirements handed off to programmers are still just guesses at the correct logic. And this is why DMN went to all the trouble to create FEEL and boxed expressions as a visual execution language for non-programmers. And honestly they did a fantastic job of that! Incumbent vendors of production rule technology have no interest in redesigning for full DMN so they just use the DRD and let you connect the programmer implementations to the DRD elements. Some use the fig leaf of a BKM, which is actually cleaner, and some don’t bother even to do that. Does it work? Yes, as long as you accept that the “business requirements” expressed in the DRD and associated scribbling about the logic is going to be vague and untested. DMN was intended to eliminate those problems, and it actually does it. The barrier to adoption that you mention comes from a reluctance of business to learn how to create executable logic themselves and the reluctance of incumbent decision modeling vendors and practitioners to encourage that (or adopt FEEL themselves). Because DMN is so well suited to today’s microservice architectures, I think it will actually win in the end. But time will tell.
Leave a Comment
You must be logged in to post a comment.
