It is almost always good practice in IT design to tease apart the functional (also known as the logical) requirements from the implementation aspects. How often have you heard an IT expert say "You tell me what's you want changed. I'll work out how to do it." But this does not mean that the functional design should precede the implementation design or that the one should not influence the other. There are several reasons why the technology architecture is a business issue.
In todays world, perhaps more important than the above, is the fact that most organizations are not starting from scratch but have existing applications in place. This influences the design and impacts future choices of technology, if only because of the profile of organizational skills.
One of the long term goals in bringing forward the development of the technology architecture in the design process is to get a better handle on performance and cost. Business metrics (like transactions per second) are usually provided (albeit they often measure hope not expectation), and turning business metrics into IT metrics such as the number and size of messages passing between machines is usually possible. Turning those numbers into performance and cost metrics is much harder. The best way is to look for comparable configurations. Failing that a benchmark is possible, but you should be aware of the impact of other work (even low priority work) and the additional complexity of a real implementation compared to a simple test system can radically alter the result.
Another area of the technical architecture that has a strong influence on the functional design, is security design. We divide security design into two projects which we call a white security study and a black security study. A white security study assumes the technology works perfectly, and asks questions like who gets what privileges, who get to dole out those privileges, what happens when people change jobs, and why do we trust our security administrators? A white security study is about the business aspect of security and is likely to influence application design and human interface design. A black security study on the other hand assumes the security is configured exactly how the business wants it and then tries to find ways in which it can be circumvented. A black security study is very technical. At the moment our modelling efforts are towards assisting white security studies not black ones.