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: [email protected]
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
>
