+1 -Rob
--- In [email protected], Todd Biske <[EMAIL PROTECTED]> wrote: > > 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
