Once upon a time... I spent about three months working nearly full time with five juniors putting together a set of interlocking business process and applications models for a client. The results were beautiful: three fat binders filled with wonderfully clear IEW drawings lovingly printed on a QMS Color laser bought with project funds. The client was happy - he even carried the binders to various conferences and made overheads out of a few particularly complicated pages - everybody got bonuses and I was so proud.
It was a great success - unfortunately it was also absolute garbage: completely out of touch with the daily realities faced by the client's users and pretty much a complete distraction to the development team eventually contracted to build the application.
So what happened? well, the IEW toolset imposed its own view of the modeling process, the control processes imposed by the client insulated the modeling team from both the users and the developers, and behind each beautifully formatted arrowhead in each colorfully printed diagram lay a host of assumptions, beliefs, and simplifications that no two people anywhere in the process truly understood in the same way, that no user could be bothered to even try to understand, and that couldn't be explained in actionable detail to either the BASIC idiots hired by the contractor or their COBOL blinkered supervisors.
On the positive side we got paid - everybody got paid - and I learnt a great and important truth: you can use diagramming as a kind of symbolic aid in discovering a process, but have to use words or mathematics, not diagrams, to describe it - and the corollary? if you can't describe it in words or mathematics, diagrams won't help you code it either.