"I define an architecture as that which solves the non-functional requirements, independent of the domain"
I wouldn't agree with that at all. Architecture is there to support the fulfilment of all requirements. Sure, if your functional requirements don't rely on any aspect of the tech then you might conclude that architecture and functional requirements are orthogonal, but that's just a particular type of project rather than a global rule. Of course, that tends to be the implied context in many of these discussions.
There are many environments where the delivery mechanism and architecture supporting that is very much a functional requirement, and where the architectural solution isn't swappable without functional effect.
For traditional DB-driven business systems, where you're given a business process to automate / assist users with, the underlying tech, architecture & delivery channel are not necessarily significant factors that anyone other than developers/ops sees, but that's far from the only kind of software that needs architecture.
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).