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.

Whatever view you document you'll want to show how desired qualities are promoted by your choices. If you don't feel that specific details help you describe that view then don't include them.

What you document will depend greatly on the view and the context in which technology decisions are made. Some technology decisions, such as frameworks, platform, or language are a big deal - they will have a significant impact on the system's architecture. Consider the audience and how you plan to use the architecture description.

In my experience it's useful to know what the technology decisions are and where they came from. For example, was the technology a constraint from the customer or a team decision? Beyond this I've found it's sufficient to briefly mention what a piece of technology provides, especially if it's something out of the ordinary for your team or if it is critical to achieving a specific quality.