Ubiquitous language and culture for project teams.

What distinguishes a junior developer from a senior and the senior from a software architect? This is a commonly asked question and there are plenty of very good sources out there. One argument can be found on every blog post about this topic: a junior mostly makes small decisions and consumes knowledge. With the level of seniority, the level of decision making and knowledge sharing increases. This is why we often find people like "advocates", "fellows" or "heroes" on conferences and summits.
I went to one of these summits (Munich Software Architecture Summit) and want to share my experiences about the sessions and talks here. Let’s start with the key note of the first day.

The speaker is Michael Plöd from InnoQ.

He starts with a provocative statement:

The biggest challenges in software development are not technological.

While most people smile, everyone knows he is correct (at least to some degree). Sure, there are projects with advanced technological challenges and uncertainty about actual future usage, but a decent amount of applications are "CRUD-like" apps, with a database and a Web UI. The hard part is fitting the business knowledge and the organization’s intellectual power in an application or API.

All-rounder

There are people out there that can do it all. They are software engineers or architects with outstanding business knowledge. Tekaris’ employees strive to be that, but there are several compositions where this is hardly possible. Sometimes the application context is very niche-focused or the experts are unavailable. In this case, we often find a dedicated role between engineers and architects on the one side and business domain experts on the other side.
Depending on the company and age of the project, we refer to them as requirements engineers or business analysts. In SCRUM, this could be our product owner.

Organizational proxy-pattern

Usually a high-level view on our project teams will look something like this:

There is various communication and exchange between the groups. Let’s not focus on the dev/ops segregation in the picture, today we are going to talk about the relationship between developers and architects on the one side and business domain experts on the other. In between, we find our requirements engineers and the PO. This construct is what Michael Plöd calls "organizational proxy-pattern". In projects, we feel like we have the need for such experts, because there is a mismatch in language between engineers and domain experts. Actually, what we need is a ubiquitous language.

Domain-driven design against Excel

Michael Plöd throws another one out there:

The archenemy of your application is Excel.

And again, the crowd smiles and nods. Business domain experts often use Excel, because it is customizable, because there is a low entry barrier and because it’s not as technical as application development. In summary: Excel is understandable for a domain expert.
This is the key moment of the key note. Domain-driven design (DDD) tries to simplify application development for non-engineers.
While DDD is the focus of the whole summit and the key mindset, the take-away can be: we need a common ubiquitous vocabulary for domain experts and developers.

Quick wins

When writing high-level notes and documentation or when going for a workshop,

• remove most technical words (to not intimidate the domain experts)!
• Add domain concepts, like policy lifecycles for insurance systems or navigation routes for harbor controlling software.

However, you don’t want to over-do the business buzzing.
Remove all business words not needed for the current context (to not confuse the engineers).

Techniques

Michael Plöd stressed this multiple times: use analogue language as much as you can! For knowledge crunching use techniques like:

• Event Storming
• Domain Storytelling
• Example Mapping
• User Story Mapping

Heart of the system

But don’t stop there. When you build your software system always remember

The domain should be the heart of your system.

This is achievable through

• a continuous learning process instead of static specifications,
• showing attitude instead of using templates,
• creating and living a culture instead of falling back to default behavior and
• enforcing engineering over of trying to fit in blueprints.

Perfect could be something like the Whirlpool Process of Model Exploration.

Title picture from: Code Guru