If you’re a doctor or a civil engineer, everything you do each day is strictly related to what you studied and did previously in the course of your career. It’s different, instead, if you’re a lawyer or a software engineer.
In both these cases, you’re regularly called to exercise expertise in areas you know little or nothing about. As a lawyer, you might have to learn about high finance for the closing argument on a bankruptcy case. As a software engineer, you might have to know about international tax rules to implement the business logic of an online store application.
This is where the ubiquitous language fits in.
Creating a vocabulary of domain-specific terms
If the information delivered to you by domain experts and interviewed users was always accurate and unambiguous, all software would probably ship on time and on budget and the world would be a better place. More often than not, though, requirements contain ambiguous definitions, duplicates, foreign terms, acronyms, and jargon. Sometimes, different people within the same organization use different words for the same concept or use the same word to mean different things.
When domain and software experts speak different languages, finding some common ground is crucial to ensure that reliable communication is set up and no loss of information occurs along the way Looking at the constituent elements of the ubiquitous language.
In spite of the fancy name, ubiquitous language is a simple glossary of all the terms used by experts of a particular business domain. Each term in the glossary is expected to be unambiguous and hold well-defined meaning. Terms are, for the most part, nouns and verbs, and the glossary also includes associations between nouns and verbs so that it’s clear which verbs (that is, actions) apply to which noun (that is, entity). While building the glossary, you might also want to look into adverbial phrases found in requirements and user stories. Adverbs might add extra layers of detail to your understanding and point to relevant aspects of the domain—such as events, processes, and triggers of processes—you might want to account for in the design.
believes that the terms in the glossary should meet the expectations of both domain experts and developers. You have a well-crafted ubiquitous language when the words and verbs in the glossary truly reflect the real semantics of the business domain.
Once it has been defined, the ubiquitous language will be shared by all people participating in the project, whether they are stakeholders, analysts, developers, project managers, or testers. In other words, the language will become the lingua franca of the project and will be used in any form of spoken and written communication, including documentation, email messages, meetings, and project work items.
The development team is typically responsible for developing and maintaining the glossary. The glossary, in fact, is a living thing, and it receives updates and gains new elements as the team learns more and more about the domain.
Choosing terms for the glossary
The ubiquitous language is not an artificial language created in a laboratory. Instead, it emerges from plain discussions in meetings and interviews. In most meetings scheduled to share ideas about a project and the purposes of the project, you typically find two groups of people: domain experts and software experts. Software experts tend to use technical concepts such as “deleting an order.” Domain experts tend to use different wording for the same concept. Perhaps they might commonly refer to the removal of order as “canceling the order.”
Another purpose of using ubiquitous language is to remove gray areas. Consider, for example, the following expression, which you might find in a user story or hear at a meeting: “Extra costs should be emphasized in the user account.”
The intended business purpose is probably well known to an expert and her colleagues, but it might not be obvious to others outside that circle of experts. What’s the intended purpose? In this case, it can be any of the following:
Show costs when the user logs in.
List costs on a detail page.
Mark extra costs in the bill.
The effort of building an unambiguous glossary of terms pays off because it helps clarify a number of possibly obscure points. In addition, it helps ensure different concepts and actions are named in a unique way and, at the same time, ensures matching concepts are detected and named similarly.
The ubiquitous language is neither the raw language of business nor the language of development. Both are forms of jargon, and both—if taken literally—might lack essential concepts, generate misunderstandings, and create communications bottlenecks. Hence, the ubiquitous language is a combination of business and technical jargon. It is expected to contain mostly business terms, but some technical concepts are allowed just to make the final language faithfully express the system behavior. Terms like caching, logging, and roles might not be business specific, yet they are required in the building of the system and might show up in some way in the ubiquitous language.
Sharing the glossary
The value of a language comes from its being used rather than persisted. Just as it might be helpful to have an English dictionary to translate and explain words, stakeholders in a project might find it useful to have a physical place to check for domain-specific terms.
Typically, you should save the glossary to a shared document. It can be a Microsoft Office Excel file placed in a Microsoft OneDrive folder or, better yet, a file collaboratively edited via Microsoft Excel Online. It can even be a wiki. Through an in-house hosted wiki, for example, you can create and evolve the glossary and also easily set up an internal forum to openly discuss features and updates to the language. Also, WEBSITE DEVELOPMENT SILVERDALE recommends that you can use a wiki to easily set permissions and control how editing takes place, and specify who can edit what.
Our highly skilled team at the website development Silverdale points out that any change made to the language should be a business-level decision. As such, that decision should always be made with the full approval of stakeholders and all parties involved.
