Different ways to understand the current state of your system
Hint: Big picture Eventstorming doesn't have to be your Mjölnir
When people talk about Domain-Driven Design(DDD), they associate Eventstorming with DDD. In their minds, if you're not doing eventstorming, you're not doing DDD. That's like wanting to use a hammer to solve every problem. Not every problem is a nail. And let's face it—you and I are not the god of thunder, Thor. If only we had the Mjölnir!
DDD is more than just a set of principles; it's a practical approach that empowers you to delve into the complexities of a domain. By understanding the business rules and problem space, you can design software that's functional and aligned with your business needs. It's about more than just writing code; it's about creating solutions that make a real difference for your business.
There’s more than one way to solve a problem!
When I was in high school, I always loved math and, in particular, Algebra. I don't know about you, but the amount of time I spent memorizing the formula for solving quadratic equations was such that if you wake me up in the middle of the night and ask me the formula today, which is almost thirty years later, I can recite it in a blink of a second. I impressed my high school kid with this scary memory recall when teaching him Quadratics! However, there are multiple ways to solve a quadratic equation; the formula is just one way. If I've now made you curious about quadratic equations and the other different ways of solving them, here's Khan Academy to your rescue. Working in software, we pride ourselves to be very logical beings and yet succumb to strong opinions strongly held. If we remind ourselves that there are more ways and more perspectives to look at a problem more deeply, we might become more curious instead of being dogmatic. In that process, we are then nicer to each other and become better collaborators.
When trying to understand the current system and how it works, There is a system. This system may comprise several services and components or be just one giant monolith with different surface areas. The primary reason the system exists today is that it is still bringing in revenue. And that's because the system is still helpful and serves the users' needs for which it was initially built.
My challenges with the Big Picture Eventstorming
When I joined the NYTimes almost two and a half years ago, I had to quickly understand the domain of subscriptions and newspaper delivery. I had to learn how it works today and the pain points to help identify the pathways to modernizing the system.
Challenge 1: Assembling a large group
Like any DDD enthusiast, I started with Big Picture Eventstorming. My initial hurdle was assembling a diverse group of domain experts, product owners, and other stakeholders for the meeting. Coordinating everyone's schedules, especially in the remote work environment, was a challenge.
Challenge 2: Asking business folks to imagine the system as domain events
The next challenge I immediately encountered was asking everyone to imagine the system as a series of domain events. First, you need to explain what domain events are: significant things to the business, essential happenings that have changed state. Then, you tell them the semantics of it, i.e., you have to name these domain events in the past tense because events are statements of facts that have already happened. Naming things takes work! Remember these famous words?
"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton
Yet we asked everyone to do this within the small time frame of the remote meeting, which proved difficult. The business folks thought this was very techie, and I agree. Instead of speaking in their language, we were dictating the terms of language and communication.
Challenge 3: Cleaning up the duplicate events and the timeline
Then comes the cleaning up of the duplicate events and arranging them in the timeline because the first part of brainstorming all of the events is just that: lots of sticky notes in Figjam or Miro. You can get to this step after a few hours, but I didn't have the luxury of setting up four-hour or all-day workshops.
Challenge 4: No clear understanding what services and components are part of the current state
I made some progress, but I needed to understand how subscribers were getting their paper delivered! I wanted to understand the different components and services that were part of this user journey and how they interact with each other. Big Picture Eventstorming did not help me with that. That may not be the intention of Big Picture Eventstorming, and I may have tried to use it incorrectly.
Exit Big Picture Eventstorming. Enter Service Blueprints!
At this point, I wanted to try a different technique, Value Stream Mapping, which is an excellent way to document business processes but not user experience. This is when my good friend Olivia Cheng asked, why not try Service Blueprints? She pointed me to an article from nngroup.com on Service Blueprints, and I was immediately intrigued. This was a research method that helped in designing service experiences that delighted the user. And I was interested in trying a new way. Little did I know back then how useful it would be.
When designing a system, it's crucial to understand how the user experiences it and what they feel. A Customer Journey Map is a visual tool that can help with this. Similarly, a Service Blueprint provides a holistic view of how all the different parts of the system work together to meet a user's need. By extending this technique to the software design field, we can visualize how all the different architectural elements work together to meet the user's needs, fostering a more user-centric approach to software design.
What’s Next?
Stay tuned. I will continue to write about how I've managed to evolve the Service Blueprints from the design world and hack them into the Software Design world to document current state and gain insights to make the experience better. I have the wholesome approval of my friends in the Design space, who were kind enough to share how I'm using them in their community of practice! If you cannot contain your curiosity and are itching to read about Service Blueprints, my good friend Chris Richardson wrote a few articles on the topic.