I think it highly depends on your work context, wouldn't exactly call it dead but firmly in the trough of disillusionment. Funnily enough, I think the author's

I think it highly depends on your work context, wouldn't exactly call it dead but firmly in the trough of disillusionment. Funnily enough, I think the author's analysis is a bit off, or rather misses essential points. They somewhat blame the procedural changes for a demise of UML. The problem they don't speak about that UML is not universal, it has serious flaws. # Complexity as a Modeling Language It can only be understood by those extensively trained in UML. Really, show someone a UML diagram and they won't understand them. What are those arrows supposed to mean? The boxes. etc. About a dozen different diagram types don't help either. In fact, I have seen so many faulty diagrams, activity diagrams that contain error and mistakes because the semantics were not properly understood that just confirms how complex UML is. Furthermore, I was in UML corporate trainings and the instructor made mistakes about UML activity diagram semantics, etc. It's that bad. From that perspective, thinking that a business person may be able to understand is wishful thinking # Object-Oriented Paradigm and the 'Encoding' Problem UML at its core assumes object-orientation. That means that class-diagrams replace Entity-Relationship diagrams. Class diagrams may work as an 'encoding' of ER diagrams, but its fairly complex. This is a pattern that repeats for a couple of applications of UML. It is possible to model a lot in UML, also by extending UML with its possibilities to extend it, but the results really look like a strange encoding and its hard to read these diagrams. Overall UML has replaced a Zoo of diagram types that were more or less established and the results are often not pretty. I made a deep dive once into diagrams of the 80ies and 70ies and overall a lot felt refreshing. # Model-based Engineering and Tool Vendor Takeover I haven't been involved in UML prior to version 2, but it overall feels like UML is a vehicle by vendors of UML tooling to sell their products and as such, UML has adapted the idea of model-based engineering. When the naive assumption of a software engineer about UML is, that a couple of Visio/draw.io/Dia diagrams will do, one learns over time that its hard to maintain these models, and the fix for it is to use a modelling tool such as Enterprise Architect or Rhapsody that contains a whole Tree of UML entities from which you derive your diagrams as viewpoints. Its like falling through a rabbit whole. If you manage to avoid this rabbit whole it just means you probably are only using a small subset of UML. I think this lead to UML becoming increasingly complex and the language standard should probably have been limited in a way that it remains useful without the tooling. # Lack of Block Diagrams and Data-Flow diagrams If you look at ad-hoc (non-UML) diagrams in open-source documentation and corporate ppt slide decks, or look at diagrams your colleagues draw on a whiteboard, what one really quite often sees is diagrams that show data flow, as in: "Frontend in the Browser requests data from the backend service, backend service retrieves data from the SQL database and the object-storage system". These simple relationships are remarkably hard to nicely communicate in UML. Hence, if you intuitively start to describe a Software system, UML will not make it easy. # Whats the alternative? I am personally a huge fan of FMC (http://fmc-modeling.org http://fmc-modeling.org) but am the first to admit that it is a little obscure, but it offers everything I consistently need. * block diagrams for data-flow and system interactions, structure * Petri nets for behaviour * E/R diagrams for data structures. Surprisingly, the diagrams seem to be fairly approachable for engineers and business people alike. A lot of the micro design decisions for the FMC diagrams have been done right. In block diagrams, arrows point in the direction of data flow, everyone can understand that. In E/R diagrams, the 1:N relations also have arrows pointing to the `1`, that's somewhat easy to grasp. Petri nets are equivalent to UML's activity diagrams, but don't omit the drawing of 'places'. With places being drawn, people have at least the chance to grasp the semantics and firing rules (that are also present in UML's activity diagrams but people just don't make that connection).