That fact makes the key design principles different. Fully a third of the bullet points on this cheatsheet speak directly to the needs of making that kind of change later.
It should also include
>Bias: Is this an agnostic solution? Am I or anyone else too invested in it?
An architect is more likely, like his building counterpart, to see the system from the top down. That is given a clean sheet of paper: How can we achieve the availablility and fault-tolerance we need? what is the threading model? how does the system connect to the outside world? etc...
Whoever takes the role of doing this makes sure that the direction of the implementation doesn't loose sight of these goals. He may even create non-functional requirements.
Testing, for example, is obviously paramount in architecting buildings because failures can be horribly expensive and lethal ... but software development is too often prone toward "happy path testing".
Repeating is more problematic in software thanks to Ctrl-C / Ctrl-V, whereas other disciplines have nontrivial time & cost sunk in doing something more than once.
Cost of changes is profoundly different. Since building software is nigh unto free (click "build", wait seconds or minutes) instead of costly (bridges take months or years), those involved are too often seduced by the notion that changes cost nothing.