When operating on the e-mobility market or considering becoming an eMobility Service Provider, the key is to identify and design the right flow. In this article, as a group of professionals developing such concepts, we want to share a verified methodology. This supports the setup of key components of major importance while developing a secure, stable, and functional eMobility Service Platform. We have already tested these principles and decided to share our insights, hoping some might find them helpful.
eMSP planning
When deciding to operate in a booming e-mobility market, apart from doing extensive research - and taking the first necessary steps toward a feasibility study, it’s worth adopting some good, tested, and proven practices.
One of the efficient methods that prove that the solution will serve is Domain-Driven Design (DDD). It’s the concept, widely used in IT, that helps organize the structure and language of software code matching the business domain. To develop the notable outcomes, there's Event Storming to offer a helping hand.
Note: Individual event names may differ (it's more of a naming issue), but the workflow’s general idea is always followed.
Before the Storm(ing)
When deciding to join the e-mobility market , to generate a widely appreciated service, you need to set in the center the final user’s needs. Keep that in mind while Event Storming. The general idea is to think about each step that needs to happen seamlessly to the subsequent one. And how each must be secured to ensure the entire flow is stable and smooth. Before you start the discovery process, make sure all the participants are familiar with the methodology and necessary tools are provided. This will help develop a final roadmap for a proper eMobility Service Platform and guarantees a smooth flow of the workshop. You’ll need:
- sticky notes in five various colors, it’s up to you which colors to choose
- markers
- a large surface for modeling (e.g., A large sheet of paper taped to the wall works well)
- step-by-step view of the process on an extra board for a clear overview of the Event Storming process
- a lead person (facilitator) who will keep the entire process running smoothly
- a group of people representing various domains, e.g., business, IT, marketing
The workshop can also be attended remotely. When the conditions do not allow participants to gather together in one place, the workshop can be conducted by distance. You can use a tool like miro in the digital variant - an online visual collaboration platform for teamwork that will solve the markers, post-its, and surface puzzle. The digital approach can also be seen as more environmentally friendly since we can create and edit each piece online without wasting paper. After all, the Event Storming outcomes must be digitalized, so the digital tool may be a good idea. Whichever variant you choose, each approach - remote or stationary - will be efficient.
Now briefly, let's clarify the roles of individual components.
Notes
Each color represents a different area. This is why diverse colors will help visually and logically picture particular subject areas. ‘True’ Event Storming purism dictates the colors for you, here we suggest the following:
Orange color - is used at the first step to define each event that should happen on the path to accomplishing the operation. Note: Events should always be described in the past tense, e.g., Invoice was generated, Charging has stopped.
Yellow color - used at the second stage of the storming to define ‘actors’ - people involved in an event or process. The goal is to recognize if external involvement is needed, e.g., Portal user, Support team member.
Purple color - being used at the third stage of storming, representing the system, external or internal, involved in the process. The objective is to highlight external involvement. e.g., Third-party API, Billing system.
Red color - represents the next step taken in the process - defining hot spots - indicating the lack of precise knowledge, doubts, or bullet points - a spot of disagreement between participants. The objective is to mark areas that need deeper insight, e.g., automatic price calculation, events order.
Green color - identifying opportunities - to specify areas where something works well and could be improved or space for fast growth. It can be a good support for the hotspot cards (red color), demonstrating a problem-solving approach, e.g., applying open standards for e-roaming
Participants
The lead person (a facilitator) guides participants through the process, keeps everything in order, and groups into aggregates.
The storming group - representatives of various areas: business, development, and marketing. The more diverse the group is, the outcome might be richer. Note: it’s not about the quantity, but rather the quality. And by quality, we mean the representation of different areas of business. The good idea is to make sure the most influential and knowledgeable people on the studied topic are invited. They are supposed to have some domain expertise (but seen from various perspectives). In this particular case, the idea is to meet IT requirements with business-related goals to provide an efficient, stable eMobility Service Platform.
Timing
Brainstorming: should take about 10-20% of the time, it is suggested to give participants ca. 15 minutes for individual work. Break: 5-10 minutes.
Verifying the ideas and backward walkthrough: about 60-80% of the time. You can make a short break about 5-10 min. between verifying ideas and backtracking events. Identifying Hotspots, commands, and actors: max 5-10% of the time.
Depending on the project’s size, in this particular case, working on eMobility Service Platform Functional Requirements, the Event Storming should take +/- one hour.
The Storm(ing)
The actual storming phase starts when all needed components are set. The Lead (facilitator) should do a brief introduction to ensure all participants understand the following steps and outcomes. When it comes to brainstorming the eMSP, our outcome will be a service platform offering easy and secure access to the charging infrastructure. This is why the information board should be provided and handily arranged for the group.
Step one: Brainstorming
In this phase, each participant defines events - all the steps that sequentially have to happen to complete the action. In our case, it will be to describe the user’s path to use a service - to charge an EV successfully.
Note: Participants should be familiar with the user’s profile - an EV owner who needs to charge the vehicle smoothly.
The Brainstorming starts with a brief individual defining. This should be a round of 15 min. Separately, all partakers are intended to distinguish the required steps. The aim here is not to specify each step, rather gather all interactions necessary for the flow.
Step two: Verifying the ideas
After Brainstorming, the Lead (facilitator) asks each participant to present individual outcomes. This is the part when the group forms together with the roadmap. Identified steps can (and should) come up repeatedly. That’s ok. It shows common parts recognized individually. It also indicates that the group was selected properly and is familiar with the general idea of the flow that needs to be shaped. At this stage, because our team is diverse, each described actions may vary, depending on what area is represented. That’s perfectly fine.
Having formed the initial roadmap, the facilitator takes charge. With the storming group, the duty is to do the actual verification. A vital part of event storming, when developing an idea, is to begin from the end and backtrack event by event to check if no significant action was overlooked. The general scheme for backtracking is asking such questions:
What has happened before X?
Is X a consequence of Y?
Is there something more happening between X and Y?
Post-its in yellow, purple, red, and green color will be needed for the following steps.
Step three: identifying red spots, defining commands and actors
By analyzing and stepping back, the Lead (facilitator) with the group ask repetitive questions, like ‘are we sure this is all we need to complete the action?’, ‘is this step secured?’, ‘how will it be secured?’, ‘are there any other options available?’, ‘how do we want to handle the billing - externally or internally?’. The objective is to identify three areas:
- Hotspots (here we suggest using red post-its - from a psychological point of view, red color is one of the most visible colors in the spectrum, has the ability to grab people’s attention instantly, hence is often used to warn of impending danger. For a good reason, the term ‘red flag’ is used to indicate warning signs)
When developing an idea, it’s good to indicate areas for improvement strongly. In our case, enhancing the emerging platform, to know what might be concerning. The sooner such areas are mapped out, the more time and resources will be saved when developing the project. If we identify a considerable number of such spots, it may also be a signal to consider engaging external agencies with specific domain expertise. - Commands & actors will need 2 extra post-it colors to mark commands like ‘execute payment,’ ‘issue invoice’, and actors, simply defining if the external or internal system is responsible for the command execution. This step helps decision making and provides extra insight into our roadmap. At this stage, we consider which parts of the process will be executed by our system and which will be on the side of e.g. CPO or payment system.
- Having defined all requirements, the last step is to identify which area might be the biggest issue (causing the most problematic - interfere with the smooth flow of the overall manner, e.g., calculating the price, storing the CDR, executing the critical step when the process failed ‘no-show payment.’ At this point, again, each participant defines the area which they feel is a contentious one).
Note: Additionally, while identifying hotspots, commands, and actors, opportunities might be spotted. When we acknowledge we have the know-how or already witnessed similar issues and solved them, we can point out these opportunities, e.g., Areas where we can apply automation, or use a well-working, already tested solution (taking this step, you’ll need an extra post-it color).
After the Storm(ing)
When the Event Storming is done, it’s time to digitize the outcome. A well-conducted storming session should result in a roadmap, providing a sharp picture of what we want to achieve, obstacles we may encounter, and areas where we can recognize some opportunities.
Note: a key to reach any complete roadmap is to define at the beginning a clear goal. People tend to lose track when the scope is not specified enough. This helps to avoid the occurrence of insignificant events. This also explains why Event Storming needs a good Lead (facilitator). Keeping an eye on the storming’s smooth flow, focusing on a language, asking specific questions, detecting significant details and unclear aspects (e.g., marking hotspots), forming the main path and sidetracks.
What is after eMSP planning?
The event is done, participants are tired but also satisfied after being creative, collaborative, and effective. After the storming, the domain architect steps in to discover and validate the subdomains.
Determining emerging subdomains cannot be omitted. There are dozens of heuristics and techniques for developing, and none of them are universal. Here are a few worth mentioning: company structure, domain expert division, domain expert language, business value, business process steps.
Detecting undetected
Event storming shapes our process, clarifying each step that must be taken to complete the session. As mentioned initially, on top of our service is the final user - an EV driver. Having the storming session done, subdomains defined, and the Big Picture, we can move more confidently to the next steps of the eMSP platform development. Successful execution of such a Storming Event will allow you to build a feasible timeline, identify areas that may be challenging, and help better estimate the financial outlay. In consequence - design and develop the eMobility Service Platform and drive interoperability.
Note: when having doubts about whether you will be able to carry out such workshops on your own, you can ask for guidance from an agency focusing on designing and conducting such events or a partner specializing in software development and domain support.
Psst! On the right, you can spot a box - drop your e-mail to check and verify a key eMSP Platform Functional Requirements.