Sometimes when you talk about application software, you find that the technicians and the customer are agreeing but don’t realize it. This happens when each party says something that is essentially the same semantically, but they don’t derive the same meaning from it. I have been in that situation many times, because of misunderstandings of the domain semantics or ambiguities in domain semantics.
Other times you have the opposite effect, where the technicians and the customer appear to be in agreement, but have different understandings of the problem or solution, so while all are smiling and nodding – there will be some time when, subsequently, they all realize that they missed something.
One of the reasons that these kinds of miscommunication happen is when the same term has meaning in multiple domains, and different people assume that they know which domain is in play without qualifying or clarifying it. These collisions, where a term has meaning in multiple distinct domains that are relevant in a conversation are sometimes very hard to detect. It feels like a wormhole opened in the conversation and we jumped from one domain to another without realizing it.
At work for the last 15 years, my primary business domain has been investment management. One thing that I have noticed over the past few years is that terms that long ago belonged exclusively to one domain have started to be appropriated by another. Examples abound.
1) Entity – in the domain modeling or database modeling domain the concept of an entity represents a noun in the business domain. In object oriented programming, one would typically construct a class that represents the data (characteristics) and behavior (actions) associated with that business entity. A few years ago, however, “legal entity” is a domain entity which is sometimes shortened in the business vernacular to entity. This creates a collision and perhaps a recursion – and you get a conversation that sounds like “Who’s on first”.
2) Schema – has been in the database domain and the data modeling domain for as long as I have been using relational databases. However, an application which represents some data as XML that is stored in the database has an XSD (XML Schema Document) and the same application has an “Asset Schema” which is a hierarchy of risk categories for investment assets so this schema is comprised of sets of mutually exclusive categories that roll up into parent sets (similar to the taxonomy of biological life forms – genus species being the lowest two sets. The business vernacular for some category in a schema is a “class” or “asset class” which has its own technology domain collision with the term from object oriented programming.
3) Model – we have many models in the software domain from the data model to the object model, and our business domain has model portfolios which effectively are like templates from which other portfolios are constructed or against which they are compared.
4) Product – While software has always been a product, in that there are companies that sell software as a product, we talk about “product management” in the software deliver domain as the process by which decisions are made especially regarding what the software’s purpose and which capabilities best support that purpose. Within the last 10 years, product has become increasingly important in the business domain in that funds and other types of aggregate investments the represent baskets of equity or debt that are managed separately from your investment of them. They implement some managers best practice and guidance around some single or compound strategy or mandate.
5) Portfolio – has been in the business domain for as long as I have been around, an investment portfolio is a collections of holdings or assets around which meaningful aggregations of risk or returns can be calculated. But a few years ago, the term portfolio invaded the project management domain so now we talk about project portfolios. Both portfolios have managers so even the term portfolio manager is not domain specific.
While these examples are not uncommon, they illustrate the problem that occurs in our language, when having a conversation simultaneously involving multiple domains or contexts like we have when we try to design software to model and solve problems in a particular business domain. So what can be done?
1) Clarify what domain (or subdomain) you are talking about as you talk (write).
2) Use qualifiers that are clearly domain specific. (e.g. not model, but domain model, data model, portfolio model, asset model, etc)
3) Adopt alternative terminology – (e.g. asset schema can become asset taxonomy – which has no collision in the other domain).
The hardest thing is when multiple business domains collide and use the same term to mean different, or even more subtly similar things. I have run into this problem in almost every application context that I have worked in, and it can be an extreme impediment to fruitful communication about the problem domain.
The hardest thing for me to understand is not why these collisions occur, but why more of us who design application software aren’t talking about this. I know in the Domain Driven space, they talk about it, and I know some pure model folks who talk about it. It makes me think that many of us don’t understand the object-oriented paradigm as deeply as we claim.