That could be the _worst_ case but the reality that I've seen is that in a Spaghetti world you tend to see a talk to b and c and d and e (etc etc) where as in a managed environment you have a talking to b (which talks to c and d) and to e (which talks to the rest of the alphabet. Taking a managed approach to integration means looking at the secondary effects as first class citizens (if that doesn't sound silly) where as a flat integration approach encourages everyone as equals view of the world.
I don't disagree that it can still get complex but its the mentality shift that I think matters, in one world the view is "talk to anyone" in the other its "talk via these managed elements". So my view is around the switch between an ad-hoc and a governed approach, you don't need technology to make the jump. Steve 2008/7/2 Todd Biske <[EMAIL PROTECTED]>: > First, I personally think the whole m^n complexity thing is a bit of FUD. > Yes, you can create a big, ugly spaghetti bowl and many have. It remains > true, however, that there is still a need for m systems/integration points > to communicate with n systems/integration points. We need to manage those > relationships, and strive to eliminate redundancy across m and n. > I don't agree with the interaction versus integration argument. If there's > no way to interact with a system, it can't be integrated. Now, the > interaction may not be easy, but it's still available. > Typically, I see the term integration used when it's an interaction that > crosses a control boundary. The system I need to talk to is under someone's > else's control (different team, vendor, etc.). That sounds very much the > relationship between a service consumer and a service provider, to me. > A change that needs to occur is that designing for integration needs to be a > primary goal, rather than an after-the-fact goal. There's no reason that > any solution should go live today without documented integration points > (events, service interfaces). They also shouldn't go live without proper > instrumentation and metric collection (separate soap box item on my mind). > Yet this happens probably every single day in corporate IT departments > around the globe. > -tb > Todd Biske > http://www.biske.com/blog/ > Sent from my iPhone > On Jul 2, 2008, at 3:45 AM, Michael Poulin <[EMAIL PROTECTED]> wrote: > > When systems cannot interact with each other but we need them doing this, we > use integration. Thus, are the interaction and integration the same things? > > When I talked about a 3rd party for integration, I meant not a broker but > somebody building the integration (since the parties could not interact on > their own). Looks like this 3-rd party and associated process of building > integration is the major difference between natural interaction and > interaction based on integration. When integration is done and systems > interact, there is no difference (though, in this case, the interaction is > provided by the means that do not belong to neither of the participants). > When an broker is used in the middle, it does not seems to me as an explicit > interaction. > > - Michael > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: service-orientated-architecture@yahoogroups.com > Sent: Wednesday, July 2, 2008 5:09:13 AM > Subject: Re: [service-orientated-architecture] Re: Legacy into SOA (was > Vandersluis on a Data Abstraction Layer's Benefits) > > I actually thought that this was the spaghetti definition of > integration, multiple systems all connecting directly giving and n^n > complexity. > > Its certainly still integration but quite often its the worst form. > > Steve > > 2008/7/1 Todd Biske <[EMAIL PROTECTED] com>: >> Rob wrote, in response to Michael: >> >>> >>>> >>>>> >>>> >>> >>>>> IMO. App A and App B talking to each >>>>> via any number of direct means is still integration. Same goes >>>>> for provider x and provider y. . >>>> >>>> I do not think we reach an agreement in this ever. >>> >>> Not surprising. Not many agree with me on that particular point--it's >>> viewed as too generic a definition of integration. >>> >> I agree with you Rob. I don't think an integration requires having a >> third party involved, that's just one technique. >> -tb >> >> Todd Biske >> http://www.biske. com/blog >> Sent from my iPhone >> > >
