In MoSy, technical components are self-contained parts of the system that can be independently deployed, updated, and managed. They are also known as deployable units.
The Core Diagram provides a simplified view of these components, focusing on business logic and execution units rather than the whole infrastructure stack. Unlike traditional architecture diagrams that include databases, message buses, or cloud infrastructure, MoSy emphasizes the functional compartmentalization of system behavior across the deployable units. This approach keeps the diagram clear and straightforward and aligns the business perspective with the technical design.
The width of each component aligns with functions and entities in other swimlanes, reinforcing the connection between business logic, data management, and execution units. This visualization helps people quickly understand which components implement the different functions, system entities, and metrics.
MoSy’s Flow Diagram, including Technical Components
Components interact through interfaces (APIs in the technical plane). In MoSy, interfaces are depicted with arrows that connect the different blocks from the initiator function (start) to the receiver function (end). You can use circular markers to align the arrows’ positions and functions. To provide additional insight into these interfaces, you can use solid lines for synchronous-type interactions (e.g., commands or data requests) and dashed lines for asynchronous interfaces (e.g., events or messages).
As with system entities, technical representatives must lead the creation of the elements in this swimlane. When illustrating an existing system, they know precisely what component implements which function and encapsulates which data. For new systems, technical people can use the valuable context provided by the other swimlanes to draw the boundaries of the envisioned technical components.
The Technical MVP Approach
The team must apply the same principle recommended for designing only the essential flows to the system’s technical design. When defining technical components in a system, it is crucial to avoid overcomplicating the architecture too soon. A common mistake in system design is prematurely splitting a system into too many components (e.g., microservices), creating unnecessary complexity before the business and technical needs justify it.
Take the e-commerce platform as an example. Instead of immediately creating separate microservices for Cart, Orders, Payments, Inventory, Shipping, and Customer Management, teams can start with a single deployable unit that handles essential workflows—adding products to a cart, processing orders, and managing payments. This allows for faster development, simpler debugging, and fewer integration issues. As the platform grows and specific parts require independent scaling or flexibility, components like Payments or Shipping can be gradually extracted into separate services. By starting simple and iterating, teams maintain agility and avoid the burden of managing unnecessary complexity too early. This approach shouldn’t be extended for too long, though. As the business matures and the organization grows, it’s essential to foster more efficient parallel work, which typically involves splitting the system into domains and, consequently, independent components that teams can develop and maintain separately. Large code monoliths are extremely difficult to maintain and evolve, so refactoring should be adopted as a regular practice. In MoSy, you can ensure a healthy technical evolution aligned with the business direction as the system progresses by incorporating non-functional requirements that can track well-established key indicators in the industry, e.g., DORA metrics – Deployment Frequency (DF), Mean Lead Time for Changes, Mean Time to Recovery, Change Failure Rate, and Reliability.