> [!tldr] Communication, simulation, & exploration. > [!note] Rethinking for a 3rd pillar > I realized I was doing some modeling to *learn* a subject & that didn't fit my original paradigm. After waffling between "education" and "exploration" I went with exploration because it doesn't imply "teaching others", which is just communication. Modeling really only serves ~~two~~ three basic purposes: **communication** and **simulation** *and exploration* Don’t confuse one for the other. Only those for simulation require stringent adherence to the rules of the language, and most are for communication. > [!tldr] TL;DR > If modeling for… > - simulation → adhere to the rules > - communication → keep it simple > - exploration → set your own rules Put another way: | Purpose | Audience | Best practice | | ------------- | ------------ | ------------------- | | Communication | Other people | Keep it simple | | Exploration | Yourself | Set your own rules | | Simulation | Computers | Adhere to the rules | I think [[Systems Modeling Exists on a Spectrum]]. A big criticism of [[UML]] is that it’s overly-complicated. There are constructs for edge cases of edge cases, you cannot glean the immediate message. The same has been, in my experience, true of most [[SysML]] models as well... and [[UAF]]. And 80% of the constructs of [[BPMN]]. If the purpose of the model is for **simulation** or for **generating code**, then completeness is necessary. If you're using UML for creating Java classes, then follow all conventions for [[Class Diagrams]]. If you're using SysML to check design parametrics against requirements & constraint blocks, then follow the necessary syntaxes. Otherwise don't. When it comes to _software development_, there are actual testing methods that can be (and should be) used. This means UML diagrams should probably be built for **communication**. This means jettisoning the details. Focus on what’s important from a [[Pareto Analysis]] perspective. > [!warning] > [[SysML]] and [[UML]] tools are built to support simulation & are probably overkill for communication. It seems to me that [[BPMN]] serves no purpose, unless it's being used for visual configuration in a workflow management software. [[IDEF0]] is fantastic because it knows what it was for. The [[C4 Model]] is also good on this front. When it comes to [[Enterprise Architecture]], modeling is _always_ for communication. This is why [[Archi]] doesn't have a million buttons and why [[Archimate]] is good. See also: [[Modeling is for Simulations and Computers, Diagramming is for Communication and Humans]] **** # More ## Source - self ## Related - [[UML]] - [[SysML]] - [[Systems Decomposition Rule of 7]] - [[Simplicity]] - [[Simple is Maintainable]]