Data Modelling For Software Engineers (Full).key.pdf
- 1. DATA MODELING FOR SOFTWARE ENGINEERS G E T T I N G Y O U R E N G I N E E R I N G L E A D E R S T O S M I L E A G A I N G E T T I N G Y O U R D A T A L E A D E R S T O S M I L E A G A I N G E T T I N G Y O U R A R C H I T E C T S T O S M I L E A G A I N G E T T I N G Y O U R P R O D U C T L E A D E R S T O S M I L E A G A I N G E T T I N G Y O U R O R G A N I Z A T I O N T O S M I L E A G A I N © 2025 Scott C Sosna scott-sosna
- 3. Data Architect Product Software Engineer Leadership Data Governance Legal Database Admin Data Modelers
- 5. 7 What Possible Could Go Wrong? Understanding Completeness Quality Usability
- 6. No time to de fi ne end-to-end data vision, get out of my way and let me start coding! S O F T W A R E E N G I N E E R X “
- 7. 9
- 8. 10 DATA IS FOREVER …but your software is not…
- 9. 11
- 10. 12 Architect Enterprise, Solution, Application, Integration, Data Who Am I? Life-long technologist with professional experience across multiple business domains, tech stacks, and responsibilities. Engineer Most recent position returned me to hands-on software engineering after long hiatus. Speaker/Writer/Mentor Enjoy sharing experiences, insights, expertise, war stories of my career, both good and bad. Traveller Too many places on my bucket list! C o n t a c t I n f o [email protected] LinkedIn: /in/scott-sosna DZone: /authors/scsosna
- 11. 13
- 12. 14 TODAY’S GOALS Becoming Data First Driven top-down not bottom-up, requires senior leaders’ buy-in, replaces existing processes, changes culture. De fi ning Career Path Impacted by business goals, role diversity, personal goals, no simple answer for any one person. Data Modeling Tutorial Industry, technology, non-functional requirements, culture impact organizational approach. Data Modeling 101 Design/implementation decisions impact your solution’s overall viability … and your organization’s success. Decouple, Please! How outsiders consume your data may not match its internal representation …. and that’s not necessarily bad. Wrap Up Other considerations, final thoughts, Q&A.
- 13. 15
- 14. 16 Definitions How is data used in your solutions?
- 15. 17 CATEGORIZING DATA Some obvious, some not Messaging APIs Persisted Hardware Generated
- 16. 18 HOW IS DATA USED? Application Data maintained and shared in your solution supports day-to-day business activity. Reporting Aggregated data provides view of state of business and identifies new opportunities. Integration You and outside providers exchange data for mutually beneficial reasons. Intellectual Property Your data differentiates you from competitors and is your company’s raison d’état.
- 17. Data is like garbage, you’d better know what you are going to do with it before you collect it. M A R K T W A I N ( M A Y B E ? ) “
- 18. 20 Data Modeling 101 Data Modeling screams waterfall: data models always preceded code. Not today. Today, code changes to implemented data structures in whatever form is modeling data: persisted, published, exchanged, cached, measured.
- 19. 21 Need To Know Key points to realize before you start…. Never Means Maybe Certainty is fleeting when business requirements change. All Changes Impactful No change inconsequential, everything visible to everyone. What Code Comments? No IDE to open, no inline comments to review. Formal Documentation Few created, fewer reviewed, none accurate.
- 20. 22 CONSISTENCY Naming Data naming more important than code naming: name visible to everyone. Data Type Choose a data type and stick with it. Epoch or structured date/time for timestamps? String, number, native for booleans? Decimal points on a percent? Enums to represent closed set of values? Structure Consistency reduces cognitive complexity, increases productivity, reduces bugs. Validation Validate once, validate always: database constraints, data type limitations, common code libraries.
- 21. 23
- 22. The good thing about standards is that there are so many to choose from. A N D R E W T A N E N B A U M “
- 23. 25 Standards Rarely need to create your own, so don’t! International Industry Corporate Business De facto
- 24. 26 Inspiration Don’t recreate the wheel if you don’t need to. https://github.com/Microsoft/CDM/blob/master/docs/CDMPoster_a3.pdf
- 25. 27 Don’t … Overuse Optionality Identify By Business Keys Codify ALL or NONE Inject Compliance Problems Store Localized Data Don’t Repeat Yourself
- 26. When in doubt, talk it out. S C O T T S O S N A “
- 27. 29
- 28. 30 Decouple, Please! Consumers whom know - or think they know - your data often implement in ways that make it difficult to evolve your data later. Keep Data Behind Closed Doors
- 29. The ability to evolve your data implementation is inversely proportional to outsiders’ knowledge of current state. S C O T T S O S N A “
- 30. 32 KEEP YOUR SECRETS Again, some obvious, some not. Structure Identity Validation Flow
- 31. 33
- 32. 34 INTERNAL EXTERNAL BALANCING ACT Are internal and external consumers handled differently?
- 33. 35 Wrap Up Other considerations, final thoughts, Q&A.
- 36. 38 FINAL THOUGHTS Understand your organization Business domain, target audience, core competencies, processes, definition of success Know Your Platform Leverage capabilities, improve maintainability, reduce costs. Accept Problem Statement, Not Solution You own the tech domain, someone’s proposed solution will become your future problem. Anticipate Future But Implement Selectively Listen to functionality discussions carefully to anticipate and (perhaps) future-proof your data design.