The architect’s role is to design for data flow and compose functionality so it can be swapped out. Great new book on that: https://www.amazon.com/dp/0136524036/ref=cm_sw_r_tw_dp_U_x_u...
The limits of physics, with respect to, software determine more its performance limits rather than its logical limits. Setting aside performance (which is important), I can make a complex piece of software with 1000 modules each directly connected to the other. A building is not capable of a similar degree of direct connectedness. There may be critical components, your keystones, but each brick is only attached to each neighboring brick. Outside of the critical components you can remove (up to a limit) and replace many components in place without bringing the entire structure down, and often without local damage. And replacing a damaged brick in place requires rejoining with only those immediately around it.
Good software is written in a similar fashion, but software itself is not bound by the physical limits that force that fashion (until you start considering performance, which will encourage better design but only when it hits a particular pain point, or if dealing with a global network of computers).
Of course that is just one of my domains. I have other systems that are pushing bounds of what 64 bit systems can do, and there I'm more worried about how can I avoid synchronizing the cache between the cores without a race condition. I don't have to worry about the servers hundreds of miles away though, that is a different architect.