Data Modelling For Software Engineers (Full).key.pdf

Really, data modeling? Is that even a thing any more?



The days of formal data modeling are definitely years in the rearview mirror, empowered teams define their data as they see fit, implement, and move on. Done. And we'll deal with short-comings down the road when they arise, that's Agile, let's keep moving forward (to data architects' frustration when trying to make sense of it all after the fact).



But "modeling data" extends beyond what is persisted in a database server: API Payloads, messages, configuration files, document metadata, Redis indexes are forms of data we define and work with regularly.

1. DATA MODELING FOR
SOFTWARE ENGINEERS
GETTING YOUR ENGINEERING LEADERS TO SMILE AGAIN
GETTING YOUR DATA LEADERS TO SMILE AGAIN
GETTING YOUR ARCHITECTS TO SMILE AGAIN
GETTING YOUR PRODUCT LEADERS TO SMILE AGAIN
GETTING YOUR ORGANIZATION TO SMILE AGAIN
© 2025 Scott C Sosna scott-sosna

2. https://www.ibm.com/think/topics/data-modeling

3. Data Architect
Product
Software EngineerLeadership
Data Governance
Legal
Database Admin
Data Modelers

5. 7
What Possible
Could Go Wrong?
Understanding
Completeness
Quality
Usability

6. No time to define end-to-end
data vision, get out of my way
and let me start coding!
SOFTWARE ENGINEER 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!
Contact Info
[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.
Defining 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
DefinitionsHow is data used in your solutions?

15. 17
CATEGORIZING DATA
Some obvious, some not
MessagingAPIsPersisted 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.
MARK TWAIN (MAYBE?)
“

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.
ANDREW TANENBAUM
“

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.
SCOTT SOSNA
“

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.
SCOTT SOSNA
“

30. 32
KEEP YOUR SECRETS
Again, some obvious, some not.
StructureIdentity ValidationFlow

31. 33

32. 34
INTERNAL
EXTERNAL
BALANCING ACT
Are internal and external consumers handled differently?


33. 35
Wrap UpOther considerations, final thoughts, Q&A.

34. https://www.ibm.com/think/topics/data-modeling

35. https://www.erwin.com/solutions/data-modeling/benefits-of-data-modeling.aspx

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.