When talking about integration sometimes people are discussing totally contrary aspects even though they are using same words. Depending on the experience, background or context same terms might mean various things to different people. I wanted to write about how I see the dimensions in the enterprise integration space; this is just a brief introduction.

Data integration as the name says focuses on transferring data from database or system to other - it is closely related to ETL process. Data integration has a quite technical approach to integration context. It is not only batch processing of data masses or database synchronization processes but implementation of data integration solution can also be message oriented or something else. Typically requirements initiate from data centric problems two or more systems. On the other hand process integration or business process automation starts from process centric approach where business owners or units have the need either to get more efficiency out from existing processes or to implement new ones to create additional business value. 

Architectural dimension is the other big thing in the picture. The reality is that many organizations still do things ad hoc without creating and evaluating long term plans. Ad hoc integration leads to integration spaghetti with hard-to-monitor, expensive-to-maintain and strenuous-to-make-changes point-to-point connections spread all over IT infrastructure. Planned and structured integration architecture requires effort and governance but in the long run it lowers maintenance costs and enables flexible environment where IT can react quickly to changing business needs.

The more we go into the direction of process integration the more we need to talk the language of business - not only to bamboozle business guys with all the the sexy technological acronyms. Technology experts need to understand the business requirements and translate them into meaningful specs and at the same time hopefully create environment which in the long term is sustainable and agile for the changing business needs. Don't understand me wrong here - I'm not saying the never ever implement ad hoc solutions. I'm saying that if you don't care about overall architecture maybe you should because it actually gives more than demands. Also in some cases depending on the situation it is not wrong to make conscious choice against architectural guidelines but if you do you should have really substantial reasons for doing it.