"A software architecture document is a communication tool."
No, it's a CYA tool to ensure that the worthless development team can justifiably blame whatever mouthpieces were the fountainhead of poorly understood/communicated requirements.
Until the requirements/analysis/decision process is removed from organizations' hierarchical frameworks, until everyone (and I mean EVERYONE) comes to terms with why development teams are universal failures, users hate software, managers are process-ignorant overseers, analysts are paperpushers and executives are shamelessly ignorant bullies, the entire requirements documentation process is an excersise in froth.
Let's not actually believe our own propaganda, shan't we?
If we start to believe that we really do NEED our "architecture document" to get anything done, we will hand every single project right on over to people who will then black box the entire analysis/development process by conducting it in Urdu. Besides working for tap-water, they will have actually given the business software to hate/use/wait for version 2, which is the entire point.
Let's not take seriously the idea that users, or (even more laughably) managers, or even developers somehow know what software will be like BEFORE it's put in front of them.
"For example, early in a design project, developers can review the software architecture to catch improper design decisions at a time that will have the least impact on cost or software redevelopment."
What a joke!
What perverse risk-terrified ostrich concieved of that idea? The whole concept of development is not to dispense with risk as much as possible BEFORE the thing is built, it's to COURT risk, to actually learn what needs to be done by FAILING AS SOON AS POSSIBLE. The whole front-loaded design-first/build-when-we-are-absolutely-sure-what-we're-doing-is-EXACTLY-what-the-idiots-specified process is a shameful waste of time, talent and money.
"Finally, due to the standardization and focus of the software architecture on specific quality attributes, architects can focus on best practices or design patterns to create system components. This enforces standard object-oriented development goals such as code reuse. "
What!?
In reality, "best practices or design patterns" don't ever actually "create system components". They don't do anything at all other than describe what real, smart humans create in response to SPECIFIC SITUATIONS and immediate quality feedback AFTER THE FACT. This is not a semantics game, this is another obvious example of how not to think about process instead of result. Defining the issue as a judgment on process instead of value, and then droning endlessly in management/software development theory-speak only confuses what really matters (i.e., real productivity) with managers' inept justifications of glorified supervision-oriented task attempts (i.e., their worthless jobs).
There should never be "standard object-oriented development goals". There should only be business goals, not as defined by "stakeholders", but truly understood and embraced by developers. One does not substitute for the other.
Unless developers know and care themselves what should be built, and how, by deciding for themselves what projects' priorities are (and being correct), everybody involved (including CIO's) should just read this crap in English while they can still keep picking up paychecks for sitting around.
If you really, truly believe that "standardizing a definition of software architecture" is in any way whatsoever important, then you are a fool, an idealogue or insane.
Try standardizing on competence, courage and passion. If you can't, then nothing else matters.
