Collaborative Process Modelling (DDD!!!) for the Unbelievers

I was reading this book:

Because, what else to do on a Saturday morning while sipping coffee and the beach is 5 mins away?

And I came across this:

Basically, they are talking about the ubiquitous language, and the whole Domain-driven Design idea. The first question is, why not mention it? We find the same amnesia in the BABOK. Why don’t mention DDD?

The second question: what on earth is Behaviour Engineering?

Answer: it’s a behaviour science model used to tweak performance in organisation, holistically. I like it. It’s a way to acknowledge and tackle complexity (the DDD subtitle).

[embed]

But how it’s used in process modelling? Like this (from Wikipedia):

And what does a “behaviour tree” looks like?

It looks like this (from same page):

Note how the written requirements are already given, which begs the observation:

Given that we are using the model to fix ambiguities in natural language descriptions, when we build the model *after the natural language description is provided, then* we will either incorporate those ambiguities in the model or we will not be able to build the model due to those ambiguities.

Which begs a postulate:

In order to effectively remove ambiguities in natural language descriptions of requirements, process modelling activities needs to happen while or before the natural language description is defined and finalised.

Which begs another:

Process modelling activities need to be

1. collaborative to enable different stakeholders to contribuite to it,
2. they need to be visually intuitive to enable immediate feedback and agreement,
3. and they need to be easily modifiable to remove sunk costs and enable cheap on the spot adjustments.

Is behaviour engineering modelling meeting our requirements as a process modelling techniques?

Zooming in on the components of the tree:

It looks to me it is more like a proper engineering tool rather than a collaborative process modelling tool. In fact, I discover it is used by engineers in AI and gaming. And you can even build it graphically and integrate it with the actual program:

[embed]

So imagine, you do ONE thing right:

• You realise there is ambiguity in language descriptions of requirements, and that you need some form of process modelling to remove it

But then you follow it up doing FOUR things wrong:

• You fail to acknowledge that this problem was tackled by a very influential book (the blue book by Eric Evans), that became mainstream in the software industry as Domain-driven Design (on what planet one can be a software process expert, address complexity and ambiguities in requirements and design, and not point to DDD??)
• Because of that, you suggest a process modelling technique that is not collaborative, has a complex visual grammar, and a structure (the tree) with a lot of sunk cost for changes
• Because you sound very formal and scientific, you convince the managers to incorporate the flow in the standard operation processes

Which results in:

• Your best developers will search for another job

Instead, let’s put together an happier path:

• You realise there is ambiguity in language descriptions of requirements, and that you need some form of process modelling to remove it
• You get in to Domain-driven Design and learn how this problem is tackled, because this is how the software practitioners are trying to solve it
• You realise that requirements and process modelling need to feed back on each other, and that morph progressively in to design (architecture and code)
• So you DON’T enforce a sequential separation between requirements, process modelling and solution design
• You acknowledge that the tools for process modelling need to be collaborative, visually simple and intuitive, and easy to modify
• Because you also have DDD on the radar, you will not miss techniques such as Domain Storytelling, EventStorming and Event Modelling
• You convince your high level suited manager to accept the sticky notes, the collaboration, and the fancy colours
• You train your delivery team on process modelling techniques, in software design, and how to link the two. In essence, you train everybody on DDD
• Actually, you create a Behaviour Engineering model to assess what is preventing your team to perform
• Then your DDD-trained workforce will surely help you to optimise the value flow using process modelling techniques to remove bottlenecks, optimise queues, and optimise org. structure with Team Topologies

There’s always so much to explain. And the beach is 5 mins away…