⚡ Tl;dr

Event Storming

• Event Storming is a cost-effective, lightweight technique for tackling complex business processes
• It facilitates collaboration between domain experts and development teams
• A miro whiteboard is used during discussions
• Helps gain a deeper understanding of the business, dependencies, actors, systems, and features
• Collaboration can uncover unexpected aspects and provide valuable insights
• Event storming will help to make better decision by understating bussiness goals, organization and business environment.

Architecture Modelling

• The architecture model is a view that is a single source of truth about the current architecture state (Deployment units, external systems, components, connections, infrastructure)
• After understanding the business context, analyze the architecture model(AS IS)
• Analyze coupling and cohesion and prepare the TO-BE design
• Use Ice Panel or other modeling tools like PlantUML or Structurizr
• A visual model helps in making better architectural decisions.

Architecture Decision Log

• Maintain an Architecture Decision Log (ADL) to record significant architectural decisions
• Use as a reference for future decision-making processes and assess previous trade-offs
• Evaluate trade-offs and document findings in a clear and concise manner
• Store ADRs as Markdown files in a repository, closely linked to the code
• Review ADRs as a production item through a pull request process.

Analyze system quality attributes

• Software architecture quality attributes are non-functional properties that determine overall quality and suitability for use
• Use a table to analyze impact of architecture decisions on quality attributes
• Helps to have a clear and concise summary of each decision’s impact on quality
• This analysis can be included in the Architecture Decision Record (ADR).

Team-Based Architecture Evaluation and Decision Making

• Strong collaboration with the team is key to the success of each technique
• Use tools that facilitate collaboration to maximize the value of the process
• Have team members challenge decisions to stimulate new thinking
• Final decisions should be made by the team as a whole.

As the saying goes ?

Architecture is made up of significant decisions.

Making the right decisions, especially with limited knowledge, is a challenging aspect of being a software engineer or architect. However, this challenge can be overcome through collaboration and the use of effective decision-making techniques.

In my experience, I have found that utilizing the following 5 techniques has helped me make better architectural decisions. By using these techniques, I am able to enhance my decision-making abilities and create a more flexible and business-aligned architecture.

1. Event Storming

Event Storming is a cost-effective and lightweight technique that facilitates collaboration between domain experts and the development team. It is designed to tackle complex business processes.

I use Event Storming in conjunction with a miro whiteboard to discuss the context of a feature with the business. This helps me gain a deeper understanding of the business, including dependencies, actors, systems and features, and arrive at a shared understanding through the use of sticky notes.

The use of ubiquitous language in Event Storming also helps me to better understand the domain and boundaries as well as clarify non-functional requirements through discussion. Collaboration with the business and development team can often uncover unexpected aspects and provide valuable insights.

In conclusion, Event Storming is an effective technique for architects that don’t come with a high cost. It provides a way to gain a deeper understanding of the business and make more informed decisions. You don’t have to use the Event Storming process by the book you can use the lighter version to adjust the technique to your workstyle and needs.

2. Architecture Modelling

Once I have a clear understanding of the business goals and context, I analyze the architecture model (current state of the system (AS IS)). The next step is to design a solution (TO BE). From event storming business design we move to technical aspects. I prefer using the C4 abstraction for modeling as it allows me to visualize the external systems, deployment units, infrastructure, and components and plan my next actions.

With the C4 model, I can see the components and design new ones. If I have a single model of the system, I can analyze the coupling and cohesion and prepare the TO-BE design. I can see how things will be connected.

I use Ice Panel as my modeling tool, but you can also use other tools like PlantUML or Structurizr. Maintaining C4 Architecture model generates additional effort for the team but usually is worth it. Having a visual model like this significantly helps in making better architectural decisions.

One of the things I love about the ice panel is its ability to visually demonstrate the diagram flow of requests as they pass through multiple components and queue neatly. This makes it easier for me to present my ideas to both the development team and business stakeholders. Feel free to have a look at my example to try for yourself.

3. Architecture Decision Log

I maintain an Architecture Decision Log to record all significant architectural decisions made, along with their context, advantages, and consequences. This log serves as a reference for future decision-making processes and helps me assess previous trade-offs and determine their impact on new decisions.

When I am in the decision-making process, I create an Architecture Decision Record (ADR) to outline the proposed state. This requires me to evaluate trade-offs, gather all benefits and disadvantages, and document my findings in a clear and concise manner. By doing so, I ensure that all team members have a clear understanding of the reasoning behind each decision and its potential consequences.

I keep a record of my decisions by creating Markdown files and storing them in a repository, ensuring that the Architecture Decision Log (ADL) is closely linked to the code. When a significant change proposal arises, I initiate a pull request that includes the corresponding document and reviews it as a production item. This process allows for the possibility of ADRs being rejected.”

Examples of Architecture Decision Log:
https://github.com/kamilbaczek/Estimation-Tool/tree/develop/Documentation/Architecture/Decisions
https://github.com/Sylius/Sylius/tree/1.13/adr

4. Analyze system quality attributes

Software architecture quality attributes are the non-functional properties or aspects of a software system that determine its overall quality and suitability for use. Some common quality attributes include:

1. Availability: The degree to which the system is operational and accessible when required.
2. Scalability: The ability of the system to handle increasing workloads.
3. Performance: The speed and efficiency with which the system operates.
4. Security: The degree to which the system is protected from unauthorized access or attack.
5. Maintainability: The ease with which the system can be modified or updated.
6. Usability: The ease of use and user-friendliness of the system.
7. Testability: The ease with which the system can be tested.
8. Flexibility: The ability of the system to adapt to changing requirements and environments.
9. Portability: The ability of the system to run on different hardware and software platforms.
10. Reliability: The ability of the system to function correctly and consistently over time.

I find it useful to use a table to analyze the impact of my architecture decisions on software quality attributes. This helps me to overview my design decisions by having a clear and concise summary of the impacts of each decision on quality. Such kinda analyze can be put into ADR.

5. Team-Based Architecture Evaluation and Decision Making

Strong collaboration with the team is key to ensuring the success of each technique presented in this post. I emphasize the importance of using tools that facilitate collaboration, as this will maximize the value of the process.

During event storming, it is crucial to encourage the team to ask questions and thoroughly examine the context of the project. I suggest proposing architecture decision records (ADRs) and obtaining feedback through comments or merge requests in the associated document. Providing the architecture model for review and presenting a trade-off analysis to the team will allow for a thorough examination at each stage.

It’s important to have team members challenge decisions as this will stimulate new and potentially undiscovered thinking. The final decisions should be made by the team as a whole, not just by individual team members.

Ending

As an architect, I have my own set of tools that I have found to be effective in my work. In this post, I have shared a list of these tools which are commonly used but not necessarily known or used by all architects. The choice of tools should be adjusted to the specific needs and requirements of each project and team. I typically use all of these techniques, but it is not a rule. I find them easy to implement and useful in the development process. In the future, I may also include another technique called “Context Mapping” that I am currently learning about.

Thank you for reading

References

• https://icepanel.io/blog/2022-09-21-modelling-vs-diagramming-software-architecture

Follow me

If you’re looking for ways to improve your software development skills and stay up to date with the latest trends and best practices, be sure to follow me on dev.to!? I regularly share valuable insights and tips on software development, as well as updates on my latest projects.

Speaking of projects, I’d like to invite you to check out my modular monolith project on GitHub, called Estimation Tool. It’s a great example of how you can use modularization to build a more scalable and maintainable system. The project is open-source and well-documented, so you can learn by example and see how I applied the concepts of modularization in practice.

https://github.com/kamilbaczek/Estimation-Tool 

So if you’re looking to level up your development skills, be sure to follow me on dev.to and check out my modular monolith project on GitHub. Happy coding!?