I like the concept of 'Masala diagrams' that OP introduces - I've drawn these a lot, and the UML-trained part of me is always slightly uneasy that I'm combining (say) data and process flow on the same diagram, or that some of my boxes are physical machines and some are programs, etc. But the thing is, you shape your masala diagram to communicate whatever the thing is you want to communicate. You'd need 3 or 4 UML diagrams to cover the same thing, and no-one would really care that you'd bothered to keep to the conventions.
IMO diagrams work best in tandem with actual docs. The diagram is an abstract — you glance at it to get a high-level understanding, and if you need to deal with the details you can look at the writing. UML always gives me a headache; I hate having to squint at a diagram to deduce details that I could just be reading about.
