The Schema
Diagram:
Damaging
Enterprise Software
Development*
* Even more than it was
damaged already
Slide 2
Slide 2 text
Me
Sean Reilly
@seanjreilly
+Sean Reilly, etc
Equal Experts UK
Slide 3
Slide 3 text
Agenda
Enterprise software
development
Enterprise architects
Schema diagrams
How everything goes wrong
How (maybe) to fix it
•
•
•
•
•
Slide 4
Slide 4 text
Enterprise
Development
Very different from a startup or
small company
Age of
employees
Dev : Manager
ratio
8pm at the office
Technology stack
Dress code
Certifications
Operations
Lead time
Motivations
Slide 5
Slide 5 text
The Biggest
Difference
Different funding
Different part of the
organisation
Different development
culture
Different development
schedules
•
•
•
•
Multiple Teams
Working on pieces of a
“software suite”
Slide 6
Slide 6 text
Making This Work
Focus on overall efficiency vs
local efficiency
Tension between local and global
effects
•
•
Slide 7
Slide 7 text
Example
Java vs. Ruby
Ruby makes this utility 10%
cheaper
Adding ops expertise w/ ruby
costs £££
Total languages across the
organisation
Ruby is the better local choice
•
•
•
•
•
Slide 8
Slide 8 text
Enterprise
Development
Counter-intuitive unless
considered from a global
perspective
Slide 9
Slide 9 text
Role of an Enterprise
Architect
Given a complex software suite
composed of independently
developed pieces, focus on the
global perspective
Slide 10
Slide 10 text
Schema Diagram
Tools
Automatically generate a
diagram by processing database
metadata
Slide 11
Slide 11 text
Why Do This?
Difficult task
Architects are lazy people too
The tool can produce
something
•
•
•
Slide 12
Slide 12 text
Why is This a
Problem?
Almost what is needed
Wanted a diagram of a
complex system
Instead we have a diagram of
how the system persists data
Not useful for analysis
•
•
•
•
Slide 13
Slide 13 text
Would you describe a
video game using the
format of its save game
files?
Slide 14
Slide 14 text
Not a Problem with
NoSQL
Multiple technologies
Do more in the
application layer
Less is more
•
•
•
Slide 15
Slide 15 text
What Goes Wrong
Next
Mistake the map for the
terrain
Makes implementation
details public
Encourages interaction via
persistence
•
•
•
Slide 16
Slide 16 text
What Goes Wrong
Next
In other words, encapsulation is
destroyed!
Slide 17
Slide 17 text
How do you get from
“almost the right
diagram” to “damages
enterprise software
development”?
Slide 18
Slide 18 text
WHAT?
Slide 19
Slide 19 text
Externality
A side effect or consequence of
an industrial or commercial
activity that effects other
parties without this being
reflected in the cost...
Slide 20
Slide 20 text
The Story So Far
Lack of encapsulation hurts
development
Feels like the organisation
taxes projects
Reasoning about software
using persistence breaks
encapsulation
Schema Diagrams encourage
•
•
•
•
Slide 21
Slide 21 text
Fixing the Problem
Easier to prevent than fix
Interact through code, not
persistence
Change the diagram type
Diagram interactions, not
storage
•
•
•
•
Slide 22
Slide 22 text
What to Use Instead
Web Services
REST
JMS/Messaging
Anything that can use
multiple versions
•
•
•
•
Slide 23
Slide 23 text
The Dirty Truth
Need support from your
organisation
Things will go slower at first
•
•
Slide 24
Slide 24 text
Let’s Try That Meeting
Again, Shall We?
Slide 25
Slide 25 text
Common Objections
Too much work
Duplication of data
Views provide enough
abstraction
•
•
•
Slide 26
Slide 26 text
The Secret Benefit
If an application’s persistence
is an internal implementation
detail, then it’s easy to
migrate to MongoDB!