My job is to look at how the system we build fits into its environment. In my case, the lead engineers are similar to the structural engineers that you have in building architecture. Their job is to ensure that the things we design can actually be built and maintained by our programmers. What I do is figure out how it interacts with other systems, and with its users, system-wide and in the long term. My job is to look ahead and think about what the users are likely to want in a few years time. Of course I have no hope of doing so in detail (typically, users don't even know what they want for themselves, right now), but I can hopefully see well enough where things are going to make sure that the core of the system won't need to be recreated from scratch anytime soon. I think building architects have a similar role: they design a building for a client, but also need to take into account that the building will still be there decades into the future, and still needs to earn its keep then.
So, I think that building architects and software architects have even more in common than what you described. I even think there is an equivalent to that other job of a building architect: making it beautiful. Of course software has no physical embodiment, so it has no physical beauty (artful syntax highlighting excepted :-)), but its design can still be just _right_. It's hard to define what makes a design right, but a good software architect recognises when that is the case, just like a building architect recognises a good-looking building. Linus Torvalds (original author and architect of the Linux kernel) even calls it "taste".
As an added bonus, Lourens ended his email with a little bit about why he loves computer science so much in general. I wanted to include it here because the point about puzzles is so similar to what I love, too.
The attraction of computer science to me has always been the solving-a-puzzle aspect, and while software architecture is certainly not the most technical area of computer science, getting current user requirements, potential future requirements, current technology and future technological developments all covered in a single design is usually a very interesting puzzle. And a rewarding one too, if you manage to give the users a system that satisfies their needs now and into the future.
Really makes me want to be a software architect myself one day! I suppose if I do end up in industry at some point (and I hope I do, at least during internships), this is something to explore. Thanks again for letting me share your perspective, Lourens!