From a technical point of view there are multiple entry points in a roadmap toward SOA. As I mentioned before, in large companies there is no one-size-fits-all approach to SOA. Depending on the maturity of the project environment, in which the enterprise's software development and operations take place, an adequate entry point may be chosen.
This is the maturity scale I tend to use as the distinct per project entry levels to SOA:
1. Batch-file transport over the ESB
2. Record (message) oriented data transport over the ESB
3. Shift design-focus from applications and batch-files to asynchronous real-time point-to-point messages
- at sending side: split batch file into SOAP-messages
- at receiving side: rebuild batch file from queued messages
4. Define intermediate (canonical) layer of message types to map semantics and decouple formats between senders and receivers
5. Break the applications down to well defined, documented and reusable components (services)
6. Make use of tools for Business Process Management (BPM) en Business Activity Monitoring (BAM)
By choosing an ESB-infrastructure for data exchange between applications, even at the lowest level of maturity, an optimal coherence between the old world (legacy) and the new world (SOA, EDA, BPM, BAM) will be achieved. By using web services technologies based on an ESB-infrastructure, a virtualization of location as well as technology will arise. The tooling around this kind of infrastructures will offer early visibility of the application landscape in terms of existence of and interrelationships between the applications.
So, avoid choosing one single approach to introduce SOA. But instead choose an entry point on the maturity scale for every single project, depending on the project's context. And realize it will take an odd 10 years - on average for big companies - before you may seriously be speaking of having an installed SOA base.