The very first #DDDBE event: the modellathon

This is my personal review of the @DDDBE inaugural meeting: a modellathon.

Some background info

So, last night we had the very first event of the Belgian DDD community: a modellathon facilitated by Mathias Verraes and Stijn Vannieuwenhuyse, and kindly hosted by the hosting company Combell.

For the people who do not know the concept of a modellathon - in fact, I think we might even have invented the term maybe, but I am not quite sure -, it was something we spiked like a while a go, while coming back from the London DDD Exchange: As we were sitting together on the train with some of the #CQRSBeers guys, we considered starting a Belgian DDD community, and having real workshops.

Somehow the idea for the first workshop emerged: instead of having hackathons (hacking away on code), why not have a modellathon (hacking away on domain models).

UPDATE

Apparently the modellathon term was Jef Claes' idea !

So one thing came to another, and all of a sudden we were in this situation:

The modellathon

Our assignment for the workshop was to model a system that was used as a reporting tool in the Kazachstan Education System.

This was not your average fictuous model, we even received some official Kazachstan documents:

We were divided into groups of 4 people, trying to make sure that at least one person having experience in domain modelling was in every group.

Just to elaborate on the “experienced” part: when we asked who had experience in domain modelling, not a lot of fingers went up, but when we asked who had managed to build a domain model in the past, that somehow turned out to be completely wrong, some more fingers went up.

The role of the expert was just to find a way to get started, but once you have the juices flowing, the expert’s opinion is as valuable as anyone else’s. So it is more about facilitating the process then being good in the whole modelling part.

On to the modelling part

During the first pomodoro of the modellathon (after a general introduction by the domain experts), people started experimenting with different kinds of modelling at different groups.

A lot of people were trying to use the event storming approach - as they had experienced the value of the technique in a really great workshop with Alberto Brandolini during Vaughn Vernon’s IDDD tour in Belgium.

Somehow this approach did not feel valuable to us in this phase of the domain analysis, as the question was more about the report we initially got:

  • Why was having only this piece of paper not a viable solution?
  • Why does the business need the system? What does it need to do?

So we started asking questions from there, and all of a sudden the domain experts were mentioning concepts like observations and evaluations. So instead of focussing on the part where you process grades/tests/students/whatever, the domain experts were focussed on that part; the report was only a deliverable from the system, not the system in itself.

From this knowledge we could build a conceptual model of teachers being able to track the observations, progress and expectations in a graph-like model with time on one axis and skill on the other, just finding a way to represent the domain to the experts on paper…

It is only the left half, the right half came in the next pomodoro

The @DDDBE guys decided to put a picture of us explaining our model on twitter, and I would like to sincerely thank them for for photographing me from my best side ;-).

After another pomodoro, we evolved into this high overview model where we found out that observations (like grades, tests, but also subjective observations) were not always side-effect free, and there had to be some kind of a formal evaluation process for an observation; this finally resulted in the flow of observation (1..n) -> evaluation (1..n) -> progress x learning goals (1..n) -> expectations and back….

Then all of a sudden the DDD cowboy - AKA Yves Reynhout came along, and he stated the model might be to abstract to be usable, and challenged us to mock up a UI to prove it.

So we did, and by building this mockup for the evaluation part, we managed to get an even deeper understanding of the domain…

We noticed the higher level overview might have been all that was required for this particular bounded context or subdomain, because it made sense by mocking up the UI.

The most interesting part however, is how we progressed from mapping nouns from the specs to trying to find out why the system was needed (Root cause analysis/5 why’s - anyone?). Then, by modelling our UI mockup, we were able to verify whether our assumed domain model would be usable in the real world…

Conclusion

Well, this was a really interesting exercise to perform; I think the biggest lesson in all this, was to experiment, and not being afraid of starting over, especially using a different modelling approach. As we all observed in the end, and Mathias mentioned in the beginning:

“essentially, all models are wrong, but some are useful” - George Edward Pelham Box

Hence, we could coin the concept model storming (initally mentioned by Mr. Brandolini I assume - give credit when it’s due -) as the best approach to doing things: find several ways to model your domain, and gain new insights every time you do it.

A note about the #DDDBE community

Well, there is not a lot to say about that from my side, except that you were all pretty awesome; this was a huge experiment, but somehow we managed to get an interactive workshop where A LOT of people contributed.

Based on the feedback you provided, I am quite confident we can do a lot more with this community, so once again, everyone, feel free to suggest and improve, or even join!!

We also had - once again - some interesting discussions afterwards, and I even managed to see a fellow DDD practitioner (which shall remain unnamed) perform a musical masterpiece on the day after!

I hope we see you at the next event!

Tom/@ToJans

T.

More:

!!! Breaking news !!!

This just came in; he who shall not be named A.K.A. the Mob/Godfather of Event- & Modelstorming approves!