Your team is divided on data modeling strategies. How do you choose the right approach to move forward?

IIn my experience, resolving divergent opinions on data modelling strategies involves a structured approach: Firstly, gather comprehensive insights into each proposed strategy, understanding their respective strengths and weaknesses. Secondly, evaluate these strategies against your project's specific needs, considering factors such as scalability, performance, and ease of maintenance. Thirdly, foster open discussions within the team to weigh the pros and cons objectively, encouraging constructive debate. lastly, prioritize alignment with long-term organizational goals and technical standards to ensure consistency across projects.

It's ideal never to try to reinvent the wheel. There will always be methods that have worked well or still work. Of course, we must always be attentive to changes and technological advances, but trying to make something overly complex when a simple solution would suffice is counterproductive. Always strive to understand what is expected and aim to meet those expectations precisely and efficiently.

Data modeling is not always the proper solution for all the problems, it's not the silver bullet fit for all the problems. We must see the problem size, if the data size is huge, messy, a lot of data formats we need to unify, data transformation and data modeling might be the good solution for that. It's quite overkilling if you do data modeling for very small set of data, where you can just provide the solutions in spreadsheets maybe, or python dataframe is enough. Asses your needs is very important here.

As Steve Jobs said, "You have to start with the customer experience and work back toward the technology." Before diving into data modeling strategies, thoroughly assess your project's needs. Consider factors like data type and volume, access speed, query complexity, team skills, and maintenance implications. This assessment helps compare the strengths and limitations of each approach, ensuring the chosen model meets your specific requirements. Steps: ?? Assess data type and volume. ? Evaluate data access speed. ?? Consider query complexity. ?? Review team skill set. ??? Evaluate maintenance implications.

Involving the team in the decision-making process is crucial. I make it a point to gather input from all team members, valuing their perspectives and expertise. Holding brainstorming sessions and discussions helps in surfacing diverse ideas and concerns, ensuring that everyone feels heard and included in the process.

From what I’ve learned, comparing different data modeling approaches side by side can be very effective. We look at the pros and cons of each model, considering factors like scalability, performance, and ease of implementation. This comparative analysis often reveals the strengths and weaknesses of each option, guiding us toward the most suitable approach.

Evaluate tools like SAP powerdesigner, Erwin , ER studio , Spark EA In my experience all the tools are more or less similar with few differences in their functionalities SAP PowerDesigner: Robust tool for data modeling, enterprise architecture, and application portfolio management. Widely used in large-scale projects and integrates well with SAP products. Erwin Data Modeler: Focuses on data governance, metadata management, and compliance. Suitable for organizations emphasizing data governance. ER/Studio Data Architect: User-friendly tool with strong version control. Popular among data architects and modelers. Spark EA (Sparx Systems Enterprise Architect): Extensive modeling capabilities (UML, BPMN, etc.).

Before fully committing to a strategy, I advocate for pilot testing. Implementing a small-scale version of the chosen model allows us to evaluate its practicality and identify any unforeseen issues. It’s like taking a new car for a test drive – it helps ensure that it performs well under real-world conditions.

Change is inevitible. Everyday, there will probably be new needs, new products that can help improving our data modelling strategy, probably new business process that need new (adjustment) data model At the end of the day, what's important is the data modelling we have can support the organization's interest in the most efficient manner Thus, iterating on our data modelling strategies is a must do. Collective intelligence through asking feedback from team is one way to do it. In our case, there are always fresh new ideas that in hindsight we didnt realize when we actively look from team's feedback We use scrum to iterate and improve our data model