An architecture should present the technology used, but only for the public API and any shared resources.
If I'm trying to figure out how the inventory system is going to talk to the work order system then I need to know what my options are.
I don't really care if the system is developed with C# or Java, unless it affects licensing or hiring; I do care if it's using SOAP, REST, or some kind of EDI. I also care which version, and which protocols are in use. These need to go in an architecture document, otherwise it tells me nothing about the actual architecture.
I also care about the database - that's a shared resource. If I'm leaning toward ETL as a solution then it makes a pretty huge difference whether or not the source is Oracle or SQL Server.
Oh, and I need to know about dependencies. For example, if you've decided to use NServiceBus for your ESB, I need to know that because it requires widespread deployment of MSMQ, and as an architect I'm supposed to be able to say something about how reliable and/or scalable that is. Likewise, if you've decided to use WCF with Mutual Certificate authentication then we'd better be prepared to deploy a PKI.
On the other hand, I really couldn't care less whether you've chosen Spring or Castle for your dependency injection, or whether you're using Linq to SQL or Entity Framework in your .NET app. Please don't bore your readers with an insufferable account of the merits of log4net vs. NLog.
There's no simple "yes" or "no" answer - it's the same as asking how much technical detail you should get into during a meeting with your clients. The answer is "only as much as necessary". You're the architect; you're supposed to understand enough about the architecture to be able to determine whether or not some implementation detail has a broader impact on the entire system or enterprise.