Eric has a good post on some common themes between SOA and EAI. I couldn't agree more and in fact have said similar things. A lot of the problems that are present (notice I didn't say were present, EAI is still alive and well thank you very much)in EAI will be present in an SOA style of architecture.
No EAI is not a toolset as one of the commenter's tried to say, it is an architectural style complete with best practices, patterns etc. Things like abstraction, loose coupling, reusable services are all part of a solid EAI strategy.
There are some differences but not as many as some would imply. EAI shops will have a leg up on SOA. Contrary to what a lot of vendors are saying about SOA, defining a well defined, abstract, loosely coupled, reusable service is not nearly as easy as they make it out. We have already learned that from our EAI experience.
The difference I do enjoy the most is the "SOA is all about the business" and EAI was an IT thing. You have to smile about that. It's always about the business folks, that's why we are here. Any of you out there implement EAI systems and architectures and not work with the business?
So one day we will have dozens of highly decoupled, composable, abstracted, dynamically discovered, reusable services that our business users will simply string to together with their favorite BPM tool with little effort and no real involvement of IT. This is tied directly to world peace and the end of poverty and hunger.
Okay I'm off my "SOAP" box now. I like SOA and where it is trying to go from an architectural style. But eyes open when starting. Vendor fed delusions of grandeur can be costly to the aforementioned business users.
No comments:
Post a Comment