In the previous post, I explained how to draw the boundaries of functional areas. Not all functional areas are equal though. Some have tremendous value for you, whereas others just need to exist. Pareto’s Principle, also known as 80/20 rule goes like that:
Roughly 80% of the effects come from 20% of the causes. Wikipedia
The same goes with functional areas. A small part of your code base will generate much of its value. Event Storming and DDD (Domain Driven Design) can help us to identify where to focus, and what software to buy or build.
This is the 10th post in a series about how to use Event Storming to kick start architecture on good tracks. It might be a good idea to start reading from the beginning.
Core Functional Areas
Strategic DDD distinguishes 3 types of functional areas. Categorizing a functional area is key to answering “Buy or Build Software” question.
Core areas are your most important assets. These are the functional areas that make your competitive advantage. They are so specific and important to your business that you must build these yourself. You should strive to focus as much as you can on them. Focus goes through doing as little as possible of the rest…
These are functional areas that have no specificities with your business. They are reusable across many industries. It’s not a good time investment to build your own version. You should rather re-use or buy an existing third party to provide this in your system.
Supportive areas are the rest. Too specific to buy, but not differentiating enough to build serious competitive advantage. Here are typical supportive functional areas:
- Custom libraries reused across many core domains. Technical in-house frameworks are a good example.
- Features that are so basic in your industry that everyone takes them for granted. Configuration or administration often fall here.
You cannot reuse existing code for your supportive areas. You don’t want to focus on them either! Here some strategies experts recommend about supportive areas:
- outsource them
- leave them to less experienced programmers
- or apply looser quality rules in this code
Here is a post by Jonathan Olivier if you want to learn more about these 3 kinds of functional areas.
How to classify your functional areas
This activity goes after all the DDD Event Storming steps I presented in the previous posts. The design board should now look something like that:
Here is how to do this in group during the workshop.
- Give a quick introduction to the 3 kinds of areas. It’s rather simple, and people usually get this quick.
- Draw a few hearts ❤️, 🅖 and 🅢 post-its.
- Pick one area, and ask how they would classify it. Discussion and, hopefully, agreement should follow. If you cannot reach a consensus, use a pink problem post-it and continue. You might also have a look at Nick Chamberlain’s technique of using both complexity and competitive advantage.
- Hand the rest of the post-its to the audience, and ask them to classify the other areas
- It should not be very long for them to have classified all the contexts
- The core should be as small as possible. So let’s try to highlight the core even further. For identified core areas, ask the audience if they could extract non-core parts out. If yes, draw new supportive or generic functional areas.
- Ask them if there is anything that they would like to comment
This small and simple activity can have paramount consequences. Especially for big topics like prioritization or buy vs build software decisions.
Here is an illustration. I gave this workshop to a team in Dublin a few month ago. They later told me they had unscheduled a large refactoring that was not tackling their core. By itself, this kind of decision pays back the whole workshop many times.
Another team I’ve worked with decided to replace a feature they had built in-house with a 3rd party. They had discovered it was ‘Generic’. This would allow them to re-focus on other core areas of their system.
💡 Use Event Storming and DDD to identify generic parts of your system. Then save time and maintenance by replacing them with third parties.
A less tangible outcome is that it focuses discussions and efforts on core areas. At the end, there will be less work on non-core areas, and more on core areas. Work on core areas is also more valuable. All in all, it means less but more valuable work. This means a more profitable and sustainable pace.
The more we dive in Event Storming, and the more actionable the outcomes get!
To be continued
In the next post, I’ll go over decision power between functional areas. Now that we know our core areas, we want to make sure they have this power!
This was the 10th post in a series about how to use Event Storming to kick start architecture on good tracks.