Enterprise integration architecture (EIA) is about being reactive – it's an architecture to facilitate integration of applications that were never designed to work together in the first place. Typically, the primary role of an EIA is synchronizing data among all the disparate systems. So, for example, you might need to make sure a customer's address change is recorded in all different systems that have a copy of the customer record.
In contrast SOA is about being proactive – it's an architecture designed to enable applications to work together the day they are deployed. An SOA, instead of focusing on synchronizing multiple copies of redundant data, seeks to avoid the redundancy in the first place – providing a single view and way to manipulate common business entities such as customers, orders, etc. and a single way to define your business processes on top of these – regardless of the underlying applications.
Real world architectures, in fact, require a bit of both approaches. You will never be able to fully eliminate redundancy or having processes built into applications if you own and use multiple packaged applications – thus the continued need for EIA. However, for custom applications, overarching business processes, portals, Web sites, dashboards and other similar applications, having these applications use well defined services for common business tasks information access can dramatically improve your time to delivery, total cost of ownership, and – in the end – your business agility.
Dig Deeper on Topics Archive
Related Q&A from Daniel Foody
Daniel Foody defines end-to-end security and discusses the different parts of security to consider. Continue Reading
Dan Foody discusses the capability of using Web services for ASP applications. Continue Reading
Daniel Foody discusses the "find-bind-execute" paradigm and secure service directories. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.