Enterprise Level Architecture Management Part V: Enterprise

Application Portfolio Management© 2001 Wolfgang W. Keller - all rights reserved

W. Keller1

Enterprise Level Architecture Management

Part V: Enterprise Application Integration (EAI)

Wolfgang Keller, Plattform-Management,Generali Office Service & Consulting AG, Wien

Email: [email protected] http://www.objectarchitects.de/


W. Keller2

Contents• a typical sales line for EAI products• what EAI was intended for• why the sales line is only half the truth• what to do with complex EAI infrastructures

• a pragmatic approach to EAI


W. Keller3

a typical sales line for EAI products


W. Keller4

a typical sales line for EAI products• your bosses want you to integrate legacies in order to

enable rapidly changing business processes on your legacies ...

• every app needs to communicate with every other app• you end up with a max of n2/2 interfaces

• this is to slow and too expensive – you need to buy and EAI tool ..


W. Keller5

a typical sales line for EAI products – hub and spoke

app 1

app ..

app n. app 4

app 2

app 5app 6

app 3

Hub


W. Keller6

a typical sales line for EAI products – hub and spoke• now you have only n interfaces• let the EAI software do the job for you• just buy our product and you don‘t get fired ?


W. Keller7

why the sales line is only half the truth: what EAI was intended for

app 1 app 2 app 3 app 4

Business Process

automating processes over several legaciestherefore it was called Enterprise Application Integration

process activity


W. Keller8

why the sales line is only half the truth – remember multi channel

dial

ogs,

inte

grat

ion,

mid

dlew

are

bank accountmachine

online tradingmachine

property insurancemachine

others ...

web interface

call center interface

sales forceinterface

others ...

clients servers

clear direction


W. Keller9

and in the hub sales story ..

no direction


W. Keller10

why the sales line is only half the truth – remember multi channel• usually not every app needs to talk to every other app• in most cases there are clear servers and there are

also clear „clients“• the clients seldom talk to each other• the servers may talk to each other – this needs to be

„designed“• you need dependency management

• see other tutorials on architecture• you need „commands“

• see command pattern and also


W. Keller11

what‘s cool? how to build your own cheap EAI ...• choosing the middleware• choosing a message format / language• choosing an architecture


W. Keller12

choosing the middlewareeasy pick if you‘re in the financial industry

Market Shares(Source Gartner, simplified)

CICS, MQ

EAI

CORBA

Rest


W. Keller13

choosing a message format / language another easy pick

XMLwhat else?


W. Keller14

MQ series as atransport facility

choosing an architecturenot that trivial ...

softwareserver 1

softwareserver 2

softwareserver 3

softwareserver 4

XML interface layer

a client a client a client

XML Clip

hostboundary


W. Keller15


challenge #1interface normalizations

softwareserver 1

softwareserver 2

softwareserver 3

softwareserver 4

XML interface layer


XML Clip

hostboundary

old host interfaces are not there to give you an easy time accessing them

substantial coding effort needs to be putinto improving interfaces ...


W. Keller16

typical cost situation ..typical cost situation for EAI

20%

80%

ToolInterfaces


W. Keller17


challenge #2commands

softwareserver 1

softwareserver 2

softwareserver 3

softwareserver 4

XML interface layer


XML Clip

hostboundary

often you need to access more than oneexisting „transaction“ on your host server

this implies that you write commands

your interface layer contains elementsof business logic


W. Keller18


challenge #3transaction control

softwareserver 1

softwareserver 2

softwareserver 3

softwareserver 4

UNIX

XML interface layer


XML Clip

hostboundary

if you are using non MVS-host servers together with MVS servers in onetransaction life becomes more complex.

this might indeed call for a more expensivepiece of middleware

but in a bank or insurance such cases arerare ...


W. Keller19

the hub revisited ..• does not help you with the job of normalizing interfaces• also needs a notion of commands if client1 calls clientn

and clientm in one transaction• costs ...


W. Keller20

finally .. some forces• tools productivity / quality• runtime quality / scalability• runtime fit to purpose• support for business processes• integrator (vendor) resources• purchase costs and tco (total cost of ownership)• availability of adapters (clips)


W. Keller21

finally .. some forcesapplied to our „KISS“ solution• tools productivity / quality

• yes: free XML tools and libraries ..• sorry: no interface libraries

• runtime quality / scalability• yes: Java Host

• runtime fit to purpose• yes:


W. Keller22

finally .. some forcesapplied to our „KISS“ solution• support for business processes

• yes: MQSeries Workflow• integrator (vendor) resources

• yes: simple and therefore no special vendor skills required• purchase costs and tco (total cost of ownership)

• yes: cheap• availability of adapters (clips)

• MQSeries on many many platforms ...


W. Keller23

summary• don‘t believe every story a vendor tells you• often you can save a lot of money by exploiting the fact

that your situation is simpler than 100% of all possible cases

Documents

Enterprise Level Architecture Management Part V: Enterprise