Slide 1

Slide 1 text

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!