So is the need for blueprints. Too often, however, software architects become distracted by nonarchitectural issues, and they retain the typical programmer's disdain for documenting their work. A building architect wouldn't dream of designing a building without blueprints. Of course, the building wouldn't get built without blueprints. No one involved in any aspect of the process would dream of proceeding until the blueprints were produced.
Some software architects only use the term as a kind of idealized abstraction for what they do.
Such an attitude would never cut it in building architecture. And it leads to project failures, just as physical construction without blueprints leads to building collapses in countries where architectural standards lack the force of law and custom. But in the developed nations, the architect's responsibility is to provide adequate blueprints, work with the construction firm to make sure they are understood, work with building inspectors to validate conformance to the blueprints, then make formal changes to the blueprints as new requirements are identified, and as construction problems are discovered. No shortcuts in this workflow would be excused or accepted. This analogy precisely applies to software architecture.