When it comes to [[Enterprise Architecture]], data, and process modeling, there's varying levels of abstraction you can pick. More detailed gets you closer to the day-to-day reality of what's being done and worked with, but loses the forest for the trees. The higher-levels of abstraction can paint a clear picture of what can exist and why, but fails to capture any of the how or nuance. Many modeling & diagramming standards (e.g. [[Entity-Relationship Modeling Standards]]) are more well-suited for a particular type of abstraction. [[IDEF0]] gives you an excellent overview of a function from an abstract point of view, but if you're trying to actually *operate* the function you'd need a full [[Process Specification]]. **There are many examples of "types" of diagrams switching as the level of granularity changes**. - [[C4 Model]]s change to [[UML]] diagrams for the lowest levels - [[IDEF0]] goes to [[IDEF3]] for the lowest-level processes - [[Archimate]] gives way to [[Entity-Relationship Diagrams]] for lower-level data - [[Value Stream Mapping|Value Stream Maps]] can turn into [[BPMN]] or other types of diagrams One **example** I found in the source book from a company that actually laid out what the levels of abstraction they used *were* and, importantly, *what those levels were for and what they excluded*. ![[IMG_6141.jpeg]] **** # More ## Source - [[Fundamentals of Business Process Management]]