No, but it does have its uses. I've found it particularly helpful when communicating complicated technical decisions to non-technical management. They "feel" li

No, but it does have its uses. I've found it particularly helpful when communicating complicated technical decisions to non-technical management. They "feel" like it's a true technical document (even if it only superficially conveys what's actually happening) and it empowers them to make better decisions. Amongst actual technical staff? I don't think I've ever even seen a UML diagram on display in my entire career outside of perhaps the occasional E-R Schema model. Honestly, that gap is one that really does need to be addressed since technical staff pretty much work on whatever they want to work on, master design documents be damned. Perhaps some of it is that extant architecture methodologies are all top-down, where information concerning design and intent flow down, but there's no formal feedback loop, a bottom-up component, in-place for implementers to say "well, that doesn't make sense, we're going to do it this way, change the design docs to reflect". I think it's this lack of a formal approach from both directions that really cause a lot of large systems engineering and integration projects to end up with poor results. Many "technical" UML users I've come in contact with tend to be a decade or more removed from the actual technology they are designing around...familiar only with feature and capability lists of the technology ecosystem they are working in. In management meetings they'll continue to pull out year old UML diagrams built in a vacuum to make a point, when all they have to do is talk to the most junior developer to see that the de facto picture is wildly different than in the docs. In the end, all that really matters is that the system does what it's supposed to do, it doesn't matter as much how it actually does it. UML makes non-implementers think they are having some say in how things are to be built when it's very rarely the case. Another interesting thing I've noticed is that as time has progressed, in order to become more useful, the UML spec has started to vacuum up other traditional diagramming techniques beyond just use cases event models. This is definitely an effort to make UML "work" for technical folks and not just decision makers. Unifying/Rationalizing higher level models with lower-level technical models is actually pretty hard and demonstrates a large number of problems with both sets of models pretty quickly, faster than cranking out half-baked code. I will say though that I've started to see better models for communicating architecture to management recently. Archimate springs to mind: http://en.wikipedia.org/wiki/ArchiMate http://en.wikipedia.org/wiki/ArchiMate It leaves out lots of details that are irrelevant/dangerous for decision makers to see, while focusing them on the entire enterprise stack. I believe it's not part of the newer TOGAF frameworks.