Those are a lot of interesting points you're raising. 
 
I'd like to highlight your scepsis regarding the desirability of introducing an intermediary component. I think central components have a tendency to become major barriers in innovation in organisations. So your advice to muster great restraint in introducing them sounds very wise to me. Can it be that the fondness to introduce central components is directly correlated to their single defining characteristic: they're involved in everything that transcends the scope of a single project/application/organisational unit and as a result represent power to architects/ISPs/vendors? A more charitable explanation is that they provide a locus to enforce standardisation to prevent maintainance nightmares. 
 
Personally I'm under the impression that a central component should be as lean as possible and play a very commoditised role: it's services should be well understood by the organisation and easy/simple/quick to provide. So that it's like the use of tcp/ip networks in organisations or like the use of commoditised applications (ERP) are meant to be.

I do think that vendors play a role; they have a direct concern in selling software products and additional licenses for additional use. It would be strange if they would tell you that you really do not need an ESB software product; that would be like a car dealer telling you that a bike is cheaper and healthier for you. 
 
I concur with your view on central components. I would even extend it to the principle that infrastructure in general should be kept as simple as possible, perform a well defined function, and should not be extended with custom code. I still see a lot of organisations spending large amounts of money in developing their own infrastructure or wrappers around infrastructure. In addition, this custom infrastructure often turns into a monster that is hindering change since lots of applications have become dependent on it.

Is there really a valid reason, I wonder, why a single CRM service can fit the needs of an entire enterprise, just like an ERP service, or data warehouse, whereas an enterprise service for application integration or an enterprise nervous system seems to be a pipe dream? Are the shortcuts in integration issues sincerely different from bypassing the enterprise directory for authentication and authorization, or any other precious design principle?

I am not stating that you should not strive for generic integration infrastructure, standardization or reuse of services. To the contrary; these are absolutely best-practices that you should apply. My message is however that you should apply them carefully. 
 
With respect to the shortcutting you refer to; I would like to see it as using the right tools for the right purposes. Your comparison with security is of a totally different order; surely security risks should not be taken lightly. On the other hand, also security measures should be applied with care. Maximum security is often not the best solution; measures should depend on the risks involved.

Hi Danny 
 
First of all. Good initiative : starting a discussion on the question whether or not SOA is the silver bullet, the newest IT hype or just a nasty disease (not exactly your words).  
 
In the initial statement and the subsequent reactions I see a couple of different themes. (1) What should be understood by "services" and are they so different from "components" in the traditional sense of the word? (2) What is the role of the "ESB" in a service oriented architecture? Is an ESB a MUST or can we request and provide service without intervention of an ESB? By the way what do we mean by an ESB? (3) How come SOA prophets seem to think that all experience from enterprise architecture is no longer valid? 
 
In my view all three themes need attention. 
 
Ad (1) In Ziv Baida's thesis on service bundlining read a good definition of "service". Ziv makes a distinction between (business) services, e-services and web services. I think that in order to avoid confusion we have to adopt a similar definition. Ziv's e-service is very similar to a component with an interface, a runnable an data. Ziv's business service is not comparable to a component. This type of service does not need to be fully automated; i.e. can also contain human interventions or even be completely manual. If you think about it in this way service level management (to give an example) is a SUPERSET of IT service level management. 
 
Ad (2) Litteraly Service Oriented Architecture deals with providing and requesting services. I see no good reason why this could not be done without an ESB. I realize that in saying this I divert from the official message that my employer (IBM) is bringing to the market. 
 
Ad (3) I think you are absolutely right in stating that all old (good) experience from Enterprise Architecture (and Component Modeling and Operational Modeling and ITIL and.....so on and so forth) still apply. We just started an interest group on SOA governance and management and one of our first conclusions was that it partly builds on EA, partly on ITIL.

Hi Lydia, 
 
Indeed I think that a lot of confusion stems from the multiple meanings of the term "service". Personally, I like to refer to the ArchiMate terminology that discerns business services, application services and infrastructure services; business services are defined independently of any IT support. Another distinction made in ArchiMate is external versus internal services. External services are exposed to the layer above, whilst internal services are exposed within the same layer (business, application, infrastructure). Services in ArchiMate are primarily aimed to be EA constructs; they show which behavior is exposed from a certain element. This does not automatically imply that it is a service from an integration perspective, and even if it does it's implementation does not have to be a Web Service. And even if the latter does; it does not necessarily map 1-1 onto a specific Web Service. 
 
With respect to ESB; if you think of it as a concept then all application integration can be seen to use the "ESB", independent of whether integration middleware is used. 
 
Regards, 
 
Danny