The alignment
@ziobrando
About me
Very hard to explain my job to my mother
running www.avanscoperta.it
Modelling (almost) everything with sticky notes, markers and a paper roll.
Calling this stuff
In the last years
• seen many more companies and ecosystems
• Went quickly to the core problems
• Started to see patterns
• #SelectionBias
Big Picture Workshop
Invite the right people -> Business, IT, UX
Provide unlimited modelling space
Surface, Markers, stickies
Model a whole business line with Domain Events
Establish a timeline
Some facilitator tricks will kickstart the discussion quickly
Explore with domain Events
The underlying knowledge
Enforcing the timeline
Experts will usually post a locally ordered sequence of events
But enforcing a shared timeline then triggers long awaited conversations
Outcome (big Picture):
The whole process is visible
Massive learning (crossing silo boundaries)
consensus around the core problem
Outcome (big Picture):
Multiple storytellings
Incremental Notation #NoUML #NoBPMN
A language for different tribes #Lean #UX #Agile #SW
More specifically…
No scope limitation (paper roll)
Exploration of boundaries (External Systems & People)
-> The BOTTLENECK is in the picture.
-> The CORE DOMAIN is in the picture
Awesome! … now what?
1. The shape of the problem
I might start here
But it starts from here
#BlameTheSilos
Silos must have a reason
Silos minimise the amount of learning needed to be “productive”
unfortunately, the emerging structure of silos is hardly reversible
Even small organisations will tend to become silos if not managed otherwise
… if only we could make learning cheaper… ;-)
Asymmetry
And this is what you get
But fragmented knowledge is only one ingredient
Let’s look at the outcome
There are recurring patterns in blockers
A clear business narrative
A massive blocker
Recurring anti-pattern
“That’s our key class”
Big class with overloaded responsibility in the disputed land between 2 (or more) Bounded Contexts
Nouns won’t helpEverybody agrees what an order is?
Of course we do!
An order is an order!
And has a customer too! Agreed!
Perfect recipe:
Talk with many people
Model Data-First (everybody agrees on nouns)
Add some “Dogmatic DRY principle”
Repeat
The Big Ball of Mud
I swear it was a monolith last time I
checked!!!
One solution
A Draft Model with loose integrity constraints
Constraints implemented as warnings
A Validation barrier (constraints implemented as blockers)
An Execution Model, with similar data structure, but different behaviour
Data-first modelling is flawed
And we knew it from Long Ago… #DDDesign
Everything is a code smell here!
follow the money
• Bad code is everywhere!
• Implementation flaws with the highest negative impact on the enterprise are mostly related to missing or wrong bounded contexts
Wait! Monoliths and BBoM aren’t necessarily the
same thing!
Monoliths mechanics
It takes little to worsen the code
It takes a lot of effort to improve it
LEGO Entropy laws
Mixing LEGO boxes takes seconds
separating LEGO boxes takes ages
Database Entropy laws
Make a copy of an important table and give it a nontrivial name
Measure how much time is needed to remove it
#INeedToBeSure…
Asymmetry
People will try to improve systems only if they’re going to be around long
enough to see the benefits
Will you clean your hotel’s garden?
Asymmetry
We can’t hire good developers
A portion of our codebase is so bad that devs quit
the company whenever we ask them to touch it
Most companies don’t understand technical debt
until it’s too late
They might, but waiting their “permission” is a losing strategy
Refactoring stories won’t help you
• Product Owners will prioritise about what they know.
• Total transparency, but YOU are the expert.
…Hidden agendas, unclear benefits, many other
reasons…
Asymmetry
Features bring revenues, refactoring reduce risk
If we could start from scratch…
Conceptual boundaries
Implementation boundaries
2. The Impediment
Some companies attacked the problem Some didn’t
You don’t mess with the Bottleneck #ToCot
A clear business narrative
A massive blocker
The author of the original software was still around
The dungeon master
• Authors of the original code
• Only ones knowing some areas
• Can’t be beaten on their own playground
https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f#.1koij6bk1
And then I discovered…
Bias: I only recommend books that prove me right.
“indefinite procrastination”
We finally opened up that portion of the
code!!
WOW! It was smelling bad in 2011!!
It was buggy as hell… :-/
Guilt?
protection?
We have a few problems here
In a talent-driven job market, nobody cares about your monolith
Thin red line
• Start a project with a data first approach
• Lack of control requires protection & specialisation
• few people become key, others retire or get minionized Business grows on top of old code
• More responsibilities: less time to change it, harder to make the call
• Hard to recruit seniors to finish the job
Thin red line
• Postpone evolutions of critical software
• prevent the organisation from getting new feedback
• -> how long are your iterations?
• Suddenly realise that the organisation is dumbed down and blames IT for everything
They’re the same problem
We don’t have dungeon masters: everything is developed by
contractors
People will try to improve systems only if they’re going to be around long
enough to see the benefits
Will you clean your hotel’s garden?
Accelerated Growth
• A few developers build up the foundations
• Success brings money -> Hiring frenzy #Scale #recruiting
• Hiring is too slow -> Outsourcing
• External code is now maintained internally.
• Builders -> controllers -> caretakers -> cleaners
3. The business
Not a single business vision wasn’t flawed
There is value in “discussing business” …and “Don’t worry about it” isn’t the best answer
Transparency helps
People won’t self organise around a system they don’t
understand
My personal experience
EventStorming +
Radical Transparency
A “culture” of rewarding exploration
a clear mission
Transparency is hard
Competing goals anyone?
“agile doesn’t work here”
The purpose of our organisation is to make
money
so…
“agile doesn’t work here”
One more time: Agile doesn’t happen in a vacuum
Purpose matters
Yep it’s Pink on Purpose
Good news: The Rise of Good Companies
ConclusionsSometimes you have to wrap-up
The curse of enterprise monolith
natural tendency
natural tendency
“It will pass” is not a strategy
Monolith and dungeon master are often the same
problem
The monolith is the dungeon
Stop pretending that it’s cheap
Events are way better to prevent it
can’t solve one ignoring the other
#feelings & #Code
But the coding ecosystem is OUR responsibility
Can’t delegate it to pixies
A clear business narrative
A platform for self-organisation
Transparency & purpose will make magic happen
Questions?
Every question is welcome, except
“When will you finish the book?”
Questions?
Thank you!
References
References• www.eventstorming.com
• EventStormers on Google+
• https://plus.google.com/u/0/communities/113258571348605620818
• LeanPub book in progress:
• http://leanpub.com/introducing_eventstorming
• Blog:
• https://medium.com/@ziobrando
• http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation:
• http://www.avanscoperta.it