Eric Evans coined the term Ubiquitous Language in his excellent book “Domain Driven Design” and it means that we should align the language of the IT systems we build (and the developers who build it) with the language of the users who will use the software.
While this seems like common-sense, and it should be easy advice to follow, things don’t always go smoothly. There is also some subtlety to the idea of a ubiquitous language which is worth exploring.
Just as badly named variables or functions can make a codebase difficult to maintain; badly named concepts and metaphors in software difficult to use and understand. Having a common language means developers can more seamlessly engage with business stakeholders, which means they will understand the domain better and subsequently produce better requirements and ultimately better software.
IT REQUIRES EFFORT FROM BOTH SIDES
It is not always the case that it is only the developers who need to do all the hard work. Creating a ubiquitous language can require work from business stakeholders too.
Business stakeholders will be required to transfer their use of language to the team. This can be done implicitly while working with the development team on requirements, or explicitly to teach and explain the terminology in their specific domain.
Assuming the development team will have ongoing relationship with the business stakeholders and the software, this should be considered a valuable investment.
DEVELOPERS CAN HELP REFINE THE LANGUAGE OF THE BUSINESS
Business users may not yet have developed a mature language and they may use words loosely or in an overly colloquial way. A symptom of this might be that the business users already struggle with miscommunication, or misunderstandings within their own team.
A development team, through probing and challenging the use of terms and vocabulary, can help the business stakeholders realise that they don’t always agree or use terms consistently. In such cases we can, together, create a new and better ubiquitous language that will enable the business stakeholders to be more effective.
Sometimes, the mere act of business stakeholders explaining their use of language to someone else enables them to see inconsistencies of weaknesses in the used terminology.
Additionally, new ideas may emerge through the continued development of the software which requires new terminology for the ubiquitous language. A development team, can be very useful in defining such new terms together with business.
Being an external party, looking in to the domain from the outside, oftentimes gives the developers a unique perspective that can be really helpful for the business stakeholders.
NOT ALL WORDS NEED TO BE PRECISE
Perhaps the term “Product” is used interchangeably for an “Article” or an “Offer” in a web shop. Perhaps different members of a team use the same words for different things. This is completely normal and it’s frequently the case when those terms do not need to be well defined.
The Inuit people of Canada have over 50 words for snow, and the reason is because, well there is a lot of snow and it’s important to have this precision of vocabulary. For the average person in southern Europe, for example, a single word would suffice.
Similarly, for a team dealing with Pricing, it is perhaps quite important whether a thing is a “Product” or an “Offer”, but for a person in the accounting department those words do not need to be used so precisely.
Some words will be extremely important for the purposes of our business stakeholders, and other less so. We should try to identify the most important terms and prioritise standardising these first and not aim to perfectly specify everything.
THERE IS MORE THAN ONE UBIQUITOUS LANGUAGE
It is quite a common misconception that a ubiquitous language should be ubiquitous everywhere, to all stakeholders within a company. This is not correct.
Stakeholders working in different domains will have their own distinct terminology which can be mutually incompatible with that of other teams. It is foolish to attempt to define a vocabulary that can be used through an entire organisation.
The idea of a ubiquitous language refers to the shared language between the developers and the respective business stakeholders. If a development team, or indeed, an IT system serves several distinct business stakeholder groups from different domains, then there will be several “ubiquitous” languages that the development team will need to work with.
We need to consider this fact when working with different stakeholder groups and to be open minded about terminology and not to be too strict. It is quite possible that when two different people are using terminology differently that they’re both correct! Perhaps these individuals simply work in different teams and hence require a different usage of the terminology in question.
CONCLUSION
Formalising a ubiquitous language is a worthwhile investment to make and can improve the lives of developers as well as business stakeholders. We need to take care not to be too dogmatic and to treat different departments separately to reflect the complexities of our business.