The High-Level System View might be simple to model in small organizations but challenging for bigger businesses. Big organizations usually have more than one business offering and, therefore, different business models.
A good example of this approach is Amazon, which operates multiple independent business units, each with its own system. Amazon’s e-commerce business is fundamentally different from Amazon Web Services (AWS), despite both being part of the same corporation. Even within the e-commerce side, Amazon provides different solutions tailored for specific types of sellers, such as Amazon Marketplace for small retailers, Kindle Direct Publishing for book authors, and Amazon Business for corporate buyers. Each of these operates as a separate system, aligning with its unique business model, customer base, and operational requirements.
Organizations with multiple business plans should structure MoSy diagrams into distinct systems, ensuring each serves a specific purpose without unnecessary overlap. A single MoSy high-level system view should align with one business strategy, one set of key objectives, and a clearly defined set of actors and flows. This separation avoids overcomplicating the system model and maintains clarity of purpose.
Splitting a system into multiple views allows organizations to:
- Keep each system focused on its business goals without cross-dependencies complicating decision-making.
- Maintain clear ownership and accountability across different business units or product teams.
- Reduce unnecessary complexity by ensuring that only relevant actors and key objectives are modeled within each system.
Organizations may offer different business cases that share commonalities or overlap regarding Actors and Flows. Some typical flows naturally enter into these categories: invoicing, customer management, etc. Those with a technical background might think these map to dedicated components and APIs that can be reused across business cases and, therefore, they should be part of the same system view. Do not jump so fast into these technical optimizations that try to influence high-level visualizations. In this design phase, it’s much better to duplicate flows across business cases and only jump into optimized solutions when looking into the technical planes of the different systems together.