Many people involved in software development understand their business domain – i.e. they have business or domain knowledge. This is, for the most part, a good thing, for it means that they can have reasonable confidence that they share syntax and semantics with other stakeholders.

However, there are two common issues related to domain knowledge that bear some discussion. The first is the assumption that if we have sufficient domain knowledge, then we understand the problem. The second is a failure to recognise that in almost every significant software development effort, there is more than one domain that needs to be understood.

The Domain Is Not The Problem

When we talk of ‘business knowledge’ we refer to knowledge of how the business operates in its dealings with the rest of the world. For example, equity trading domain knowledge includes: what an ‘equity’ is, the conditions under which equities may be traded, how soon after trading equities we have to settle, any regulations that exist in respect of equity trading, different ways of trading equities, etc.

A team attempting to build an equities trading system would need to know some or all of this information. However, the fact that thousands of equities trading systems have been built suggests that this information is necessary, but not sufficient. There are several reasons why more than one system per domain might be built, such as competition, technology shifts or lack of maintainability of an existing system. However, if these kinds of reasons were the only explanation we could offer, it should by now be possible to build an equities trading system with a near perfect specification and no stakeholder involvement other than that of the development team, since so many have been built before.

The reason that this is not possible is that whenever a system is built, it is built for a particular set of stakeholders. Some of these stakeholders are certainly embedded in the domain but their needs are not limited to the facts of the domain. In addition to these, they have their own needs; organizational, political, usability, taste and fashion, personal goals, different aspects of quality, pragmatics, etc.

These additional needs often form a significant part of what a system must achieve. Sometimes one or more of them is the driving force behind the development effort. Given this, the business domain can inform and constrain our analysis but an understanding of it comes nowhere near to a sufficient analysis of the problem.

Is There Only One Domain?

Whenever there are multiple stakeholder groups, the possibility of multiple domains arises, each with its own associated business knowledge. For example, non-regulatory reporting (i.e. to managers or other groups within an organisation) potentially implies a need that is not relevant to the end users’ domain. If that need is exhibited, then it is the entry point to another business domain; one which is quite possibly unique to the organisation, and which must be considered as part of any competent analysis.

Furthermore, even within one group of stakeholders, multiple well known domains may intersect and interact to create emergent needs. For example, there is a class of systems known as Order Management Systems. Most readers will have used one or more of these when buying products from any online shop. Abstractly, the order management systems of all of these organisations are the same. But the particular classes of products that are bought and sold will have an impact on the details of that system. 

Consider, for example, how an order management system for buying books might differ from one for buying pharmaceuticals or financial products. Even within a single organisation, an order management system for procurement may have very different concerns from one for sales, even though they relate to the same products.

So in this case, when we talk about ‘domain knowledge’, are we talking about knowledge of book publishing, procurement and sales, knowledge of order management systems or knowledge of organisation specific reporting needs? The answer is, of course, that at different times, we mean different things.

Summary

Setting aside ‘Chinese Room’ thought experiments in which analysts and developers manipulate symbols without any understanding of their meaning, domain knowledge can assist greatly when analysing a problem. However, it must be kept in mind that what might be considered the ‘primary’ domain of the problem is possibly not the only domain and also probably does not even include the full set of concerns of the ‘primary’ stakeholders.

These secondary concerns can, and often do, have a significant impact on a software development effort and can even vastly outweigh those of the ‘primary’ domain in terms of complexity and need. The only way to find out about these concerns is to talk to the stakeholders, using knowledge of the domain to enable, but not constrain the discussion.

An Aside

For the most part, sufficient business knowledge to build a system is fairly easy to come by for the inquisitive and skilled developer. This does not suggest that the business is simple; there is a lot more to working in any domain than a casual manipulation of business knowledge.

However, it is a mistake to emphasise business knowledge over technical skills for developers. Software development is a significant multi-disciplinary skill in itself, one which takes many years of thoughtful experience to acquire. To dismiss that in the (sadly too common) belief that ‘as long as the developers understand the business, everything will be OK’, is to ask for a poor implementation that will not stand up to short term scrutiny or longer term needs.

Even worse is the frequently required ‘investment banking experience essential’ on job specifications. What exactly does ‘investment banking experience’ mean? It is denotationaly so weak and connotationaly so multitudinous that it means almost nothing, other than that a candidate must have worked in an investment bank before. Investment banks are frequently huge organisations in which dozens or hundreds of business areas are served. Also, within the overarching culture of the organisation, there are significant variations in attitude from one group or even team to another.