Experts talk about the relation between SOA, Integration, and Enterprise Architecture

SOA, Enterprise Application Integration (EAI) and Enterprise Architecture (EA) are three highly discussed and interesting topics for many architects, developers and software designers. There are differing definitions of each topic, its characterestics and design requirements. This leads to questions about the relation of these topics to one another and how one domain stands to benefit from the principals and experiences learned in another. In a recent dialogue in the SOA Yahoo Discussion Group, several industry experts chimed in with their views on the relation between these three areas.

According to Ashraf Galal, SOA and EA and their corresponding governance reveal a great deal of overlap in their concepts, activities, processes, and outcomes:

For example, both require input based on business objectives and produce outcomes that are tied to and measured against these objectives.

Furthermore, both aim to address issues on the enterprise level (strategy and planning, reference architecture, and so on), and at the same time their governance models are similar. An enterprise that's adopting SOA while developing EA and its governance may encounter problems if the similarities and overlaps between EA and SOA are not recognized and accounted for.

If we look at business architecture domain, SOA address the business processes while EA addresses the business architecture.From application architecture domain, SOA address servcies and components while the EA address the application architecture as a whole.

In the integration middleware architecture domain, SOA addresses Integration architecture / ESB, while EA concerns with technology architecture. Data architecture is addressed by SOA while EA address the information architecture.

And from operations architecture domanis, SOA addresses QoS, security, monitoring & infrastructure while EA again concerns with the whole technology architecture.

Rob Eamon however, believes that SOA should not be viewed as a distinct architectural level which appears to Ashraf's implication:

My view is that SOA does not infer any scope and does not define a new level. SO can be applied to BA, EA, IA, or AA (or whatever). SOA is not a replacement for EA or something you do in addition to EA.

If an SOA group exists and is operating at the EA level, and an EA group also exists, expect conflicts. They are both doing EA though likely in different ways (different styles).

"SOA is something you do" is a popular phrase. I'd like to modify that a bit to "Architecture is something you do, perhaps in an SO way."

Herbjon Wilhelmsen quoted an Open Group white paper in response:

According to an SOA white paper by The Open Group SOA is an archtectural style that can be used for EA. EA frameworks must be able to support the features of SOA.
 
A few quotes from the paper:
 
P 6:
Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. It is a way of thinking in terms of services, service-based development, and the outcomes of services.
 
P 11:
SOA is an evolution of traditional enterprise architecture styles, not something different. It has new features, which deliver major benefits. Enterprise architects must be able to take advantage of these new features, and they must therefore be supported by the architecture frameworks that those architects use.

Based on Thomas Rischbeck's experience however, projects touted as SOA are very often just service-oriented integration, which implies that in practice, SOA and EA may be more 'tightly coupled' than we think:

SOAs are not typically built on Greenfield. Gartner estimates that 70% of the services in an organization's portfolio will be assembled from established assets -- for example, from legacy (mainframe) applications and old (pre-SOA) versions of ERP applications. Integration features, such as adapters and translation, facilitate the "on-ramping" of such IT assets.

Now there's one final edge in the triangle relationship: how does SOA relate to integration? My take: projects touted as SOA are very often just service-oriented integration (SOI), at least according to my customer experience. There are no processes (only integration processes) and there is not much reuse. Service interfaces are used as integration points for systems and applications (sometimes these come as part and package of current ERP/CRM systems). However, such interfaces are mostly technical, API-oriented, bottom up. To create a meaningful portfolio of (normalized) service endpoints, some kind of intermediation is necessary.

To put some of these views into perspective with the 'official' definitions of these terms, we also consulted Wikipedia:

A definition of SOA taken from Wikipedia:

In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems package functionality as interoperable services. A SOA infrastructure allows different applications to exchange data with one another.

A definition of EA taken from Wikipedia:

Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.

A definition of Enterprise Application Integration from Wikipedia:

Enterprise Application Integration (EAI) is defined as the use of software and computer systems architectural principles to integrate a set of enterprise computer applications.

 How would you distinguish these three concepts?