0
`669
`SW 900
`0
`\\\\\\\\\\\\\W\W\W\W\%\\W\\W
`
`SSEHSNOO £0 AHUHBI1
`
`
`
`‘
`
`HP_1020_0001
`
`

`
`.4v
`'
`:7-, .
`_/ \.l T
`,~_
`I
`-\0
`‘,
`.3" 13$’
`'00
`6
`
`N11’
`
`an-"
`.T
`\'
`7+ ’
`'
`I
`\
`
`O0
`
`'
`
`‘
`
`&\
`
`'
`
`.\..,\“|‘“:.-4
`-.\. _—“
`-1
`,
`
`HP_1020_0002
`
`

`
`HP_1020_0003
`
`

`
`Enterprise
`Application
`Integration
`
`DavidS. Linthicum
`
`HP_1020_0004
`
`

`
`HP_1020_0005
`
`HP_1020_0005
`
`

`
`Praise for David Linthicum's Enterprise Application Integration
`
`"David Linthicum has created i:he ultimate EAI primer! EAI tends to be the most
`chaotic of all computing marketplaces, and Dave has done an excellent job of
`identifying, classifying, and clarifying the important issues and directions."
`-]P Morgenthal, CTO, TechSolve, Inc.
`
`"David Linthicum's new book on Enterprise Application Integration is timely,
`complete, and covers critical information. The era of independent and conflicting
`'islands' of data and software that support only local organizations will soon give
`way to a new era of integrated corporate data. Dave's book is a pioneer in this
`new era."
`-Capers Jones, Chairman and Founder, Software Productivity Research
`
`"The definitive guide to EAI. This book offers a wonderful practical collection
`of all the relevant standards and technologies that are applicable to EAI. It covers
`EAI approaches, implementation, and technologies, and in particular, it details
`approaches to integration of packaged applications and the importance of message
`brokers. If you want to learn about how EAI can help you-or you need material
`to explain the business value of EAI within your organization.:_this book is worth
`several books, and it saves searching through thousands of Web pages to find how
`technology can be applied to solve business problems and what are the pluses and
`minuses of different approaches."
`-Ron Zahavi, Vice President, EAI Frameworks Solutions
`
`"This book offers an insightful synthesis of the increasingly vital discipline of
`application integration. In addition to explaining the core principles and techniques
`of the field, the book provides concrete illustrations of how to integrate existing
`· applications and database systems using current and emerging technologies. The
`author's emphasis on message brokers as the strongest solution is right on the
`money, and his inclusion of workflow management technology demonstrates
`unusual insight into this market. If you are trying to connect three or more
`applications in your company, you will find this book highly useful. If you are
`attempting to integrate applications across companies, it's indispensable."
`-David A. Taylor, PhD, CEO, Enterprise Engines Inc.
`
`"Dave's breadth and depth of technical knowledge and expertise offer readers a
`legitimate chanc~ of understanding the problem, and more importantly, of getting
`the correct solution for their environment."
`-Marie A. Lenzi, Editor in Chief, Distributed Object Computing Magazine
`
`HP_1020_0006
`
`

`
`Addison-Wesley Information Technology Series
`Capers Jones, Series Editor
`
`The information technology (IT) industry is in the public eye now more than ever
`before because of a number of major issues in which software technology ,and
`national policies are closely related. As the use of software expands, there is a
`continuing need for business and software professionals to stay current with the
`state of the art in software methodologies and technologies. The goal of the
`Addison-Wesley Information Technology Series is to cover any and all topics
`that affect the IT community: These books illustrate and explore how information
`technology can be aligned with business practices to achieve business goals and
`support business imperatives. Addison-Wesley has created this innovative series
`to empower you with the benefits of the industry experts' experience.
`
`For more information point your browser to
`http:/ /www.awl.com/ cseng/ series/it/
`
`Wayne Applehans, Alden Globe, and Greg Laugero, Managing Knowledge:
`A Practical Web-Based Approach. ISBN: 0-201-43315-X
`
`Gregory C. Dennis and James R. Rubin, Mission-Critical Java™ Project Management:
`Business Strategies, Applications, and Development. ISBN: 0-201-32573-X
`
`Kevin Dick, XML: A Manager's Guide. ISBN: 0-201-43335-4
`
`Jill Dyche, e-Data: Turning Data into Information with Data Warehousing.
`ISBN: 0-201-65780-5
`
`Capers Jones, The Year 2000 Software Problem: Quantifying the Costs and
`Assessing the Consequences. ISB~: 0-201-30964-5
`
`Ravi Kalakota and Marcia Robinson, e-Business: Roadmap for Success.
`ISBN: 0-201-60480-9
`
`David Linthicum, Enterprise Application Integration.
`ISBN: 0-201-61583-5
`
`Sergio Lozinsky, Enterprise-Wide Software Solutions: Integration Strategies
`·
`and Practices. ISBN: 0-201-30971-8
`
`Patrick O'Beirne, Managing the Euro in Information Systems: Strategies
`for Successful Changeover. ISBN: 0-201-60482-5
`
`Bill Wiley, Essential System Requirements: A Practical Guide to
`Event-Driven Methods. ISBN: 0-201-61606-8
`
`HP_1020_0007
`
`

`
`nterprise
`Ap lication
`Integration
`
`David s. linthicum
`
`-~·
`
`A.
`TT
`Addison ... wesley
`An imprint of Addison Wesley Longman, Inc.
`Reading, Massachusetts • Harlow, England • Menlo Park,
`California • Berkeley, California • Dou Mills, Ontario •
`Sydney • Bonn ·Amsterdam • Tokyo • Mexico City
`
`HP_1020_0008
`
`

`
`Many of the designations used by manufacturers and sellers to distinguish their
`products are claimed as trademarks. Where those designations appear in this
`book, and Addison Wesley Longman Inc. was aware of a tradem~;~.rk claim, the
`designations have been printed in initial capital letters or in all capitals.
`
`The author and publisher have taken care in the preparation of this book, but
`make no expressed or implied warranty of any kind and assume no responsibil(cid:173)
`ity for errors or omissions. No liability is assumed for incidental or consequen(cid:173)
`tial damages in connection with or arising out of the use of the information or
`programs contained herein.
`
`The publisher offers discounts on this book when ordered in quantity for spe(cid:173)
`cial sales. For more information, please contact:
`
`AWL Direct Sales
`Addison Wesley Longman, Inc.
`One Jacob Way
`Reading, Massachusetts 01867
`(781) 944-3700
`
`VisitAW on the Web: www.awl.com/eseng/
`
`Library of Congress Cataloging-in-Publication Data
`
`l1
`L
`
`0
`
`,J
`J
`
`;,.
`'I
`
`\
`
`C'~
`'
`
`Linthicum, DavidS., 1962-
`Enterprise application integration I DavidS. Linthicum.
`p. cm.-(Addison-Wesley information technology series)
`Includes bibliographical references.
`ISBN 0-201-61583-5
`1. Application software-Development. 2. Business enterprise-Data
`I. Title.
`processing.
`QA76.76.A65 L56 2000
`005.1-dc21
`
`99-046633
`
`Copyright © 2000 Addison Wesley Longman
`
`All rights reserved. No part of this publication may be reproduced, stored in a
`retrieval system, or transmitted, in any form, or by any means, electronic,
`mechanical, photocopying, recording, or otherwise, without the prior consent
`of the publisher. Printed in the United States of America. Published simultane(cid:173)
`ously in Canada.
`
`ISBN 0-201-61583-5
`Text printed on recycled paper
`1 2 3 4 5 6 7 8 9 10- MA- 0302010099
`First printing, November 1999
`
`HP_1020_0009
`
`

`
`For my family. Thanks for everything.
`
`HP_1020_0010
`
`

`
`HP_1020_0011
`
`HP_1020_0011
`
`

`
`Contents
`
`Acknowledgments xvn
`
`DEFINING EAI
`
`1
`
`What Is EAI? 3
`Applying Technology 4
`How Did Things Get This Bad? 6
`. Chaos Today, Order Tomorrow 8
`Evolution of Stovepipes 11
`Traditional Systems 12
`Microcomputer Systems 13
`Distributed Systems 13
`Packaged Applications 13
`Making the Business Case for EAI 14
`The Virtual System 15
`e-Business 17
`Types ofEAI 18
`Middleware and EAI 20
`
`DATA·lEVE L EAI
`
`23
`
`Going for the Data 24
`Data-LevelEAibyExample 27
`Database-to-Database EAI 28
`Federated Database EAI 29
`Consider the Data Source 30
`Relational Data 30
`Object-Oriented 33
`Multidimensional 33
`Other Data Storage Models 3 5
`Working with Data-Level EAI 36
`
`HP_1020_0012
`
`

`
`viii
`
`Contents
`
`APPLICATION INTERFACE=LEVEL
`EAI
`37
`
`Application Interfaces 38
`What's an API? 39
`Interface by Example 40
`Approaching Application Interfaces 42
`The Interface Tradeoff 42
`Packaged Applications 43
`Packaged Application Technology Architecture 44
`Packaged Application APis 47
`Other Interfaces 53
`Custom Applications 57
`Rolling Your OwnAPI 57
`Application Wrapping 57
`Using Application Interfaces 60
`
`METHOD-LEVEL EAI
`
`61
`
`Method-Level Example 63
`What's a Process? 64
`Scenarios 64
`Rules 64
`Logic 65
`Data 66
`Objects 66
`Method Warehousing 66
`Leveraging Frameworks for EAI 67
`The Value of Frameworks 69
`Framework Functionality 70
`Framework Types 72
`Framework Categories 7 5
`Enabling Technology 75
`Application or Transaction Servers 75
`Message Brokerss 7 6
`Distributed Objects 76
`Sharing Methods to Bind Your Enterprise 77
`
`HP_1020_0013
`
`

`
`Contents
`
`ix
`
`US E R I NT E R FACE-lEVEl E A I
`
`79
`
`Leveraging User Interface-Level EAI 80
`Going to the User Interface 80
`Understanding the Application 82
`Creating the Screen Catalog 83
`Mapping Screens 84
`Approaches 85
`Enabling Technology 87
`
`(
`
`THE EAI PROCESS-METHODOlOGY OR
`MADNESS?
`91
`
`Applying a Procedure/Methodology 92
`Step 1: Understanding the Enterprise and Problem Domain 93
`Step 2: Making Sense of the Data 93
`Identifying the Data 94
`Step 3: Making Sense of the Processes 104
`Process Integration 104
`The Common Business Model 106
`Leveraging Patterns for Method-Level EAI 108
`Step 4: Identifying Application Interfaces 112
`Application Interface Directory 113
`Step 5: Identifying the Business Events 114
`Step 6: Identifying the Schema and Content Transformation Scenarios 114
`Step 7: Mapping Information Movement 115
`Step 8:ApplyingTechnology 115
`Step 9: Testing, Testing, Testing 116
`Step 10: Considering Performance 116
`Step 11: Defining the Value 117
`Step 12: Creating Maintenance Procedures 117
`Method or Madness? 118
`
`AN INTRODUCTION TO EAI AND
`M I D D lEW ARE
`119
`
`Middleware: The Engine of EAI 119
`What's Middleware? 120
`Types of Middleware 120
`
`HP_1020_0014
`
`

`
`X
`
`Contents
`
`Middleware Models 132
`One-to-One versus Many-to-Many 132
`Synchronous versus Asynchronous 135
`Connection-Oriented and Connectionless 137
`Direct Communications 13 7
`Queued Communications 13 7
`Publish/Subscribe 137
`Request Response 138
`Fire and Forget 138
`Conversational-Mode 139
`Tough Choices 139
`
`TRANSACTIONAL MIDDLEWARE
`AND EAI
`141
`
`Notion of a Transaction 143
`The ACID Test 144
`Scalable Development 145
`Database Multiplexing 146
`Load Balancing 146
`Fault Tolerance 147
`Communications 148
`XA and X/ Open 148
`Building Transactions 149
`Application Servers 149
`Evolving Transactions 151
`Future of Transactional Middleware 160
`
`RPCS, MESSAGING,
`AND EAI
`163
`
`RPCs 164
`DCE 165
`Message-Oriented Middleware (MOM) 166
`MSMQ 168
`IBM MQSeries 170
`Getting the Message 17 5
`
`HP_1020_0015
`
`

`
`Contents
`
`xi
`
`DISTRIBUTED OBJECTS
`AND EAI
`177
`
`What Works 178
`What's So Difficult? 179
`What's So Easy? 180
`What's a Distributed Object? 181
`The General Idea 182
`COREA 183
`Shortfalls 183
`COREA Internals 184
`COM 186
`OLEAutomation 186
`Moving to DCOM 188
`The Realities 189
`
`DATABASE-ORIENTED MIDDLEWARE
`AND EAI
`191
`
`What's Database-Oriented Middleware? 193
`Types of Database-Oriented Middleware 195
`ODEC 196
`]DEC 198
`OLEDE 203
`Going Native 205
`Databasg Gateways 205
`Ready for Prime Time 207
`
`JAVA MIDDLEWARE AND EAI
`
`209
`
`Categories of Java Middleware Standards 210
`Database-Oriented 210
`Interprocess 210
`Message Oriented 211
`Application-Hosting 216
`Distributed Objects 218
`The Future of Java and Middleware 220
`
`HP_1020_0016
`
`

`
`xii
`
`Contents
`
`IMPLEMENTING A.N D INTEG RATING
`PACKAGED APPLICATIONS-THE
`GENERAL IDEA
`221
`
`Why Packaged Applications? 222
`Installing Packaged Applications 224
`Business Drivers 224
`Architectures Drive Success 225
`Testing What Has Already Been
`Tested 226
`Implementing Specific Packages 227
`Packaged Application Tools 229
`Database Issues 230
`Web Enablement 231
`The Opportunity 233
`·web-Enabled Selling and EAI 233
`Integrating the Supply Chain 234
`Applying EAI to Packaged Applications 236
`Our Packaged Future 239
`
`INTEGRATING
`SAP R/3
`241
`
`The Basic Problem 242
`SAP Architecture 244
`The SAP Repository 245
`The SAP Presentation Layer 245
`The SAP Application Server Layer 245
`The SAP Database Layer 245
`SAP Middleware 246
`ALE 249
`IDOC 251
`BAPI 252
`Using the Repository 253
`SAP and EAI 254
`
`HP_1020_0017
`
`

`
`Contents
`
`xiii
`
`INTEGRATING PEOPLESO FT
`
`255
`
`PeopleS oft Architecture 256
`Data Level 258
`Data Mover 258
`SQRs and Moving Data 259
`Workflow and Moving Data 259
`Application Interfaces 260
`Screen Scraping 261
`EDI 261
`Workflow 262
`Workstation 263
`What's Best? 265
`
`SUPPLY CHAIN INTEGRATION:
`INTER .. ENTERPRISE APPLICATION
`I NT E G RAT I 0 N
`267
`
`Defining Your Supply Chain 268
`Extending EAI outside the Enterprise 270
`Binding the Home System to a Stranger's 271
`The Process 2 72
`Supply Chain Technology 27 4
`ERPs and the Supply Chain 2 7 6
`Supply Chains Organize 276
`
`XML AND EAI
`
`279
`
`The Rise of XML 2 79
`What'sXML? 281
`Data Structures 281
`DTDs 282
`XML Parsers 283
`XML Metadata 283
`XML and Middleware 284
`Persistent XML 286
`
`HP_1020_0018
`
`

`
`xiv
`
`Contents
`
`RDF and EAI 286
`XSL and EAI 287
`XMLandEAI 288
`
`MESSAGE BROKERS-THE PREFERRED
`E A I EN G I N E
`291
`
`Integration, not Perspiration 292
`Why a New Direction? 293
`Considering the Source (and Target) 296
`Message Translation Layer 297
`Schema Conversions 298
`Data Conversion 300
`Intelligent Routing 301
`Rules Processing 302
`Message Warehousing 304
`Repository Services 305
`Graphical User Interface 307
`Directory Services 308
`Management 309
`Adapters 309
`Thin Adapters 310
`Thick Adapters 311
`Static and Dynamic Adapters 313
`Using an API 314
`·Topologies 314
`The Future of EAI and Brokers 316
`
`PROCESS AUTOMATION
`AND EAI
`319
`
`What Is Process Automation? 320
`Process Automation and EAI Levels 324
`Implementing Process Automation 325
`Documenting Processes 326
`Defining Processes 326
`Executing Processes 326
`Tools and Approaches 327
`
`HP_1020_0019
`
`

`
`Contents
`
`XV
`
`Workflow Standards 330
`Process Automation and EAI 330
`
`EAI MOVING FORWARD
`
`333
`
`Problem Domains Change 334
`Moving from Intra- to Inter-Enterprise Application Integration 334
`Moving from Data-Level to Application-Level Integration 335
`Loose Ends 336
`Vendor Approaches 338
`Data-Oriented 339
`Application Integration-Oriented 341
`Process Automation-Oriented 343
`Transaction-Oriented 344
`Distributed Object-Oriented 344
`Technologies Join Forces 345
`Future Directions 347
`Importance of the Architecture 347
`Importance of Application Design 348
`EAI and the Modern Enterprise 349
`
`Glossary 3 51
`Bibliography 361
`Index 367
`
`HP_1020_0020
`
`

`
`HP_1020_0021
`
`HP_1020_0021
`
`

`
`Defining EAI
`
`"They have computers, and they may have other
`weapons of mass destruction.:'
`-Janet Reno, Attorney General,
`February 2, 1998
`
`s corporate dependence on technology has grown
`more complex and far reaching, the need for a
`method of integrating disparate applications into a uni(cid:173)
`fied set of business processes has emerged as a priority.
`After creating islands of automation through genera(cid:173)
`tions of technology, users and business managers are
`demanding that seamless bridges be built to join them.
`In effect, they are demanding that ways be found! to
`bind! these applications into a single, unified! enterprise
`application. The development of Enterprise Application
`Integration (EAI), which allows many of the stovepipe
`applications that exist today to share both processes and
`data, allows us to finally answer this demand.
`
`Interest in EAI is driven by a number of important fac(cid:173)
`tors. With the pressures of a competitive business environ(cid:173)
`ment moving IT management to shorter application life
`cycles, financial prudence demands that IT managers learn to
`use existing databases and application services rather than
`recreate the same business processes and data repositories
`over and over (see Figure 1.1). Ultimately, finances are a prime
`concern. The integration of applications to save precious
`
`1
`
`HP_1020_0022
`
`

`
`HP_1020_0023
`
`HP_1020_0023
`
`

`
`HP_1020_0024
`
`HP_1020_0024
`
`

`
`;;::#fJ!i:&'=y J!ffi""';_"'~- $
`
`:
`
`#~ "' ,)tC;;~
`
`~
`
`X
`
`""'
`
`'"\d!
`
`rJi,;;""'cc"'y«"
`
`"'"' ~P0,i' ::~: "'~~"':" :' :;;;""
`
`" ~
`
`"
`
`"'~"'
`
`~ ~fr! "s£~:.;_~7j,'\0~ ;;;,'!!!:J!;"'::Sc?'" ;;o.SC"" :;::~::z:~$:-:;;~"'d]I'- e "'~A "W
`~ ~r II g'e m ,B II "II N B "
`~
`- ~
`
`¥_j;wj"'
`
`~
`
`~ 'S
`
`""
`
`""""'
`
`~'"
`
`""'"'; $
`
`Defining EAI
`
`"They have computers, and they may have other
`weapons of mass destruction.:'
`-Janet Reno, Attorney General,
`February 2, 1998
`
`s corporate dependence on technology has grown
`more complex and far reaching, the need for a
`method of integrating disparate applications into a uni(cid:173)
`fied set of business processes has emerged as a priority.
`After creating islands of automation through genera(cid:173)
`tions of technology, users and business managers are
`demanding that seamless bridges be built to join them.
`In effect, they are demanding that ways be found to
`bind these applications into a single, unified enterprise
`application. The development of Enterprise Application
`Integration (EAI), which allows many of the stovepipe
`applications that exist today to share both processes and
`data, allows us to finally answer this demand.
`
`Interest in EAI is driven by a number of important fac(cid:173)
`tors. With the pressures of a competitive business environ(cid:173)
`ment moving IT management to shorter application life
`cycles, financial prudence demands that IT managers learn to
`use existing databases and application services rather than
`recreate the same business processes and data repositories
`over and over (see Figure 1.1). Ultimately, finances are a prime
`concern. The integration of applications to save precious
`
`HP_1020_0025
`
`

`
`2
`
`Defining EAI
`
`development dollars creates a competitive edge for corporations who share appli(cid:173)
`cation information either within the corporation or with trading partners.
`The vast majority of corporations use several generations of systems that
`rely on a broad range of enabling technology developed over many years.
`Mainframes, UNIX servers, NT servers, and even proprietary platforms whose
`names have been forgotten, constitute the technological base for most enter(cid:173)
`prises. These technologies, new and old, are all providing some value in the
`enterprise, but their value is diminished if they are unable to leverage other
`enterprise applications. Moreover, the need to integrate those systems with pack(cid:173)
`aged systems has been intensified by the popularity of packaged applications
`such as SAP, PeopleSoft, and Baan.
`The case for EAI is clear and easy to define. Accomplishing EAI, however,
`is not.
`The idea of EAI is something we've been wrestling with over the last several
`years as the need for a comprehensive integration system has grown more urgent.
`Forester Research esti~ates that up to 35 percent of development time is devoted
`to creating interfaces and points of integration for applications and data sources.
`Most problems_ with developing software derive from attempts to integrate it
`with existing systems. Certainly that has been a significant problem in creating
`traditional client/server systems-what was inexpensive to build was expensive
`to integrate and became difficult to maintain.
`
`Expand Supplier and
`Customer
`Relationships
`18%
`
`Move Information
`Beyond Traditional
`Confines
`20%
`
`Integrate a
`Best-of-Breed
`World
`14%
`
`Mergers and
`Acquisitions
`10%
`
`Get New Applications
`into Production Quickly
`38%
`
`Source: Aberdeen Group, October 1998
`
`Figure 1.1 The need for application integration
`
`HP_1020_0026
`
`

`
`What Is EAI?
`
`What Is EAI?
`
`3
`
`So, if EAI is the solution, what exactly is it? EAI is not simply a buzzword
`dreamed up by the press and analyst community. It is, at its foundation, a
`response to decades of creating distributed monolithic, single-purpose applica(cid:173)
`tions leveraging a hodgepodge of platforms and development approaches. EAI
`represents the solution to a problem that has existed since applications first
`moved from central processors. Put briefly, EAI is the unrestricted sharing of
`data and business processes among any connected applications and data sources
`in the enterprise.
`The demand of the enterprise is to share data and processes without having
`to make sweeping changes to the applications or data structures (see Figure 1.2).
`Only by creating a method of accomplishing this integration can EAI be both
`functional and cost effective.
`Now that you know what it is, the value of EAI should be obvious. EAI
`is the solution to the unanticipated outcome of generations of development
`
`1998 Annual Revenue
`
`2000 Annual Revenue
`(Estimated)
`
`1000
`
`900
`aoo
`"' 700
`s:: g 600
`~ 500
`UT 40'0
`
`- 300
`
`200
`
`100
`
`0
`
`~
`0
`u:
`"'
`"'
`...
`
`Q)
`0
`0
`IJ,.
`
`c:
`0
`:;::;
`...
`co
`Cl
`.e!
`E
`l1l
`'tii
`0
`
`....
`...
`Q)
`"'
`0
`·.:
`a.
`e-1/)
`"'
`s::
`Q) Q)
`l1l
`1: "' F
`UJ ~
`l1l
`Q) e
`"0()
`'tii
`-gc..
`0
`Q)
`~
`UJ
`
`1000
`
`900
`
`800
`
`700
`
`"'
`s::
`~ 600
`~ 500
`UT
`400
`
`300
`
`200
`
`100
`
`0
`
`Q) "' ·.: e-1/)
`Q) Q)
`"""'
`s:: "'
`UJ Q)
`Q) e
`"0()
`-gc..
`Q)
`~
`UJ
`
`~ u:
`"' "' Q)
`0 ...
`
`0
`
`IJ,.
`
`Figure 1.2 The technology that drives EAI is growing quickly.
`
`·
`
`Source: Aberdeen Group, December 1998
`
`HP_1020_0027
`
`

`
`4
`
`Defining EAI
`
`undertaken without a central vision or strategy. For generations, systems have
`been built that have served a single purpose for a single set of users without
`sufficient thought to integrating these systems into larger systems and multiple
`applications.
`Undoubtedly, a number of stovepipe systems are in your enterprise-for
`example, inventory ·control, sales automation, general ledger, and human
`resource systems. These systems typically were custom built with your specific
`needs in mind, utilizing the technology-of-the-day. Many used nonstandard data
`storage and application development technology.
`While the technology has aged, the value of the applications to your enter(cid:173)
`prise likely remains fresh. Indeed, that "ancient" technology has probably
`remained critical to the workings of your enterprise. Unfortunately, many of
`these business-critical systems are difficult to adapt to allow them to communi(cid:173)
`cate and share information with other, more advanced systems. While there
`always exists the option of replacing these older systems, the cost of doing so is
`generally prohibitive.
`Packaged applications such as SAP, Baan, and PeopleSoft-which are natural
`stovepipes themselves-have only compounded the problem. Sharing informa(cid:173)
`tion among these systems is particularly difficult because many of them were not
`designed to access anything outside their own proprietary technology.
`
`Applying Technology
`
`If EAI articulates the problem, then traditional middleware has sought to articu(cid:173)
`late the solution-sort of. Traditional middleware addresses the EAI problem in
`a limited manner.
`The primary limitation is that middleware that uses message queuing or
`remote procedure calls (RPCs) only provides point-to-point solutions-that is,
`linkage between system A and system B. Unfortunately, any attempt to link addi(cid:173)
`tional systems quickly becomes a complex tangle of middleware links. Worse still,
`traditional middleware demands significant alterations to the source and target
`systems, embedding the middleware layer into the application or data store.
`For example, when integrating a custom accounting system running on
`Windows 2000 with a custom inventory control system running on the main(cid:173)
`frame, you may select a message-queuing middleware product to allow both sys(cid:173)
`tems to share information. In doing so, however, you generally have to alter the
`source system (where the information is coming from) with the target system
`
`HP_1020_0028
`
`

`
`Applying Technology
`
`5
`
`(where the information is going to) in order to make use of the middleware. This
`is due to the fact that the point-to-point middleware layer only provides a pro(cid:173)
`gram interface, and thus the programs must change to accommodate the middle(cid:173)
`ware. This is costly and sometimes risky.
`What's more, as we use the same or similar technology, as with the previous
`example, to integrate other applications inside an enterprise, the number of
`point-to-point solutions may grow to accommodate information movement
`between various systems. The end result is software pipes running in and out of
`existing enterprise systems, with no central control and central management, and
`a limited ability to react to change. The end state looks more like an ill-planned
`highway system that was built by many small integration projects but with little
`strategic value.
`An additional complication to this scenario is that IT ~anagers must per(cid:173)
`form integration projects inside fluid environments using rapidly advancing
`technology. In seeking to integrate links, the manager may also encounter addi(cid:173)
`tional problems such as:
`
`• A variety of legacy systems that contain mission-critical applications
`• Several packaged applications with both proprietary and open frameworks
`• A hodgepodge of hardware and operating system platforms
`• A hodgepodge of communication protocols and networking equipment
`• Geographically disbursed applications and databases
`
`In adQ_ition to these structural limitations, the economics of traditional middle(cid:173)
`ware have placed EAI out of the reach of most IT organizations. Even a simple
`dual-application linking is financially daunting, running as high as $10 million
`according to the Aberdeen Group.
`Given these significant limitations, it follows that EAI represents a very dif(cid:173)
`ferent method of application integration than that using traditional middleware
`(see Figure 1.3). EAI provides a set of integration-level application semantics. Put
`another way, EAI creates a common way for both business processes and data to
`speak to one another across applications. More importantly, we approach this
`old problem with a new set of technologies designed specifically for EAI.
`So, keeping this information in mind, we can focus on the following differ(cid:173)
`ences between traditional approaches and the vision of EAI:
`
`• EAI focuses on the integration of both business-level processes and data,
`whereas the traditional middleware approach is data oriented.
`
`HP_1020_0029
`
`

`
`6
`
`Defining EAI
`
`Enterprise ~
`!!
`Application
`Integration
`
`1. Application Independent
`2. Business Process Oriented
`3. Configurable across
`Applications
`4. Automated Deployment
`
`Traditional ~
`Middleware ~
`
`1. Application Dependent
`2. Technology Dependent
`3. limited Business Process
`Visibility
`4. Static Implementations
`
`Source: Aberdeen Group, October 1998
`
`Object Request
`Brokers
`
`''')':~ :?"\ ,,.,
`
`Transaction
`Monitors
`<•,•:.· • .. / ...
`
`. Messaging
`
`RDBM s
`
`r-'··
`
`.:c•
`
`Figure 1.3 EAI versus traditional middleware
`
`• EAI includes the notion of reuse as well as distribution of business processes
`and data.
`• EAI allows users who understand very little about the details of the applica(cid:173)
`tions to integrate the applications.
`
`How Did Things Get This Bad?
`
`EAI answers the problem of integrating systems and applications. But how did
`the problem come about? The answer depends to a great extent on perspective.
`In the early days of computing, information was processed on centralized plat(cid:173)
`forms. As a result, process and data existed in a homogeneous environment.
`Integrating applications (both processes and data) within the same machine
`rarely created a problem beyond some additional coding. As technology devel(cid:173)
`oped, platforms changed. Smaller and more open platforms, including UNIX
`and Windows NT (in addition to new programming paradigms such as object-
`
`HP_1020_0030
`
`

`
`How Did Things Get This Bad?
`
`7
`
`oriented and component-based development), challenged traditional roam(cid:173)
`frames, once the backbone of IT.
`Whether correctly or not, traditional IT leveraged the ·power of these newer,
`more open platforms. A number of factors contributed to this. Users wanted
`applications that were driven by newer and more attractive graphical user inter(cid:173)
`faces. Misreading or ignoring this desire, traditional legacy systems lagged in
`adopting "user-friendly" graphical user interfaces, abandoning the field to the
`newer platforms. Perhaps more importantly, the press trumpeted the claim that
`the cost of applying and maintaining the newer platforms was less than tradi(cid:173)
`tional systems. Sometimes this claim was correct. Often it was not.
`In the rush to incorporate these new systems, most enterprises applied mini(cid:173)
`mal architectural foresight to the selection of platforms and applications. IT
`managers made many of their decisions based on their perception of the current
`technology market. For example, when the UNIX platforms were popular in the
`early 1990s, UNIX was placed in many enterprises, regardless of how well it fit.
`Today, the same is true ofWindows NT.
`Clearly, the installation of these systems has been a textbook example of
`"management-by-magazine." Rather than making sound, business-driven deci(cid:173)
`sions, or evaluating all possible solutions, decisions were made to implement the
`"coolest" technology.
`While acknowledging that smaller and more open systems·can hold a very
`important place in the enterprise, this decision-making process lacked the per(cid:173)
`spective and foresight that might have minimized, or possibly avoided, many
`integration problems. The success of these smaller, more open systems was that
`they met the requirement of commodity computing but with a steep price-the
`need for integration with the existing, older system.
`The need for EAI is the direct result of this architectural foresight, or rather,
`the lack of it. Until recently, architecture at the enterprise level had been virtually
`nonexistent. Information technology decisions tended to be made at the depart(cid:173)
`ment level, with each department selecting technology and solutions around its
`own needs and belief structures. For example, accounting may have built their
`information systems around a mainframe, while human resources leveraged the
`power of distributed objects, and research and development might have used dis(cid:173)
`tributed transaction processing technology. The end result could have been a
`mixing and matching of technologies and paradigms. As a result, the enterprise
`as a whole was left with a "system" that is nearly impossible to integrate without
`fundamental re-architecture-and a significant investment of precious funds.
`
`HP_1020_0031
`
`

`
`8
`
`Defining EAI
`
`To address the problem of architectural foresight, many organizations have
`created the role of the enterprise architect. This person or office is responsible for
`overseeing a centralized architecture and making sure that technology and solu(cid:173)
`tions selected for the enterprise are functionally able to interact well with one
`another. As a result, departments will be able to share processes and data with a
`minimum of additional work.
`Enterprise architects will be called upon to make some unpopular decisions.
`They will be charged with making decisions regarding the commitment to a sin(cid:173)
`gle programming paradigm and technology religion. If the enterprise goes to dis(cid:173)
`-tributed objects, it must do so as a unified whole. Tough, centralized decisions
`must be made. The idea of selecting technology for technology's sake is today a
`proposition that is simply too expensive. Corporate America is finally shutting
`down the playground that was once information technology.
`
`Chaos Today, Order Tomorrow
`
`- The establishment of enterprise architects is a significant and positive develop(cid:173)
`ment. Often, in addition to developing a central long-term strategy for the future,
`the role of the architect is to coordinate the technology that is already in place.
`Most enterprises leverage many different technologies. The integ.ration of
`these technologies is almost always a difficult and chaotic pr~position. Traditional
`middleware technology, such as message-queuing software, ties applications
`together, but these "point-to-point" solutions create single links between many
`applications, as we mentioned previously. As a r