An architect’s journal -Embracing Simplicity in Software Architecture Diagramming
Diagramming is a fundamental communication mechanism among software architects and other system design and development stakeholders. It’s a visual language that conveys complex ideas in a digestible format, enhancing comprehension and promoting effective collaboration. However, the power of diagramming lies in its simplicity.
“Simplicity is the ultimate sophistication.” — Leonardo da Vinci
An excellent architectural diagram should be straightforward enough for anyone to understand, even someone new to the organization or the particular system being represented. It should serve as a bridge, connecting diverse audiences and facilitating a shared understanding of the system’s architecture. By refining and simplifying our diagrams, we can ensure they are approachable and comprehensible, ultimately enhancing communication and promoting successful architectural outcomes.
In my previous post, I emphasized the importance of simplicity as a critical skill every architect must develop. Simplicity, in our context, facilitates understanding of the proposed architecture and aids architects in maintaining authenticity and clarity in their work. Today, I want to delve into a methodology that embodies simplicity and allows us to gradually build an architecture from level 0 (L0) to level n(Ln).
“The ability to simplify means to eliminate the unnecessary so that the necessary may speak.” — Hans Hofmann
My journey toward this methodology was catalyzed by a challenge I encountered early in my career. Following the .com crash, I was at a midsize software company tasked with untangling the knot of development complexity and delineating a clean architecture for the application stack they were building. The pre-existing architectural specifications were perplexing, and the reasoning behind certain design decisions was unclear. This experience compelled me to refine how we present and document software architecture.
It’s essential to note that the L0 to Ln approach can be applied to each architecture category, whether it’s business architecture, application architecture, information architecture, or technical architecture. Every architecture category has its intricacies, and using the L0 to Ln approach allows us to progressively detail each one precisely and clearly. A common misconception is that business architecture corresponds to L0, solution architecture to L1, and deployment architecture to L2. This interpretation is incorrect. Each architecture category should be viewed as a unique entity with its own levels from L0 to Ln rather than a sequential distribution of levels across different categories of architecture. We must remember to maintain the flexibility and granularity of each category within its unique context, allowing for a practical architectural approach that embraces the complexity and distinctiveness of each system.
The cornerstone of my approach draws parallels to how we learn in elementary school — gradually progressing through levels. First, I would divide a complex system into smaller, manageable parts and employ a top-down approach to the problem description. Next, my path involved structuring the system across several layers — hardware, organization, system, virtual application, domain, sub-domain, and components. Then, I would expound on the architecture using a series of levels, from level-0 to level-n, with the number of levels varying based on the system’s complexity.
You may wonder about the diagramming notation I employed. To be honest, it didn’t matter. Whether UML, C4, or data flow notations, the choice depended on preference. While I’m not partial to UML or C4, I appreciate diagram simplicity. Therefore, I opted for block notations with simple shapes, valuing consistency above all else. As a result, I created and adhered to a notation library and a color palette. I spoke about the diagramming tools I use in a previous post.
Given our vast, intricate problem space, offering a one-size-fits-all approach is challenging. So, let’s explore this methodology using a hypothetical scenario: an enterprise is re-architecting its systems as part of an ERP modernization. The organization aims to become digitally driven and embarks on its digital transformation journey. They already have several systems of record layers in place, which need to be reused while also seeking to optimize internal processes through automation and new applications.
You’re the lead architect spearheading the architecture — so let’s get down to business.
Level 0 (L0)
Level 0 (L0) marks our starting point. This is the most abstract view of the target architecture. At this stage, a single shape might represent the entire system. It serves as an initial snapshot, an abstract encapsulation of the system we aim to build.
With Level 0 serving as our foundation, we will gradually progress to the following levels.
Level 1 (L1)
Level 2 (L2)
Level 3 (L3)
In Level 3 (L3), we utilize the principles of cell-based architecture to clearly define and encapsulate distinct domains and their corresponding (micro)services, enabling efficient and scalable system design.
Just as described, you can continue this incremental detailing process all the way up to Level n (Ln), depending on the complexity of the system and the level of detail you wish to delve into. This flexibility allows you to effectively address and manage even the most intricate architectural scenarios.
In conclusion, the L0 to Ln approach is a potent methodology for any architect, enabling systematic and clear delineation of intricate systems. Our diagrams, acting as a universal language, should embody simplicity and clarity to facilitate understanding among various stakeholders, including those new to the system or organization. This approach, applicable across architectural categories such as business, application, information, or technical architecture, promotes precision and detail in each unique context.
“In architecture, simplicity is an imperative. It’s about communicating complexity understandably. Our diagrams are our architectural language — let’s ensure they speak clearly from Level 0 to Level n.”
This discussion has hopefully illuminated the importance of simplicity in our architectural representations. As we venture further into the world of architecture, keep in mind that our primary mission is not solely to design systems but to effectively communicate these designs. Regardless of the complexity of the system, our challenge lies in maintaining simplicity in understanding. Continue to tune in as we explore further into the nuances of software architecture, and remember: clear, effective communication is the key to successful architecture.
