Recommended
More Related Content
Similar to EventModeling & Outcome driven design
Similar to EventModeling & Outcome driven design (20)
Recently uploaded
Recently uploaded (20)
EventModeling & Outcome driven design
- 1. Event-Modeling & Outcome Driven Design Arjan Noordhoek Founder, EBD Connect
- 2. Presentation Outcomes Start using/exploring Event Modeling Reconsider how you currently implement systems
- 3. Intro to Event-Modeling Modeling over time, a system’s state changes caused by events. Brainchild of Adam Dymitruk (www.eventmodeling.org) ◦ Domain Driven Design ◦ CQRS (Command Query Responsibility separation + ES (Event-sourcing) Talk the language of the business Simple! (only a couple of symbols) Provide PREDICTABILITY to the implementation process.
- 4. Domain Driven Design Advocates modeling based on the reality of business as relevant to your use cases. It describes independent problem areas as Bounded Contexts (could correlate with a micro service). Emphasize a common language to talk about these problem areas.
- 5. Command Query Responsibility Separation UI/API STORAGE Command Service Query Service Command Model Query Model WRITE READ
- 6. STORAGE Command Query Responsibility Separation + Event Sourcing UI/API STORAGE Command Service Query Service Command Model Query Model WRITE READ Projector
- 7. Event Sourcing Command Handler Query Projector Trial Requested Id email emailConfirmed 423 arjan@modelmycode.com true Trial Id email userId trialEndDate 123 arjan@modelmycode.com Event Stream Payload Trial Requested Trial {trial-id: 123, email: ‘arjan@modelmycode.com’} Trial requested Request Trial Interface Event Stream Payload Trial Requested Trial {trial-id: 123, email: ‘arjan@modelmycode.com’} Email Confirmation Sent Trial {trial-id: 123 } Email confirmation sent Send Email Confirmation Event Stream Payload Trial Requested Trial {trial-id: 123, email: ‘arjan@modelmycode.com’} Email Confirmation Sent Trial {trial-id: 123 } Email Confirmed Trial {trial-id: 123 } Automation Confirm Email Email confirmed Interface User Register User User Registered Event Stream Payload Trial Requested Trial {trial-id: 123, email: ‘arjan@modelmycode.com’} Email Confirmation Sent Trial {trial-id: 123 } Email Confirmed Trial {trial-id: 123 } User Registered User {user-id: 423, trial-id: 123} Start Trial Trial Started Event Stream Payload Trial Requested Trial {trial-id: 123, email: ‘arjan@modelmycode.com’} Email Confirmation Sent Trial {trial-id: 123 } Email Confirmed Trial {trial-id: 123 } User Registered User {user-id: 423, trial-id: 123} Trial Started Trial {trial-id: 123, duration: 30} Automation 423 2023-05-28
- 8. How does it work? Brainstorming (Identify events). The plot (create a timeline of events). The Storyboard. Identify inputs. Identify outputs. Elaborate Scenarios (Given/When/Then). Apply Conway’s Law
- 9. The resulting model can be broken down in slices of work. As each slice contains similar patterns, we can start predicting how much implementing a slice on average will take or cost. Predictability
- 10. “UX is preventing us from being customer centric” The Real Problem The requirements translation and quality gap! The Solution Outcome Driven Knowledge Modeling
- 11. “Project outcomes are results that occur from creating your product or service. They are the changes in policies, people and communities that you aim to achieve with your work” “ Projects outcomes aim to address core problems and drive changes in conditions, behavior or attitudes to provide a positive impact“ Outcome Driven Knowledge Modeling
- 12. Align from the start with business Mission •direction Vision •Outcomes Strategy •Outputs Operations
- 13. Work backwards How do we use ODKM Outcome Convert Trial To subscription Outcome Convert Trial To subscription Outcome Convert Trial To subscription Outcome Convert Trial To subscription Outcome Convert Trial To subscription Outcome Convert Trial To subscription Outcome Trial To subscription
- 15. Outcome Convert Trial To subscription Putting all the pieces together
- 16. Generate Code
- 17. CQRS + ES + ONION
- 18. Presentation Outcomes Reduce project risk Reduce lead times Reconsider how you currently implement systems Start using/exploring Event Modeling
Editor's Notes
- Hi, My name is Arjan Noordhoek and I’m the founder of EBD Connect unlock the value of Event Driven Architecture for any size of software development organization. Using the right methodologies and tools, Event Based Development can be simplified and more broadly embraced. It is my pleasure to talk to you today about, how following an outcome driven approach and adding the concept of contexts event-modelling can be made even more powerful as it already is.
- Before we go there, it would be good first ask the question, Why we would do this. Why change something that is not broken? Adding stuff is not always good. And as we have all learned, more is not always better! To answer this question, let’s start with a quick overview of what event-modelling is for those unfamiliar with the technique and then dive into the why of extending the model and slight change of modelling approach. Event Modelling is the brainchild of Adam Dymitruk and could be defined as: Modeling, over time, a system’s state changes caused by events. It has its foundations in Domain Driven Design, CQRS and event-storming, but focuses on the tactical design of a system. One of its major benefits, besides being a very simple modeling tool, is the ability to provide predictability to the implementation process.
- Adam’s approach is as follows: Brainstorming where we as many events as possible. Technics like event-storming are perfect for this. In our case we will take a simple example of a hotel room booking. We randomly start writing down events that must have happened during the process of being able to have a room in a hotel. Examples would be: Room booked. But I can’t book a room without also having rooms available. So I must have Added a room in the past (Room added). I’ll would like to have some payment and the room needs to be prepared before the guest can check -in. The next day the guest will probably check-out too. The plot (create a timeline of events). Room Added must have happened before the Room can be booked, so we start swapping events around until we have the right time order. The Storyboard. Adam wants to reflect our tradition of story telling in event-modelling to get all stakeholders on board in identifying what information goes into the system and who are the source of that information. We use the result to be able to do the next steps of gathering inputs and outputs. Conway’s law states that organizations design systems mirror their own communication structure. So we need to make sure we apply organization to our events so we don’t have to break our team structures. The last step is identifying business rules in the form of Given,when,then or Given, Then. They reflect what we would traditionally put as the title of a story. As a user I want to do this because…
- As promised I would get back to one of the key deliverables when working with event-modelling. Predictability Due to the nature of the module, we are able to break it down in slices the constantly repeat the same steps. This allows us to measure time and cost consumed and result in an average slice cost. Our velocity if you want to stay with Agile. However. As usual we keep having one unpredictable element in all of this and it’s of course the Frontend work.
- While I love UX and prototyping, having done it many times myself, by now my opinion has changed about its role and place in the SDLC. In my opinion it is actually preventing us from being customer (outcome) driven and should only be used when preparing to implement a slice of work and most certainly not be part of discovery. Why did I get to this conclusion? What I noticed was, that the original UX work done during storyboarding started to dominate how we imagined the flow of information should be. Stakeholders adjusted to what they saw and no longer came up with their own approaches. Which was often good enough for the happy path, but didn’t help with the more edge case scenarios. Of course there was also the aha moments from other departments. That were not invited or willing to be part of the initial meetings but now they actually did want some input in how the new system was going to work when it was reaching its finish. Can you please at those requirements, shouldn’t be a big change. The real problem why we still have all these failed projects is that we never solved the real problem when building software. The requirements translation and quality gap! While implementing a tool to make event-modelling even more simple I discovered across a possible solution! Outcome Driven Knowledge Modelling
- So lets start with the first part of name of the methodology, outcome driven. To be able to understand this, we first need to have a clear definition of what we mean by outcome. For me the most important aspect of an outcome is the fact that it must change the attitude and thus the behavior of people. This fits nicely with Event driven systems, as the only thing that can influence a person is some sort of a trigger/event.
- Another important reason to let outcomes drive the design of our system, is to make sure we have alignment with the business strategy. If we look at how organisations fullfill their purpose, it starts with a mission statement that gets translated in a vision. The vision gives us some basic direction which the executive team will translate into strategies. These strategies should be define in outcomes and KPI to measure if we have achieved the outcomes. With ODKM we have a natural link between strategy and project, which will make it much easier to talk with our primary stakeholders. There is much more to say about outcomes, but for now it should be clear that if we start with defining the right outcomes we start with a very solid foundation for the project. There are already other methodologies that do the same. An example would be the True North approach as coming from LEAN. Or Right to Left from Agendashift`s Mike Burrows.
- So how does Outcome driven modelling work. It works by going backwards! Starting with the outcome we begin with identifying which events must have taken place to achieve the outcome. Lets take the example that the outcome we want is that a new user will subscribe to a plan after finishing their trial period. What hasn’t been mentioned yet is the concept of the actor. This will be really helpful in identifying if we have all stakeholders involved and if there are any bottlenecks if our process where we can’t identify who has ownership of an event.
- So far we’ve only changed event-modelling to use an Outcome driven approach to discovering events instead of using a more event-storming like approach. But we now have a means to check if we are complete and can actually get all information and required state changes in place. Still no need at all for Story-boarding and other UX activity. UX/UI design is now only needed when we need to know HOW we get information in our events. Not WHAT we need in our events. There are multiple reasons why we would like to know what context events belong to. One is to make certain we stay consistent in our language. We should use the concept of ubiquitous language from DDD so we have clarity around the meaning of event naming. An example could be that we are talking about Account added for finance why it is a customer Added for Customer success. It also points out that we actually needed two events instead of only one. Of course one event can trigger the other, but we should never share the use of events between contexts. What if something changes in one of the contexts. We would have a dependency.
- We start with the outcome Identify the events while adding our inputs We can validate our completeness of the system before the system tactical level Each timeline represents an event-model to implement. However because we have already provided all essential data, we only need to indicate what patterns we want to use and describe our scenarios to complete our event-model designs.
- I hope I managed to get to my desired outcome of the presentation. Although we didn’t have much time I hope I inspired you to reconsider the role of design in the software lifecycle But especially realise that by finding requirements starting from the required outcome and then backwards can solve the requirements communication and quality gab. After this presentation there will be
- Thank you for watching this presentation and I will be happy to answer some questions live after this presentation or send me an email at arjan@ebdconnect.com