- Shopping Bag ( 0 items )
Application integration assembles methods and tools for organizing exchanges between applications, and intra- and inter-enterprise business processes. A strategic tool for enterprises, it introduces genuine reactivity into information systems facing business changes, and as a result, provides a significant edge in optimizing costs.
This book analyzes various aspects of application integration, providing a guide to the alphabet soup behind EAI, A2A, B2B, BAM, BPM, ESB and SOA. It addresses the problems of choosing between the application integration solutions and deploying them successfully. It supplies guidelines for avoiding common errors, exploring the differences between received wisdom and the facts on the ground. The overview of IT urbanization will help introduce English-speaking audiences to a powerful approach to information system flexibility developed in France. A key chapter approaches the analysis and interoperation of service levels in integration projects, while the discussion on deployment methodologies and ROI calculation anchors the theory in the real world.
Application Integration: EAI, B2B, BPM and SOA relies on concrete examples and genuine experiences to demonstrate what works – and what doesn’t – in this challenging, topical and important IT domain.
Chapter 1. Introduction.
Chapter 2. What is Application Integration?
2.1. The economy: the “engine” of integration.
2.2. The history and the issues of application integration.
2.3. Consequences for IT.
2.4. Integration typologies.
2.4.1. Classifying the integration problem types.
2.4.2. Classifying the applications.
2.5. EAI: Integrating enterprise applications (A2A).
2.5.1. Accounting interpretation: EAI precursor.
2.5.2. EAI today.
2.6. Integrating inter-enterprise exchanges (B2B).
2.7. Coupling A2A and B2B: A2B (or Business Collaboration).
2.8. Managing business processes (BPM).
2.9. Service-oriented architectures (SOA).
Chapter 3. Levels in Integration Services.
3.1. Transport and connectivity.
3.1.1. Defining partners.
3.1.2. Data transport.
3.1.4. Supervising transport.
3.2. Adapting the information.
3.2.4. Defining the rules.
3.2.5. Supervising exchanges.
3.3. Automating business processes.
3.3.1. Modeling business processes.
3.3.2. Executing business processes.
3.3.3. Supervising business processes.
3.4. Business process and integration: mediation and exchange.
3.4.1. Business process level and integration level.
3.4.2. Mediation process sub-level.
3.4.3. Exchange process sub-level.
3.4.4. Interaction between the sub-levels.
3.4.5. Interaction between integration and business process (BPM).
3.5. Choosing the exchange architecture.
3.5.1. Synchronous/asynchronous communication.
3.5.2. Architecture: centralized or distributed?
Chapter 4. Types of Integration Projects.
4.1. Integrating a single application.
4.1.1. Exchange cartography.
4.1.2. The integration platform.
4.2. IT infrastructure projects.
4.2.1. Urbanization of information systems.
4.2.2. IT exchange infrastructure.
4.3. Integrating inter-enterprise exchanges.
4.3.1. Exchanging electronic documents (EDI).
4.3.2. XML standards.
4.3.3. Inter-enterprise “spaghetti” system.
4.3.4. Inter-enterprise exchange platforms.
4.3.5. “Single Window” initiatives.
4.4. Managing business processes.
4.4.1. Points of departure.
4.4.2. BPM project opportunity: choosing the processes.
4.4.3. The “top-down” approach.
4.4.4. Expected results.
4.5. Implementing a service architecture.
4.5.1. Characteristics of an SOA.
4.5.2. Elements of an SOA infrastructure.
4.5.3. Applicable norms and standards.
Chapter 5. Application Integration Tools.
5.2. Application servers.
5.3. Enterprise Service Bus (ESB).
5.4. BPM tools.
Chapter 6. Understanding Integration Failures.
6.1. High failure rates.
6.2. The technological approach.
6.2.1. New technology or new packaging?
6.2.2. Technology confronts reality.
Chapter 7. Integration Myths.
7.1. The mirage of the single tool.
7.1.1. A conservative choice: example and consequences.
7.1.2. “Modern” architectural choice: example and consequences.
7.2. XML: miracle format.
7.3. Business adapters: simplifying the implementation.
7.3.1. Business adapter: implementation – maintenance – problem.
7.3.2. By way of a conclusion on business adapters.
7.4. Java: the proof of a modern solution.
7.4.1. The real reason for Java.
7.4.2. Limitations of an all-Java integration solution.
7.5. Files: the “poor cousins” of application integration.
7.6. Process and services are everything.
7.6.1. BPM and SOA: top-down approach – from business to IT.
7.6.2. EAI and B2B: bottom-up approach – from IT to business.
7.6.3. Complementary approaches.
Chapter 8. Integration and IT Urbanization.
8.1. IT urbanization review.
8.2. Limits of urbanization without an integration solution.
8.3. How do integration solutions support IT urbanization?
8.4. Limits of integration solutions without IT urbanization.
8.5. How does IT urbanization support integration solutions?
8.6. The need to correlate integration solutions and urbanization.
Chapter 9. Choosing an Application Integration Solution.
9.1. General approach.
9.2. Methodology for calculating return on investment (ROI).
9.2.1. Introduction to the method.
9.2.2. Equations: maintaining the language of integration.
9.2.3. Operational workload gains through centralized supervision.
9.2.4. Quality of service improvements.
9.3. Opportunity study.
9.3.1. Analyzing the real needs of the enterprise.
9.3.2. Real needs and the “state of the art”.
9.3.3. Identifying possible business benefits.
9.4. Go/NoGo from General Management.
9.5. The search for a candidate: Request for Information (RFI).
9.5.1. Why issue an RFI?
9.5.2. Key points in an integration RFI.
9.6. Request for Proposal (RFP) or specifications document.
9.6.1. Interest and spirit of an RFP.
9.6.2. Myths: standard questionnaire + one-stop supplier.
9.6.3. Key points in an RFP for application integration.
9.7. Presentations from the candidates.
Chapter 10. Deployment Methodology.
10.1. Introduction to the method.
10.2. Deployment methodology: general principles.
10.3. Special case: deploying BPM and SOA.
10.4. Economic models of cost allocation.
10.4.1. Cost allocation linked to usage.
10.4.2. Cost allocation linked to usage and services (developed model).
Chapter 11. Operational Examples of Implementation.
11.1. Rationalizing bonds purchase order management (banking).
11.1.1. The context.
11.1.2. The choices.
11.1.3. The solution.
11.1.4. The results.
11.2. An EAI hub (telecommunications).
11.2.1. The context.
11.2.2. The choice.
11.2.3. Implementing the pilot: first difficulties.
11.2.4. Integration tests: disturbing results.
11.2.5. How did we end up here? Consequences of architectural choices.
11.2.6. Performance tests: catastrophic results.
11.2.7. Report card: final decision.
11.2.8. The lesson: what we could have done.
11.3. A2A and B2B (retail).
11.3.1. The context.
11.3.2. The choice.
11.3.3. The solution.
11.3.4. The results.
11.4. BPM and SOA in service delivery.
11.4.1. The context.
11.4.2. The choice.
11.4.3. The solutions.
11.4.4. The results.
11.4.5. Points to watch for this type of solution.
Posted May 8, 2009
The blurb on the back cover says it well. There is an alphabet soup of acronyms floating around this concept mindspace of application integration. The book attempts to stand above all these ideas, while explaining them in succinct fashion.
Ultimately, they all revolved around the problem of hooking up two (or more) sets of software, where associated with each set might be manual business procedures (sometimes called processes). So the book is not just purely about software. It offers no code fragments, for example.
The reader can be a manager, with probably already some type of computer technical background. You have been assigned the task of merging the business procedures. Inevitably, there is indeed much jargon and acronym soup in the text. But there are good instances of practical examples. An approach used in several places in the book is to look at the dataflow. This mindset can be a great aid to you. There are existing applications. The outputs from some have to go as inputs to others. Typically, you have to transform the outputs in some way, before they can be inputs. If you use this approach, it can make concrete what has to be done, and put this into modular form that you can then assign to team members.
This pedagogy may be more meaningful than some books that are strictly on SOA. These can drown the reader in the technical details of connecting up an SOA system. While you may end up having to use such texts, the current book attempts to rise above such lower level details, to focus more on the overall design.
The book also makes clear that you cannot do an ab initio top down design, starting from no legacy code. This is the "integration" in the book's title. Realistically, you have to contend with complex existing components, possibly located in physically distributed systems (ie. not in 1 data center).
En passant, it is interesting that the book omits mention of JMX. About 8 years ago, this was bruited about in Silicon Valley as a next big thing for software integration, and several startups were funded to build it out. JMX still exists, but it was never able to go far. While SOA, BPM and WSDL seem more flexible and successful. Implicitly by omission, this book offers that opinion. (Take that, those of you in 2002 who said JMX would be awesome!)