Agile methodologies typically focus on software development. It may appear as if writing code is the only aspect of agile delivery. But we know that most applications use data and this data must be stored somewhere, preferably in a database. This is an integral part of any application.
The question then becomes: how do we develop the data model for the database in an agile manner? The book The Nimble Elephant: Agile Delivery of Data Models using a Pattern-based Approach by John Giles addresses this question and gives in-depth advice on how to make it work.
Choose a data model pattern
How do we come up with a data model quickly in order to allow iterative development to start? The author of the book John Giles suggests to use industry-standard data models or data model patterns as a starting point and customize them as you go. He says that off-the-shelf proven data model patterns may go a long way towards bridging the speed versus quality divide. Elementary data model patterns are the “nuts and bolts” of data modeling. They include items such as ways to resolve many-to-many relationships, and to construct self-referencing hierarchies.
There are many places where we can find data models to be reused. Almost always you may find that a generic industry data model has already been designed. A popular resource for industry standard data models is The Data Model Resource Book series by Len Silverston but there are many other sources as well. It is likely that we won’t find the exact data model that fits our requirements. The idea is to look for something that resembles what we need closely enough, so that we can start quickly and then evolve with more detail in subsequent iterations.
Customize the data model pattern
Customizing the data model pattern might mean adding additional details to the initial data model. Another way to extend the data model pattern is to flesh out the generic superclasses with your own specialized subclasses. Yet another way to use patterns is to link a set of patterns in new ways to suit your unique requirements.
There is always the question of achieving a balance between specific models highly tuned for a particular requirement versus generic models that are flexible and better able to adapt to yet unknown requirements. An elegant model that uses generalized patterns may require a higher skill level for developers. On the other hand, if you have a multitude of denormalized classes with little or no generalization, it is better suited for communication with the business, but it is unlikely to be effective for implementation. Finding the sweet spot between the two extremes is a balancing act.
Have the big picture in mind
Although in agile we may be pressured to come up with a data model quickly so that development of the current iteration can progress, we should have the big picture in mind when choosing the initial data model pattern. Even if the current project has limited scope, we may want to keep an eye out for the enterprise view and choose a model that will eventually span the entire business. We will just add details to the model for the current scope.
In the spirit of agile/iterative development, the data model model can be fleshed out in greater detail on a project-by-project basis. The author suggests that this is to be done selectively. Components that are essential to project progress get greater attention. Of course this is a never-ending exercise and you should expect that part of each iteration will be the refinement of earlier modeling work.
This book provides actionable advice on how to make data modeling work even when we have to do it as part of agile delivery and I am sure to put some of this advice to use in my subsequent projects. I would definitely recommend this book to data modelers both in agile as well as in non-agile environments.