EAI is an acronym for Enterprise Application Integration, which is something that we have created to solve the fact that we for many years have created IT systems that are isolated islands, most often not supporting business process, but rather functions in the company. When companies began to become process oriented we needed to integrate this islands with each other. The first step was to create point-to-point integrations which is a quick and initially cheap way to solve the problem. This created new problems with to many points connected to each other and therefore platform companies like IBM, Oracle and Microsoft created EAI products to help us handle this mess of integrations.

For me SOA is mostly about two important aspects:

• Enable business agility
• Business/IT alignment

Of course EAI can help making businesses more agile, but still EAI is there because the software is not aligned to the business. The two most important aspects of the business is its business processes and the information required in this processes. We therefore use these two aspects as the baseline for the service oriented architecture. The business/IT alignment is one important aspect to enable business agility, because it will be easier to identify what in the service oriented architecture need to be changed when the business evolves. But to allow the business to be agile we also need to create smaller (but not to small) autonomous services which are loosely coupled to each other. This enables change in one service without effecting the other and in that way enables business agility.

Service oriented architecture is about architecture which is very much about the business aspects and of course with its alignment with IT. The technology part, about how we make services autonomy, loosely coupled and so on is just Service Orientation (SO). Statements like "Services and workflow is really all there is to SOA" as I heard on a Microsoft conference yesterday should have ended with only SO. If Services and workflow is all there is to SO is not something that I will comment in this post though.

When covering this subject I should probably also mention service-oriented integration (SOI), which is a functional integration pattern. This pattern has a big benefit of being interoperable and a decoupling between the interface and the implementation, which therefore also enables some business flexibility. SOI is a pattern that can be used when doing EAI, and is not SOA. The SO part, is once again the technology part described above.

I'm tired of listening to people telling me about their SOA initiatives when all they really do is integrating systems, aka EAI. EAI can add a lot of business value, but it should still be named as EAI and SOA. There are other examples of people and companies stretching the meaning of SOA to mean "their" thing just because SOA is the hot buzzword. I don't believe that SOA as acronym (or Service Oriented Architecture) will survive this stretch of use, but I feel certain that the principles behind SOA will survive and are the best way to enable business agility and business/IT alignment, that I know of today.