MoSy sits between the problem and solution spaces. Therefore, it fills the gap between defining the customer’s needs (the problem) and the technical architecture and implementation of a system (the solution). Most of the tools available focus on one or the other, but few connect both worlds. That doesn’t mean that MoSy can replace those tools, but you can combine them with them and use its visuals as the bridge between business, product, and technical aspects. Let’s have a look at some popular frameworks and tools and see how you can leverage them together with MoSy:
-
Business Model Canvas. A very popular tool to visualize your business plan using a single piece of paper where you plot customer segments, value propositions, revenue streams, key partners, channels, etc. It focuses on the problem and what you plan to do instead of the details of how you plan to do it. That’s a perfect approach to start with. MoSy combines perfectly with this tool since it’s a natural continuation: now that you know what to do, you can use the framework to design a system that materializes your plans and ensures that it’s perfectly connected to them.
-
Customer and UX Journey maps. They visually represent a customer’s experience with a product, service, or brand across different touchpoints. The main objective of a Customer Journey Map is to understand and improve the customer experience by identifying pain points, needs, and opportunities at each stage of their interaction with a business. You can use these mappings as input to model the action flows in MoSy, using the rest of the swimlanes to show how those relate to metrics, system entities, and technical components.
-
Behavior-Driven Development (BDD). A software development methodology that enhances collaboration between developers, testers, and business stakeholders. It extends Test-Driven Development (TDD) by using natural language descriptions of system behavior, making requirements more understandable for all team members. The primary objective of BDD is to bridge the communication gap between technical and non-technical stakeholders by defining software behavior in a clear, structured, and executable way. BDD also sits between the problem and the solution, and it’s a powerful glue between them. Still, it lacks visuals and a global directory of user behaviors, and it’s commonly devalued when technical processes are added to the scripts. You can use MoSy flows as inputs to create the BDD scripts and connect the whole stack by ensuring that the code implements the envisioned flows.
-
C4 model. The C4 Model is a visual framework for software architecture modeling. It provides a hierarchical way to describe software systems at different levels of abstraction, making it easier to communicate architecture to various stakeholders. The name C4 comes from its four diagram types: Context Diagram – shows the system in relation to users and external systems; Container Diagram – breaks down the system into deployable components (e.g., applications, databases); Component Diagram – details internal components of a container and their interactions; and Code Diagram (Optional) – provides a class-level view for further technical details. The C4 Model is the best approach to visualize software architecture. It’s simple, flexible, and effective. This model is not intended to map business requirements; it focuses on the technical solution. It can be perfectly combined with MoSy. First, you can map the High-Level System View(s) with the Context Diagram to depict how the technical architecture of your system supports the operational flows. Then, you can construct a single container diagram for all the flows or one for each. That gives you the classic static view of your architecture, which is easier for technical people to read and understand than the horizontal representation in MoSy’s technical components’ swimlane.