I spend a lot of time with software developers. Most of the time I spend is clarifying semantics between business domain and technical domain. Semantics have to do with the meanings of words or terms. In the business domain, when semantics are ambiguous it is often context that allows us to clarify. I work hard to clarify terms that users posit to describe the entities and operations we are modeling in the software we use.
When words are “overloaded” it is hard to avoid being confused because we use the same word to describe multiple distinct entities or operations or operational states. Much of the overloading occurs because “qualifiers” are embedded in business context, so to the business staff, the qualifiers are unnecessary.
Sometimes, though business people actually use the same word differently in the same context and you end up with a buffalo. I recently ran into a buffalo in my application domain. The term “Rack Partition”, was used by the business to describe three distinct things: two nouns and a verb. Here are the definitions:
Rack Partition: 1 n – the recommended ratio of size and value items within a portion of any merchandise display. The rack position is selected by the merchandising advisor, to reflect the distribution tolerance of the client. It is selected by a distinct list of recommended ratios described in the merchandising policy manual.
Rack Partition: 2 n – the current ratio of size and value items within a portion of a specific merchandise display.
Rack Partition: 3 v – to adjust the current ratio of size and value items within a portion of an merchandise display into compliance with the recommended ratio. An activity performed by an merchandising professional.
When a term is overloaded like this, you end up with sentences that sound nonsensical:
“The merchandising advisor rack partitions the display to ensure that the rack partition is aligned with the rack partition.”
Clearly this is unintelligible, and my customer would recognize that this cannot be turned into a meaningful sentence without some qualification. The problem is, what to do when you encounter this situation. How do you disambiguate the terms.
If I were developing software from the current definitions, I would have two distinct business entities represented by classes both likely to be named RackPartition, and potentially a software capability also called “Rack Partition”.
So before I develop software, I need to clean up my semantics. So reading the definitions, I can discern that some qualification comes from the definition.
1) Kill the verb – it is clearly a case of noun verbification. When you verb a noun, you get words like operationalize, teamify, and pontificate. What is it that is the action in the definition? Adjust? Adjust what? Distribution? hmm.
2) Qualify the nouns – 1 is a recommendedRackPartition – the key word there is recommended It could also be a risk policy or rack recommendation. 2 is a property of the display itself. it is a displayRackPosition, or a proposedRackPartition.
3) Don’t add unnecessary qualifiers – Since these all have to do with the Distrubtion of a display, we can talk about adding distribution as a qualifier – so that we have distributionrackPartition or some other set of qualifiers. Since the domain doesn’t have another pack partition – that is not distribution, this qualifier adds little value.
Here are the refined definitions:
Rack Recommendation n – the recommended ratio of size and value items within a portion of any merchandise display. The ratio is selected by the merchandising advisor, to reflect the distribution preference of the client. It is selected from a distinct list of recommended ratios described in the merchandising policy manual.
Proposed Rack Partition n – the ratio of size and value holdings within a portion of a specific proposed merchdise display rack.
< no verb is needed >
Here is the revised sentence:
“The merchandising advisor adjusts the Proposed rack Partition until it is aligned with the Rack Recommendation selected from the choices described in the merchandising policy manual.”
Now that this sentence is clear, it brings us to several questions that were not clear before.
- How does the merchandising advisor “select” the Rack Recommendation?
- How does the merchandising advisor “adjust” the Proposed Rack Partition?
- How does the merchandising advisor “see” the Proposed Rack Partition?
- How does the merchandising advisor “compare” the Rack Recommendation to the Proposed Rack Partition to ensure alignment?
What we learn when we ask these questions is:
1) The Rack Recommendation is merely a property of the Proposal (a business entity).
2) The Proposed Rack Partition is derived as an aggregate of the distribution coefficients of a subset of items in the proposed display (a business entity).
3) If we had a capability that allowed the merchandising advisor to adjust the “subset” items in the proposed merchandise display while viewing the Proposed Rack Partition and the Rack Recommendation she could “see” and “compare” while “adjusting”.
What I find interesting is that, often, neither the technical staff, nor the customer realize the benefits of clarifying the semantics of our business application domain before commencing development. Technical staff is very concerned about design patterns, layer responsibilities, clear architecture, ease of maintenance. All the best designs in the world will not fix a domain model that is convoluted, that verbs its nouns and has ambiguous terms or worse – the WRONG nouns.
Customer is concerned with making the business change happen, with getting the ROI, with “ease of use” of the application. Focus on these things is important, but the best way to get to them is to clarify your thinking about your business PROBLEM in clear, precise language, that you can use to educate the business community that you are driving change into, and having the application closely aligned with your precise business domain language is perhaps the best start to achieving that.