"You get to SOA through integration, or more accurately the loose coupling of systems that create and architecture that's easy to change. " - returns to the discussion of where SOA starts.
To me, SOA starts in disintegration, disassembly of the business model. This allows to answer WHAT and WHY we need those systems that might be loosely-coupled or integrated, and whether an integration or loose-coupling (i.e. HOW) can really help us to achieve the "easy to change" state. I think, IT did enough already trying to 'guestimate' what really Business needs. SO may be and should be applicable at all levels but only after getting the clear understanding (from the business perspective) of 'what to do this application for'. I am glad for Dave with his definition of a "good architecture" but cannot 100% agree with him. If you have quite stable and steadily growing market, you care mostly about sufficient scalability and performances rather than flexibility, which you do not have business needs, i.e. changes, for. Is an extremely flexible architecture is the right/good one for such market? I do not think so; it addresses different concerns than the market needs. Integration may be a part of SO solution (SOS) but as its intermediary outcome, not as a way into SOA/SOS [see, the start point matters]. The statement "You get to SOA through integration" is wrong (IMO) as we agreed in our previous discussion already: 'integration by itself does not necessary lead to SOA' - Michael ________________________________ From: JP Morgenthal <[email protected]> To: [email protected] Sent: Monday, January 5, 2009 3:04:26 PM Subject: [service-orientated-architecture] Linthicum's Latest Blog In Dave's latest posting: SOA is architecture with integration (http://weblog. infoworld. com/realworldsoa /archives/ 2009/01/soa_ is_architec. html) he posits that integration is an inherent sub-component of SOA by its nature. "Second, SOA, while also leveraging integration as a sub-pattern -- and integration is a byproduct of SOA -- is really about architecture, or at least it should be. You get to SOA through integration, or more accurately the loose coupling of systems that create and architecture that's easy to change. You can call this agility, changeability, or whatever, but I call it good architecture. Integration indeed has value, don't get me wrong, but the largest value is the ability to get to an SOA, if you ask me. Or, at least to the SOA that's right for your enterprise. " I commented on his blog as follows: "Perhaps the problem is with the word integration more than with the term SOA in this particular case. Integration is clearly overloaded in this case. By their nature services are designed to be chained together in series to form a flow (we exclude the mega-service concept here which usually indicates poor design, in which one service does everything). I don't believe we should be calling this integration any longer. IMHO, integration is about making two disparate systems participate in a larger systematic effort. If you have SOA, you remove this limitation. Your services are designed to work with each other by nature. Hence, we don't have integration, we have orchestration. " I thought it would be interesting to take this debate to this forum where it could be addressed by the larger SOA contingent. I know it's really just all a matter of semantics, because I'm sure there are those among us that would consider orchestration a sub-component of integration. However, for me, the distinction is important because successful SOA should reduce integration requirements and lead to a more interoperable services infrastructure. Thoughts? JP
