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

ScottSosna 9 views 37 slides May 09, 2025
Slide 1
Slide 1 of 37
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37

About This Presentation


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 Agi...


Slide Content

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

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

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

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

No time to define end-to-end
data vision, get out of my way
and let me start coding!
SOFTWARE ENGINEER X

9

10
DATA IS FOREVER
…but your software is not…

11

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

13

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.

15

16
DefinitionsHow is data used in your solutions?

17
CATEGORIZING DATA
Some obvious, some not
MessagingAPIsPersisted Hardware Generated

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.

Data is like garbage, you’d
better know what you are
going to do with it before you
collect it.
MARK TWAIN (MAYBE?)

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.

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.

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.

23

The good thing about
standards is that there are so
many to choose from.
ANDREW TANENBAUM

25
Standards
Rarely need to create your own, so don’t!
International
Industry
Corporate
Business
De facto

26
Inspiration
Don’t recreate the wheel if you don’t need to.
https://github.com/Microsoft/CDM/blob/master/docs/CDMPoster_a3.pdf

27
Don’t …
Overuse Optionality
Identify By Business Keys
Codify ALL or NONE
Inject Compliance Problems
Store Localized Data
Don’t Repeat Yourself

When in doubt, talk it out.
SCOTT SOSNA

29

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

The ability to evolve your data
implementation is inversely
proportional to outsiders’ knowledge of
current state.
SCOTT SOSNA

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

33

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

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

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

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

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.