> I wouldn’t expect two teams in different companies, one in California and the other in New York, to use similar notations unless someone was deliberately keep

> I wouldn’t expect two teams in different companies, one in California and the other in New York, to use similar notations unless someone was deliberately keeping them in sync. I feel like you need a reference implementation for almost any spec out there for it to remain consistent, like a tool that everyone might use for working with UML or whatever. For example, have a look at BPMN, which has https://bpmn.io/ https://bpmn.io/ without which it would be another spec that many wouldn't care about. Of course, the tools actually need to be good, because I've seen too many bad Eclipse based pieces of software, like for 4EM modeling or other approaches that never really took off in the real world, outside of niche contexts. It might be a case of model driven development feeling pretty useless, unless it actually helps you develop the solution with minimal friction. A good example of this are ER diagrams in MySQL Workbench! For example, consider the following, what I've sometimes done: - open MySQL Workbench - reverse engineer an existing DB, get an ER model - alter the model as necessary (add tables, change columns etc.) - use the forward engineering/synchronization tools to get DDL that could be applied to DB - execute or alter as necessary beforehand Contrast this to the workflow that a colleague of mine had: - open draw.io - open a manually drawn ER diagram of the DB from local/shared disk - compare against DB schema manually, possibly fix parts that have changed in the DB since last diagram update - alter the model as necessary, using regular drawing elements and text (with lot of it being more like working in Paint) - once happy with this "documentation" and it looks good, manually write all of the SQL that's needed for migrations - execute the SQL I think the best kind of documentation and models is the one that doesn't lie to you (can be updated automatically) and tools that integrate with what your infrastructure/application/schema actually is supposed to be, rather than some out of sync model. Otherwise you end up with documentation that is wrong or that nobody cares about. If you want something like UML or any other modeling approach to be popular, I'd argue that you'd need something like the following: java2uml --in-package src/java/main/dev.kronis/sales_app_2022/products --out-model products.uml "MadeUpSoft UML Studio" > File > Open > products.uml ... do your changes "MadeUpSoft UML Studio" > File > Save uml2java --in-model products.uml --out-package src/java/main/dev.kronis/sales_app_2022/products Until we have model driven development that goes both ways (forward and backward engineering), the use cases for it will be severely limited.