when should data modeling be done?

Question

I want to get your clarifications about some points:

1. Should data modeling (e.g ERD) be ignored at the beginning of a project and then be done later after the project is complete, especially if the project developers don't have all the details about the database at the beginning of the project?

2. In Agile methodology, when should data modeling be done? Can it be done at the end of the project? Or must it be done at the beginning of the project?

Answer 1

1-Should data modeling (e.g ERD) be ignored at the beginning of a project and then be done later after the project is complete, especially if the project developers don't have all the details about the database at the beginning of the project?

Don't ignore the Data modeling , it should be covered as soon you start writing use cases and the modeling of the project.

1. Focus on real-world (problem domain) objects.
2. Don’t mistake your domain model for a data model
   • Don’t confuse an object (which represents a single instance) with a database table (which contains a collection of things)
3. Use generalization (is-a) and aggregation (has-a) relationships to show how the objects relate to each other
4. Don't be a victim of analysis-paralysis - always limit your brainstorming session to few hours and try to convert the use uses into domain modeling and the you will automatically cover the data modeling as move in project step by step

Answer 2

Data modelling is the first thing you do, not the last!

Every part of 99.9% of all applications is either manipulation of the data or some kind of presentation of it. If your developers don't understand that data, they literally can't do that. In agile you might make it up as you go along to a certain extent but it's still the foundation of any app (actually 'system' as there are often reports, reconciliation, batches, feeds, services etc. that don't have a user).

I'd argue that even your business needs a data model to truly understand how it operates and, more importantly, what it operates on.

Answer 3

In any iterative/agile environment, analysis and design of architecture and domain model is continuous process. The basic assumptions are that in the beginning of the project, you have only basic ideas of what the software should do. And that over time, feedback from users, stakeholders and developers will change (sometimes drastically) how domain should be represented. Idea that domain can be modeled as first thing in the project and that this model doesn't change is irrational at best.

To achieve this, you should focus not on modeling the domain, but on making changes to the domain simple and painless. For example, in non-iterative development, there is an idea, that document describing the model is first created (ERD) from which the code implementing it is created. So any change to the model must be done twice, once for the document and second for the code. This makes such change more expensive to do. This is part of Agile Manifesto as "Working software, over comprehensive documentation". It is also part of Domain Driven Design, where the domain is modeled not in document, but in code.

All of this is idea of evolutionary architecture. Which is an ideology that architecture is not created at once, but evolves over time. And embracing this ideology allows creation of architectures that are better suited for their purpose. And it is again agile thinking that embraces change instead of trying to predict it.