We've been over that issue before: Yefim Natis's paper begat Loraine Lawson's blog, which begat Joe McKendrick's blog that begat David Linthicum's blog.
Loraine Lawson's blog also begat a very long-winded conversation here on this forum. I prefer we not rehash that. The intent of my post was to discuss the semantic use of integration in Dave's post versus orchestration. JP On Mon, Jan 5, 2009 at 11:37 AM, Michael Poulin <[email protected]> wrote: > "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 > >
