In a previous life, I talked my boss into buying one copy of Rational Rose, the premier UML modeling tool of the day. It was I believe version two and it was on some UNIX platform. For those that remember these days, Rose on UNIX didn't work very well (lots of crashes). I then went on to join Rational software and I believe I got the job partly because I had Rose on my resume. My first two years with Rational were all about promoting and selling Object-oriented Analysis & Design classes and Rational Rose. And we sold a lot of them. Most enterprises those days had a few leaders that kept abreast of the trends and OO was a hot topic. And Rose was considered a necessary part of the solution. You needed a tool that could capture the UML diagrams that were going to revolutionize the software architecture profession.
Well, it didn't quite work out that way. I am still today a strong proponent of modeling and believe that any good architect needs to have strong modeling skills to be able to communicate their architectural ideas. I am sorry but Powerpoint and/or Visio just don't cut it. That being said, it is apparent to me that in general, software IT shops do not consider models to be a key and strategic piece of their software development lifecycle!!! I have to wonder why.
One place to look is the actual perception of UML. No doubt that UML has traveled a rocky road. It started out with such high expectations and maybe that is where the problems began. I think there was a a "silver bullet" feeling that it never was intended to live up to. Various revisions seemed to complicate things instead of clarify them. As MDD/MDA/PBE took off and began to show promise, UML was again criticized for not being "right" as the specification for driving out detailed abstractions. I think Bertrand Meyer captured an early feeling about UML in his 1997 satirical article. To some UML had completely missed its mark.
Another perspective is that UML is not understood by or even relevant to others in the software development lifecycle. OK, use cases should be understood by your requirements people, but you hardly need to know UML to understand a stick figure and oval use case diagram. So much of how a developer creates code these days is about following standard patterns which don't have to be specified by an architect. Testers for the most part aren't helped that much by a model. And UML has probably failed the operations people the most with its almost laughable deployment modeling capabilities (see Rational Software Architect's robust topology modeling capabilities to see what it takes).
This doesn't however alter my belief that modeling needs to be a key component in software architecture, for maybe nothing more than drawing pictures (I know it sounds like Visio). However, the underlying model behind the picture still provides value, particularly if you are in an industry with strong industry model influences ( i.e. CIM for the E&U industry, TMForum models for Telecommunications). It is important that architectural constructs are based on what the industry says is important.
So I continue to preach modeling and I use Rational Software Architect almost every day. I know there are those architects out there that rely on a UML modeling tool to communicate their architectural know how. It's too bad there aren't more of us out there.