If you model software, both existing and future state, as a primary business and technology activity, modularize where needed, reduce high level abstractions, follow SOLID/DRY for the most part, and use bounded context operational data stores, the architectural diagrams serve a greater purpose and are a primary artifact.

In other words, no one should change code without first validating those changes with the existing model(s).