This is a mix of good, bad, and annoying
Good: the author really does know a lot about modeling (except data modeling, see "Bad") and gives good explanations and examples of many aspects of modeling at many stages in the development process. If you can plough through his 350+ pages, you will have found many stimulating and practical concepts and some good advice on implementing them.
A very good chapter is Chapter 29 - a discussion of how to implement Agile Modeling - or really, any agile practice - in a usually hostile world. Some battle scars showing here!
I also like that he does not consider the UML the be-all and end-all of modeling tools. Like him, I've found good use for the trusty old DFD (Data Flow Diagram) of the 70's, where appropriate.
And his overall message - that the agile approach can extend to your design and modeling task, not just code, and the implications for minimizing the documentation effort - is very strong.
I find his reference to quick diagrams "on the back of a napkin" a bit overdone. Sure, the quick informal diagram is excellent, but paper napkins are not the best medium! Hand-drawn on a piece of paper, or a card, sure...if you are discussing models in a bar or restaurant with that degree of focus...get a life!
Whiteboard and digital camera can certainly be used much more than they are. But the overall point is excellent: that when you are documenting (and he has some difficulty separating out "modeling" from "documenting" and acknowledges the problem) you are not creating the end-product, and there is a cost for that. "Travel light" - yes. As Einstein said "Everything should be as simple as possible, but no simpler."
Bad: his data model example is terrible. What's with adding surrogate keys to every table? This is a pernicious practice that has become all too common from people who never learned relational theory and try to fit relational into the object model. A giveaway is that he calls his "identity" columns "persistent object identifiers." Yes, sometimes they are necessary or useful, but in general the natural key is way better. In his Customer table, there is a customer number - but it's not the primary key, a pesky OID is! He himself acknowledges that this may give performance problems, or at least not be optimal. It implies more indexing and triggers...oh well, enough already. Just don't let RDBMS gurus like Fabian Pascal or Joe Celko see that chapter.
Slightly annoying: A few little niggles about English usage etc - by now you would think that any publisher's editor would know that "supersede" has no "c" in it, and that you can't be "reticent to" something - the word is "reluctant. Odd. On the other hand, thank goodness for someone who understands why it's "co-located" not the bizarre "collocated" that I see far too often.
Really annoying: Basically, Einstein's phrase above could have replaced about half the book. It's incredibly repetitious, and also over-organized, over-conceptualized, over-categorized, generally over-inflated. We need a discipline of Agile Communication! An end to ListMania! A thoroughgoing refactoring of the contents is in order. His four Parts and thirty Chapters contain massive redundancy. The matching of agile modeling precepts, in finest detail, to the equally excruciating detail of the RUP, is really an unnecessary exercise. We don't have TIME for this!
As someone else said, a short White Paper could have replaced the entire book. Hence the two stars, good though some of the material is.