Is SOA about the technology?

Nick Gall wrote a post claiming that discussion of SOA  without  also connecting it to technology is problematic. Nick bases his post on a post by Andrew McAfee that attacks the notion of "It's not about the technology" (INATT).

Andrew suggests that there are two types of INATT. One of the is lacking and the other is flat wrong and misleading.  Andrew says the first kind is "it's not about the technology alone" and that the second kind is "The details of this technology can be ignored for the purposes of this discussion."
 
Applying Andew's definitions to SOA nick says

Like Andrew, I cringe when I hear this argument -- most especially in SOA discussions and most especially in SOA discussions in the Service-Orientated-Architecture Yahoo Group (British spelling). In such discussions, technology alternatives for implementing SOA are dismissed as irrelevant and the discussion floats away on its own hot air.

Burton's Anne Thomas Manes admits she uses INATT  however she believes she uses another meaning which emphasizes the technology is secondary to design.

More specifically, technology is an implementation decision. When initiating a project, the project team should first identify and analyze the project requirements, then select an appropriate technology that effectively supports those project requirements.

Anne says technologies are tools and you need to choose the right ones for the job - the first thing should be to identify what the job is.

At the end of the day SOA is a architectural style and like any architectural work you have to first think about your architectural goals. However once you do make technology choices you have to go back and reexamine your architectural decisions. (see figure below) After all technologies, platforms etc. all come with their own set of architectures, capabilities and constraints.


(Source "An Architectural look at SOA")

In a recent article called "ESB-Oriented Architecture: The wrong approach to adopting SOA" IBM's Bobby Woolf (of Enterprise Integration Patterns fame) warns us :

"Clients often want to build only an ESB because that involves a technology challenge without the need for messy business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It does not create business value. In fact, it incurs cost without reaping immediate benefit. And it does not align IT and the business. The better alternative to ESB-oriented architecture is SOA-oriented architecture. Do not build an ESB by itself; build it as part of an SOA, preferably one that fits the SOA Foundation architecture that IBM recommend"

At the end of the day, technology is important, we cannot afford to ignore it when we design an SOA or any project for that matter. However technology should be places as second chair to business - or should it? What do you think?