The Diminishing Role of the Data Model?

Cameron Johnson Posted 10 August 2016

Data has been a key factor in the success or otherwise of every IT (Information Technology) project or system that I have ever been exposed to, and I would go so far as to say that this is true of all systems.

All too often the data requirements are undefined, misunderstood or under estimated, resulting in a late scramble to define, acquire and manage the data required to support the business process. Nowadays it is common to point a finger at agile development practices, but as suggested above, this is not a new issue. It is my contention that the discipline of data modelling has lost focus over time, and that this has contributed to the problems described above.

The logical model

Data models describe entities (for example ‘customers’ or ‘orders’) and the associations or relationships between these entities. These data models exist in a variety of forms and levels of detail from physical (the form that is actually implemented in our systems) to logical - depending on their intended use. My interest in this piece however is in the more abstracted forms of the data model – the logical model 1.

Logical models capture the key business objects that support business processes, and the relationships between them. As a result they are vital tools in ensuring alignment across business and technical resources. Our interest at this stage is not in the minutiae of data types or field lengths. The focus is on developing a logical model that correctly represents the business needs - so that the final solution is not constrained by incorrect and untested assumptions. The semantics of the data, the business meaning of that data are drawn out in a data model, as the conversation delves into the attributes and relationships. As importantly, a data model supports the creation of a common language.

The key to these benefits is to ensure that the data model is developed in a collaborative manner. In my experience this process normally kicks off as a facilitated workshop involving both business and technology individuals, driving out the content of the solution. Once the initial workshop process has completed and a draft model designed, I’ve had considerable success just projecting the resultant model, as represented within a CASE (Computer Aided Software Engineering) tool, onto a screen to use as the basis for further discussion and refinement. Once of the concerns I have frequently heard expressed is that a data model is too intimidating to show to the business. I don’t buy this. The business people I have worked with instinctively ‘get it’. It is after all their data and they understand the meaning and nuances of the content.

As one example of the value of this approach, I am reminded of a past project for a large retailer where the incumbent, bespoke wholesale order processing system was being retired. The ability to derive and present logical models which encompassed the affected business processes enabled both business and vendor resources to rapidly align on the capabilities (and possible deficiencies) of the replacement application and fewer surprises downstream.

In summary

I suggest that when your next project is initiated, ensure that sufficient attention is given to agreeing the required data model. This will unlock one of the key elements contributing to the success of the project.

1For the purposes of this piece conceptual and logical models are loosely grouped together.