Comment on My DMN 1.2 Wishlist by jamet123
Blog: Method & Style (Bruce Silver)
I think the persistent requests from this come from a misunderstanding of the way DRDs work relative to a DRM: I can already build as many DRDs as I like as views on a single underlying DRM. I can therefore do exactly what is being requested today – it’s just a tooling issue. A flat DRD is absolutely not the way DMN supports decision requirements modeling as any number of views can be developed.
I see some confusion on this issue that comes from applying the diagram-centric view of BPMN to DMN. Unlike process diagrams, the fact that something is on a DRD is not important. The relationships across all DRDs are what matters as DMN is repository-centric and not diagram-centric. We have already managed decision models of 300+ decision nodes, it just took a bunch of diagrams showing different perspectives….
I also don’t like decision services on DRDs they are a technical artifact and I don’t want business users to have to deal with them. I don’t mind drawing a new DRD to define them but I don’t want to have to show them to business people
Alternative BKM Representation
Well I don’t like or use BKMs much but I agree with the general comment that the notation is verbose and creates clutter. BKMs don’t need diagrams though so I was thinking in terms of an icon or shape embedded in the Decision to show it has a level of indirection.
DRD Representation of a Context
As I reject the notation of a sub-DRD this makes no sense to me That said I agree that contexts and DRDs need better integration…
While I agree that multi-instance decisions are a challenge that needs to be addressed and also agree that the three vertical bar approach is a good one, the sub DRD thing is still flawed even for this. It is unnecessary as the information requirements can be labelled with the vertical bars to show the multiple instance needs, minimizing the needs for new constructs. Jan Purchase has articulated this well on his blog.
Agree this is inconsistent.