Before I'll dive into more posts that explain how I design capabilities for my offline progressive web apps, I'd like to take a moment to explain how I analyze the business processes that are supported by those apps.
To analyse existing business processes, I'm using a technique called Event Modeling.
Event Modeling is a term coined by Adam Dymitruk, but the technique itself builds on the work of others such as Eric Evans (DDD), Martin Fowler (Eventsourcing), Greg Young (CQRS) and Alberto Brandolini (Event Storming).
This modeling technique focusses heavily on identifying meaningful business events happening in a business process.
Once these events are identified, they form the basis for a design process that results in a set of processing patterns described in the DDD, CQRS and ES work out there.
Collectively, the implementations of these patterns can digitally support the analyzed business process.
Event Storming can be brought into the mix if you want to run the modeling effort as a workshop, but it can also be done on your own.
The Event Modeling Process
The following 7 steps need to be taken to follow the event modeling process:
- Identify events
- Create a timeline
- Identify user input and commands
- Identify information required by the user
- Group events into autonomous components
- Identify message processing patterns
Step 1: Identify events
As a first step I'll identify businesswise meaningful events which are ocurring during the execution of an existing business process.
As an example, I'll use a shortened version of the fundraising dinner ordering process used by our sports club.
It consists of following events:
I'll note them down on orange post-it notes and put them on a design surface.
'Businesswise meaningful' means that the events are the result of a state change which moves the business process forward. So
SalesOrderBooked is considered meaningful, where
SalesOrderValidated may not be, as it does not move the process further.
Usually it will be straightforward to identify the most important events in the process, but it will take some time and thought to identify which are meaningul, and which ones are just supporting.
That's ok though, as I work iteratively on capabilities anyway I can add, modify and remove events during future iterations when new insights are gained.
Step 2: Create a timeline
Next I organize the identified events in chronological order, so that they form a cohesive story together.
While doing so I will probably find events missing that should be added to the timeline.
I may even discover so many missing events that they can be split out into a new business process on their own.
Likewise I might discover that some of the previously identified events actually belong to a different process, or to a different variant of the process under analysis.
In any of these cases I set those events aside, and tackle them on another day. I'll focus on one story at a time.
For other stories, just repeat the process.
Step 3: Storyboarding
Now that the events are defined and in the right order, I will start thinking about what the user experience could look like for the different people taking part in the process.
When there are multiple actors in the story, I use a swimlane for each type of person taking part.
In this example there is a
Funder ordering food, a
Fundraising Manager to follow up the orders and deal with logistics and there is the
Checkin clerck that will validate the order, process and deliver it at the day of the fundraiser.
For each of these roles I will draw wireframes or mockups to visualize how the actors participate in the process.
I'll have to decide what kind of visual would convey the information in the best way: a list, a calendar, navigational search, or something else?
If a form is required for the user to enter information, I'll need to decide what buttons need to be pressed, what fields should be on the form for data collection, etc...
Step 4: Identify user input and commands
Each input form, or button, in the mockups should lead to one or more commands that will be sent to the system for processing.
I'll add a command to the drawing, typically as a blue post-it note, in between the input form and the event that will result from processing the command.
For example, when a
Funder wants to make a booking for a fundraising sale, she can issue a
Book command from the clubs website, which will result in a
SalesOrderBooked event inside the system.
I'll also take some time to define the information that should be present on the command for the system to be able to execute on it. Typically I'll record this as a comment connected to the post-it note.
- OrderId: generated - Buyer - Name: form field - Email: form field - OrderLines - Id: generated - Quantity: form field - OrderedItem - Id: ? - Name: ? - Price: ?
This way I can verify that all information needed by the user is present on the mockups, either as data entry fields or present in the visual information.
If certain information is missing, this may be a good indicator that I'm missing another business process to define it.
Step 5: Identify information required by the user
The user will require information on her screen in order to make informed decissions and invoke the right commands.
Humans however are not great at digestion a large stream of events into something meaningful. Therefore the system needs to create summaries of the information contained in these events.
In my taxonomy these summaries are called state, which are represented by green post-it notes. Sometimes action is required to get the state to the user, e.g. by sending them an email. In that case I'll use pink post-it notes.
As an example, when a
Fundraising Manager wants to grant a discount on an order, the system will have to provide her a list of
Orders to select from. This is the kind of information that needs to be identified in this step.
I'll add all required state to the drawing and also define what the shape of the objects looks like and what information needs to be present. If the state is simple, I'll just add it as a comment connected to the post-it, otherwise I might draw a small UML diagram on the side.
Then I'll connect the state to the events that hold the information in order to populate it.
Step 6: Group events into autonomous components
Once I have a good view of how data flows between the different human participants in the process, I'll have to decide how data will flow inside the system itself.
Defining the components can be done by grouping the events into swimlanes, in such a way that each swimlane has a maximum of autonomy and each one can be owned by a separate team.
The following steps are autonomous, they are executed at different times, in different locations and by different people:
OrderBooking: This step is performed upfront, on paper or via the clubs website. All info needs to end up at the fundraising manager to plan the fundraiser.
Payment: Money is handled separatly by the treasurer, accepting the money either in cash, by wiretransfer or via online transaction.
OrderProcessing: This step is only performed on the day of the fundraiser by a team of volunteers.
Avoid grouping by noun (a very common mistake), make sure to group by autonomy and have as little dependencies between the components as possible.
Also ensure not to violate conways law, take your organizational structure into account so that each autonomous component can also be supported autonomously inside the organization.
Step 7: Identify message processing patterns
From the resulting eventmodel I can now identify the message processing patterns that exist in the message flow. For each of these patterns there is a standardized way to implement them in the clubmanagement system.
There are several processing patterns to transition between commands, events and state in any direction, of which I've shown a few on the diagram above.
Aggregate Root: Makes a business decision in response to a command and records it as an event.
Event Stream Processing: Converts a stream of events into other events.
Downstream Activity: Invokes an action based on a command or event.
Projection: Turns a stream of events into state.
In total there are 9 patterns to support the transition between command, event and state.
By implementing this limited set of patterns, you can support the majority, if not all, business processes in existance.
I'll come back to these patterns in future posts.