The importance of (models) being earnest Thursday 15th September
I recently heard the story of a software project gone awry at the company a colleague was contracting for.
It turned out that new requirements had come to light late in the day that needed fundamental changes to the data model. Since this was deemed to be too expensive, the project was canned. My friend was adamant that if the data model had been based on a domain model of the business at the outset, the problem would not have occurred. Instead no domain model existed, and the data model had been designed superficially, failing to reflect some fundamental business concepts. When new requirements demanded these concepts to be made visible in the data and the software above it, the proverbial brown stuff hit the fan.
I too have come across examples of this ‘missing/bad domain model’ anti-pattern in my work experience, but thankfully not to the extent that my friend had. Here are just two areas in which I have found that good domain models pay dividends and avoid high maintenance costs.
Batch interfaces / Service APIs
The first example is rather basic, reminding me of fundamental data structuring concepts that I studied in Michael Jackson’s (not the singer) Principles of Program Design textbook.
In a recent project, an interface between a legacy system and a new software platform was based on daily transfer of files to keep the new system updated.
One of these files contained data about groups of objects (let us say groups of accounts), however the design of the file failed to reflect the hierarchical grouping of these objects and consisted of a header, a footer and a flat list of records in between. As a result, some field values were duplicated on each record belonging to the same group. Quite apart from the additional validation required to ensure that all records within a group were consistent, the lack of a record to represent the group meant that some properties of the group were not represented at all within the file and were supposed to be implied by the values of the fields of each record. When new requirements came along, needing new values for these properties, no fields could be found to hold them and an expensive restructuring exercise was needed. This proved far more costly that it would have been to get the structure right at the outset. The moral of the story is obvious - the data structure should have reflected the structure of the world. In other words, if your domain model looks like this:
and you have to transfer data about groups and accounts in a data file, then make sure that your file structure does not look like this:
Use the same structure you have identified in the problem domain, that is:
The irony in this situation was that a robust domain model did exist and was the basis for the new software platform data and component structure. However the data files were designed by the team in charge of the legacy system, who had no access to these models and worked in a more traditional model-less fashion.
The same principles that apply to batch data files also appy to messages and parameters of service operations. Make sure these match the structure of the corresponding domain model elements, to reduce software complexity and make interfaces resilient to changes in requirements.
UI requirements vary a lot according to the complexity of the task, the frequency of use, the type of user and so on. However I have found one element common to all applications where the end users are also the business experts: the concepts the users need to see and manipulate through the user interface must be the same concepts around which the data model and the system business architecture is organised. If differences exist, they will inevitably lead to higher costs in development and maintenance. New and changing requirements will become harder to accommodate. This philosophy has a few practical consequences:
- In complex domains, the domain model becomes the key artefact to share knowledge between business and IT. It is essential that it is produced in conjunction with the business, that the terminology used is agreed by all stakeholders, and that the model is widely understood and communicated. All design activities, UI design, data design and component design will be heavily based on this model. In several projects, visual diagrams depicting key parts of the model become a lingua franca for efficient communication between business and IT.
- Do not try to be clever and produce two separate models, one for business consumption and one for the technical team. Often IT designers are tempted to invent concepts and structures that might make a solution more reusable or generic, but do not match the thinking of the business people. This temptation is to be avoided at all costs.
- Do not pamper your business people by sheltering them from the complexity of their own business world. Attempts to make the user interface less transparent and more idiot proof will lead to inefficiencies and distortions that will not improve business processes and will alienate business people, preventing them from using their business knowledge when they use your application.
In summary, give business users visibility of the applications’ conceptual model of the data, and, conversely, represent the business users’ view of the world, as in their UI, in the underlying data model.
You will have guessed by now that I am a strong believer in building robust domain models as a prerequisite for project success. Models must be earnest in reflecting the business as seen by the business people. Domain modelling is not an academic exercise beloved by purists for its own sake. On the contrary, it is essential to the design of a solution that will last the test of time, especially new requirements.
If you have any feedback on my stories or have had similar experiences, I’d like to hear from you: Franco.Civello@rdfgroup.com.