Ubiquitous Language

Business language is a pain in the ass. People are way too smart and capable of dealing with ambiguity, and the more familiarity they have with a particular domain the more ambiguity they can handle. They use multiple words for the same thing (perhaps with subtle differences between the words, perhaps not) and they simultaneously use the same word for different things. If you're not "in the know" it can be very confusing. Worse, it may be confusing the people who *are* in the know - the loose language may be obscuring inconsistencies that only become clear when you try to apply automation (computers aren't as tolerant of ambiguity as people are).

There have been multiple attempts at dealing with this problem. Once upon a time it was common to say that business analysts were translators, responsible for taking things that the business understood and turning them into things that the developers understood. Of course this involves waste, in the form of hand-offs and delays, and inevitably introduces defects.

Extreme Programming introduced the idea of a System Metaphor, but most people find it hard to come up with an appropriate metaphor for their application. When someone mentioned this to Martin Fowler at a conference he said "Oh, we just use the naive metaphor" - that is, the developers used the language of the business.

Other people use different words for the same idea - System of Names for example. Domain Driven Design also has this idea at its core. However, the most common term for this idea is Ubiquitous Language.

Ubiquitous language means that everyone in the team is using the same language for the same things - mainly business concepts, but if there are important technical concepts these should be part of the language as well. The language also needs to be precise - coming up with ubiquitous language often requires disciplined analysis from a number of stakeholders (ubiquitous language does not come from one person working in isolation).

Normally we ask a team to converge on one set of language, but I'm currently working with a project that involves both a vendor and their customer.The vendor already has a well-developed set of language around their product, and the customers have a well-developed set of language around their business processes. Probably neither set of language meets my definition of a ubiquitous language, but we should try move them in this direction. Reducing them to one set of common language would probably be impossible, so we probably have to live with both sets for the duration of the program.