Begin with business processes and then progress into leading-edge technologies
SOA is not Integration and Integration is not SOA.
Integration remains a specialized discipline, especially when one considers the range of toolsets (EII, EAI, ETL, BPM), use cases (Composite Applications, BI, Portals, etc.) and architectures (CS, Web, SOA, Legacy) involved.
Further, ICCs can be implemented across a range of centralized and distributed models, coaching vs. doing, provisioning vs. developing vs. operating, and more.
Bob Eve.
Integration can be done via services, there's no doubt about that. I'm not surprised at all that the vast majority of survey respondents also indicated that ease of integration was a driving force for their SOA efforts.
There was recently a discussion around integration on the Yahoo SOA list and some debate on whether integration always required a third party or not. I fell into the camp of saying that making two systems talk to each other, with or without a third party, is an integration exercise.
Where I'd like to see things go is where integration with other systems becomes a primary concern, rather than something done when we need it. If we design integration points (which not surprisingly, should be services) from the beginning, rather than bolting them on when needed, we'll be taking the right step forward. If this is the case, then all developers should be thinking about integration, not just the integration technology specialists.
@bob eve
"SOA is not Integration and Integration is not SOA"
That's correct. But an integration architecture might be service oriented (which, strictly speaking, makes that IA an SOA).
SO principles borrow many notions from common integration practices. It is no surprise then that many associate SOA with integration.
To get a little abstract here, SO is about service consumers interacting with service providers. Typically, the consumers are in different ownership domains from the providers. That, almost by definition, is integration.
SO can be viewed in a manner such that integration is effectively the core value. Components are designed from the outset to be integrated with other (possibly unknown at present) components. Instead of an afterthought, integration aspects are considered right away.
Topic: SOA
SOA uses interoperable services grouped around business processes to ease data integration
Blog: A Fresh Look at SOA Governance
Article: Joe McKendrick on The Evolution of SOA
White Paper: Driving Business Agility Through SOA Connectivity and Integration
Related Topics
SOA for Dummies: IBM® Limited Edition Mini eBookThis eBook introduces you to the basics of SOA in context with the real-life experiences of seven companies, demonstrating that SOA allows you to work smarter and optimize costs for more significant business success.
Driving Business Agility Through SOA Connectivity and IntegrationThis white paper shows how a service oriented architecture (SOA) helps align the infrastructure with business needs in order to achieve maximum flexibility.

Learn more about this middleware layer that pools and dynamically provisions infrastruction application delivery resources to lower costs and improve efficiency.

The technology tips and tools to enhance your ability to respond to business change with ease and success.

Service-Oriented Architecture is the catalyst that allows today’s companies to respond to business demands faster and more effectively than ever.
Social Media Policies ToolkitDefine the rules at your company for the proper use of social media platforms such as Blogs, Twitter, Facebook and Youtube. Ensure your users are spending their time productively and company resources are being used for the business.
The Complete IT Policy KitDownload a comprehensive bundle containing over 40 IT policy templates. Each can be modified to align with your specific business requirements. Complete instructions are included.
I think a lot of the confusion on this topic is because a lot of folks never really understood Enterprise Application Integration in the first place. EAI is not about tying applications together in fact it's just the opposite. It's about how to make you applications communicate and exchange events without the applications knowing that they are communicating and exchanging events. A lot folks don't understand that and it showed in their EAI deployments. They ended up with a bigger mess but in centralized location.
The concepts behind the pattens of EAI are very similar to SOA. Abstraction, reuse, composability, fine grain, coarse grain are all there in EAI just like SOA. Integrations are in effect services if done correctly not just moving data around which is a common EAI misnomer. It's not the latest and greatest buzz word so a lot of analyst are glossing over the actual details of what EAI was and is. Sure they are lots of folks who wired two apps together and called it EAI. There are also a lot of folks who are doing RPC calls via Web Services and calling it SOA.
The comment saying EAI is tactical is not accurate. I not sure how anyone who has worked in business IT shop could come up with that statement.