The Basic Elements of SO Architecture

What does one need to do SOA? Let's elaborate on this from an IT Archicture point of view.

For a very basic and easy SOA-Architecture you honestly don't need that much, not even an ESB or any other infrastructure. You may just build Services (preferably published as WSLD) and let them communicate with SOAP over http. That's all.
But if you would like to get all the advantages of SOA (i.e. agility, flexibility, substantial cost savings, abstraction of complexity, standardization) you should think about a clearly structured and standardized SOA-Architecture.

First you should therefore think about how you'd like to reduce and standardize the today available communication protocolls between your systems. This is a very important step towards SOA since a standardized infrastructure helps in saving development and deployment costs. I suggest that you choose three different protocols for the three basic communication patterns: asynchronous (e.g. jms), synchronous (e.g. http(s)) and bulk transfer (e.g. (s)ftp). To achieve this you may build your own infrastructure framework by for example building adapters that can be pluged into your applications. Or you may buy an ESB that is sold on the market by many different vendors.

Second you need a software to manage your services. By doing so you avoid an unmanaged service cloud. This is just as you would manage any other assets of your company. In the SOA context such a management tool is called Service Repository.

Third don't forget to think about security. Most infrastructures and repositories offer basic components such as service authorisation or provider/consumer authentication. But you still need to make sure this components comply with your security model.