«    »

The Two Domain Problem

Most professions and trades only need to know their own domain of practice, not the customers. When you see a dentist or a plumber they do not need to understand what you do in order to work on your teeth or your plumbing. Software development is different: its essence is the automation of work. So we need to understand not only the realm of software, but also the business domain that we are trying to automate. If you do not bother to understand your customer's world and the work they need to get done, then you will waste your time producing software that is unneeded, unwanted, and unused.

It is hard enough to master one domain of practice: it is not reasonable to expect software developers to master another. It is also not uncommon for developers to periodically change projects, teams, or companies, resulting in a different business domain to deal with that they must learn from scratch. Likewise, it is not reasonable to expect the customer to be knowledgeable about software. This then is the two domain problem: creating great software requires knowledge of two domains that no one person has.

Some of the key reasons for I.T. project failures and challenges are due to this problem. Failure to address the customer's real requirements leads to unused software. Constantly changing requirements leads to massive cost and schedule overruns. I.T. struggles to understand the business and what they need done while the business struggles to understand the possibilities regarding how the system will help them and integrate into their business processes.

The I.T. industry has tried various methods to address these challenges, with varying levels of success dependent upon how well the two domain problem is acknowledged and addressed. In some cases I.T. has tried to make the business responsible for coming up with requirements, and then acting as a black box that produces a working system without any further business involvement. This exasperates the problem by minimizing any chance for each party to learn more about the other's domain. The business analyst role is another attempt to combat the problem. Unfortunately, the focus of formal business analysis training seems to be on generic analysis techniques, which risks under-appreciating the value of possessing domain knowledge and expertise. Approaches that maximize communication between business and I.T. and encourage ongoing learning by both parties are most successful at addressing the two domain problem, and it is no surprise that these form some of the underlying principles of agile development practices that are now employed by a majority of the industry.

The two domain problem is one of the reasons why producing great software is hard, and is perhaps a reason why software developers are often interested in creating frameworks, libraries, or tooling for use by other developers as this largely avoids the problem. But for the majority of us producing software for use by non-developers, the two domain problem cannot be avoided and must be dealt with.

If you find this article helpful, please make a donation.

«    »