Ask HN: Event Driven Design/Discovery?
3 comments
EventStorming[1] or Event Modeling[2]?
1. https://www.eventstorming.com/
2. https://eventmodeling.org/
https://eventmodeling.org/posts/what-is-event-modeling/
1. https://www.eventstorming.com/
2. https://eventmodeling.org/
https://eventmodeling.org/posts/what-is-event-modeling/
We're about to try event modeling at my company, does anyone here have experience with it?
The author makes some pretty large claims (it's the end of: scrum, storypoint-estimations , project management and whatnot) and it does sound promising, but I can't help but be sceptical.
The author makes some pretty large claims (it's the end of: scrum, storypoint-estimations , project management and whatnot) and it does sound promising, but I can't help but be sceptical.
I suspect Event modeling is a new buzzword, but the idea isn’t new.
See, if you had the job of automating some business process a few decades ago, you would walk around the office and watch people doing their jobs. You would learn employee A would call some customer, fill an order on paper, then leave it at the desk of another employee from another department. The this other employee would type some other paper, staple it together and dispatch to yet another department, and so on so forth…
If you think in terms of “employees” exchanging “documents”, this naturally leads to capturing the process with a model of a timeline of events. The words Create/Update/Delete simply don’t exist in business vocabulary; nothing in business is “mutate-in-place”; naturally, modeling a process around these notions is a conceptual mistake - it just happens that for a long time now technologists have enforced their tools models (relational databases, OO/ORM, CRUD APIs) onto business process instead of the other way around.
How does it help with scrum, points, project estimation and so on? Well, I guess instead of the usual throwing your hands in the air saying “Nobody knows the requirements! Let’s ship some CRUD based on a mockup and iterate!”, the Event modeling approach at least tries to gather actual requirements earlier in a format stakeholders can understand/contribute.
See, if you had the job of automating some business process a few decades ago, you would walk around the office and watch people doing their jobs. You would learn employee A would call some customer, fill an order on paper, then leave it at the desk of another employee from another department. The this other employee would type some other paper, staple it together and dispatch to yet another department, and so on so forth…
If you think in terms of “employees” exchanging “documents”, this naturally leads to capturing the process with a model of a timeline of events. The words Create/Update/Delete simply don’t exist in business vocabulary; nothing in business is “mutate-in-place”; naturally, modeling a process around these notions is a conceptual mistake - it just happens that for a long time now technologists have enforced their tools models (relational databases, OO/ORM, CRUD APIs) onto business process instead of the other way around.
How does it help with scrum, points, project estimation and so on? Well, I guess instead of the usual throwing your hands in the air saying “Nobody knows the requirements! Let’s ship some CRUD based on a mockup and iterate!”, the Event modeling approach at least tries to gather actual requirements earlier in a format stakeholders can understand/contribute.
I'm sure pretty much anything can beat Scrum™;) That's a very low baseline.
According to its inventor, Scrum™ was created to manage a team of dysfunctional COBOL programmers at a bank. But they're selling it to non-technical managers as a panacy for all SW development problems (and making ridiculously false claims in the process).
"Agile"/Scrum/SAFe is everything that is wrong with our industry.
Don't let me start with storypoints, or SW time estimations in general. Shape Up method using "appetite"[2] instead - a fixed length variable scope time budgets with circuit breakers[3].
Most modern SDLCs are mini-waterfalls with SDUF (Some Design Up Front).
Examples: informal mini-waterfall at FAANG ( design->plan->build(iteration)->ship ), Shopify's GSD (Get Sh*t Done), Shape Up method[1], Event Modeling, EventStorming.
The uniquence of the EventModeling is that it uses a single paradigm - visual canvas/board for almost everything: requirements gathering, UI/UX, Software Design, documentation, and Project Management.
--
1. https://basecamp.com/shapeup
2. Appetite
The amount of time we want to spend on a project, as opposed to an estimate.
https://basecamp.com/shapeup/4.5-appendix-06
3. Circuit breaker
A risk management technique: Cancel projects that don’t ship in one cycle by default instead of extending them by default.
https://basecamp.com/shapeup/4.5-appendix-06
According to its inventor, Scrum™ was created to manage a team of dysfunctional COBOL programmers at a bank. But they're selling it to non-technical managers as a panacy for all SW development problems (and making ridiculously false claims in the process).
"Agile"/Scrum/SAFe is everything that is wrong with our industry.
Don't let me start with storypoints, or SW time estimations in general. Shape Up method using "appetite"[2] instead - a fixed length variable scope time budgets with circuit breakers[3].
Most modern SDLCs are mini-waterfalls with SDUF (Some Design Up Front).
Examples: informal mini-waterfall at FAANG ( design->plan->build(iteration)->ship ), Shopify's GSD (Get Sh*t Done), Shape Up method[1], Event Modeling, EventStorming.
The uniquence of the EventModeling is that it uses a single paradigm - visual canvas/board for almost everything: requirements gathering, UI/UX, Software Design, documentation, and Project Management.
--
1. https://basecamp.com/shapeup
2. Appetite
The amount of time we want to spend on a project, as opposed to an estimate.
https://basecamp.com/shapeup/4.5-appendix-06
3. Circuit breaker
A risk management technique: Cancel projects that don’t ship in one cycle by default instead of extending them by default.
https://basecamp.com/shapeup/4.5-appendix-06
s/uniquence/uniqueness/
IMO you will get the best effect if your underlying SW architecture is CQRS/ES, as it maps nicely to it.
For the initial discovery/ideation I would use Big Picture EventStorming as it's a much simpler notation understandble to non-technical people (if you know what is a sticky note - you can participate;)
IMO EventModeling is more comparable to Software Design EventStorming but with Project Management, full documentation, SDLC, etc.
For the initial discovery/ideation I would use Big Picture EventStorming as it's a much simpler notation understandble to non-technical people (if you know what is a sticky note - you can participate;)
IMO EventModeling is more comparable to Software Design EventStorming but with Project Management, full documentation, SDLC, etc.
Event modelling was the one - thank you! Event storming looks a like a good alternative to review.
i also write recently something about this not eventstorming but more in architecture
https://blog.oedemis.io/serverless-event-driven-architecture...
[deleted]
I remember finding (and subsequently losing the link to) a website a few months ago which outlined a process for requirements gathering and description based around an initiating event and the data transformations that should take place in response to it. All google searches I can think of lead to many articles about event driven software patterns. Hoping someone here knows what I'm referring to!