The rationale for the business domain

The business domain is the yellow-marked area

The business provides the context for the product to be built but also may instruct which processes to follow, what productivity is expected, and which people (experts) to use.

• In relation to the product, the ‘business’ is the customer of the software development department.
• In relation to the processes, the ‘business’ is the supplier of the software development department. E.g. laws, regulations, rules, etc.
• In relation to the experts, the ‘business’ provides that expertise to the software development department.
• In relation to productivity, the ‘business’ provides guidance on the importance of functionality, and sets milestones and deadlines.
• In relation to ‘assessment’, the ‘business’ can provide information on what needs to be assessed in which stage of the development.

In all cases, an organization needs to construct a common base and assimilate that knowledge with the software development department defining the application board and the roadmap, and with the testing department defining the testing board.

A known quote says ‘In God we trust, everything/everyone else we audit’. To ‘assess’ the true status of what is happening only helps to do better every day.

This is why, this is the motivation for an organization to have a business domain. The organization sets a goal to have an organization suitable to deliver the right products and the cornerstone is the business domain. To be successful they will use the business domain to plan. If you have a goal and don’t plan, your goal is merely a wish and the organization will probably fail. Success doesn’t happen by accident, therefore we must assess the plan is always in line with the business domain.