Roy Schulte - application integration

Traditionally one of my favorite Gartner analysts but not the best speaker


Every large company is a virtual enterprise composed of multiple domains

Does not stand alone; with suppliers and outsourcers part of this virtual enterprise

Integration Links across the business units are growing (i.e CIB and Retail Lending)

Justification of expanding investments in application integration

Application integration inspired by business requirement; today continues to grow with Regulatory compliance and B2B

Mergers and acquisitions - single view of the customer

No application is an island; no system runs by itself today

Batch file transfer was good enough for past business integration requirements

Today, business requires real time reconciliation of data and ability to change the process wiring on the fly

Soft wired vs hard wired integration

Cooperating systems provide real time data reconciliation and flow if control; unfortunately you typely couple these systems. You want to loose couple these from an app integration and provide a degree of isolation - competing demands on integration

Graphic posted here sophistication on t axis, x axis is scope of integration -

Four styles of application integration

Vertical axis - communication patter - fully asynchronous , interactive

Horizontal axis - data integration vs. logic integration

Fully asynch, data integration - batch transfer
Asynch, logic integration - multo-process integration - classic BPM - middleware approaches
Interaction, data - composite application data - federated database tool as example
Interaction, logic - SOA

SOA is must valuable in the interaction, logic examples -

Building a SOA application is very different than building a monolithic system; each service is a black box - a monolithic application is the black box

Planning assumption: in 2011, we will have more data redundancy than 2006 based upon business needs, despite the desire to reverse this

Service Oriented Architecture - 1996 can out from Gartner -

A large enterprise will have disparate versions of certain SOA service in multiple business units and application

Trust boundary is typically within a business unit tea; the not invented here syndrome is not solved by SOA. Governance is still in vogue.

Pitching the ESB as the communication backbone for SOA applications

ESB technology vs products is confusing - no convergence on the terms and the product space -

Shows a three layer SOA deployment topology


Expect to have multiple ESBS to operate - a federated integration COE to organize these ESBs - interoperating this together will be a challenge

Half of the companies will unmanaged backbones and no approach across this -

Open sourced ESBs - at least four ESBs - Mule is the largest and oldest - some in production - Sun has one, along with ObjectWeb - Most of them do not have production references - If you are ahead off the curve, could be time

CONCLUSION: Nothing that we do not know - the point on managing ESBs across domains and have manner to ensure that we cross domains is important - His slide deck is worth reading