Brown proposes four levels — context, containers, components, code — and his central claim is that most architecture diagrams fail because they mix levels and because nobody knows what a given box means. A map is only a map if it works without its author standing next to it.
What I did with it
I sorted out what the architecture map actually delivers. Context and containers are what a management team can use; deployment and dynamic views are what the people running the system need. I never draw the code level: it ages within a week and it already exists — it is called the code.
Components I generate from the system itself when they are needed, by reading the module manifests, rather than drawing them by hand. A hand-drawn picture of something already written is a copy that starts lying the day someone edits the original.
And I built a review list for before delivery: every box has a type and a responsibility, every arrow says what travels and in which direction, the legend exists. It is dull, and it is what separates a map from a nice drawing.
What I left out
The tooling. Brown pushes his own text format for generating diagrams; I use whatever the client can open and edit once I am gone, because a map that only one tool can edit is a map that freezes.