Organizations that are able to integrate their applications and data sources have a distinct competitive advantage: strategic utilization of company data and technology for greater efficiency and profit. But IT managers attempting integration face daunting challenges--disparate legacy systems; a hodgepodge of hardware, operating systems, and networking technology; proprietary packaged applications; and more.
Enterprise Application Integration (EAI) offers a solution to this increasingly urgent business need. It encompasses technologies that enable business processes and data to speak to one another across applications, integrating many individual systems into a seamless whole.
Enterprise Application Integration provides a comprehensive examination of EAI. You will find an overview of EAI goals and approaches, a review of the technologies that support it, and a roadmap to implementing an EAI solution. You will also find an in-depth explanation of the four major types of EAI: data-level, application interface-level, method-level, and user interface-level. The book describes in detail the middleware models and technologies that support these different approaches, including:
Click below for Sample Chapter related to this title:
1. Defining EAI.
What is EAI?
How Did Things Get This Bad?
Chaos Today, Order Tomorrow.
Evolution of Stovepipes.
Making the Business Case for EAI.
The Virtual System.
Types of EAI.
Middleware and EAI.
Going for the Data.
Data-Level EAI by Example.
Federated Database EAI.
Consider the Data Source.
Other Data Storage Models.
Working with Data-Level EAI.
What’s an API?
Interface by Example.
Approaching Application Interfaces.
The Interface Tradeoff.
Packaged Application Technology Architecture.
Packaged Application APIs.
Rolling Your Own API.
Using Application Interfaces.
What’s a Process?
Leveraging Frameworks for EAI.
The Value of Frameworks.
Application or Transaction Servers.
Sharing Methods to Bind Your Enterprise.
Leveraging User Interface-Level EAI.
Going to the User Interface.
Understanding the Application.
Creating the Screen Catalog.
Applying a Procedure/Methodology.
Step 1: Understanding the Enterprise and Problem Domain.
Step 2: Making Sense of the Data.
Identifying the Data.
Step 3: Making Sense of the Processes.
The Common Business Model.
Leveraging Patterns for Method-Level EAI.
Step 4: Identifying Application Interfaces.
Application Interface Directory.
Step 5: Identifying the Business Events.
Step 6: Identifying the Schema and Content Transformation Scenarios.
Step 7: Mapping Information Movement.
Step 8: Applying Technology.
Step 9: Testing, Testing, Testing.
Step 10: Considering Performance.
Step 11: Defining the Value.
Step 12: Creating Maintenance Procedures.
Method or Madness?
Middleware: The Engine of EAI.
Types of Middleware.
One-to-One versus Many-to-Many.
Synchronous versus Asynchronous.
Connection-Oriented and Connectionless.
Fire and Forget.
Notion of a Transaction.
XA and X/Open.
Future of Transactional Middleware.
Message-Oriented Middleware (MOM).
Getting the Message.
What’s So Difficult?
What’s So Easy?
What’s a Distributed Object?
The General Idea.
Moving to DCOM.
What’s Database-Oriented Middleware?
Types of Database-Oriented Middleware.
Ready for Prime Time.
Categories of Java Middleware Standards.
The Future of Java and Middleware.
Why Packaged Applications?
Installing Packaged Applications.
Architectures Drive Success.
Testing What Has Already Been Tested.
Implementing Specific Packages.
Packaged Application Tools.
Web-Enabled Selling and EAI.
Integrating the Supply Chain.
Applying EAI to Packaged Applications.
Our Packaged Future.
The Basic Problem.
The SAPPresentation Layer.
The SAPApplication Server Layer.
The SAPDatabase Layer.
Using the Repository.
SAP and EAI.
SQRs and Moving Data.
Workflow and Moving Data.
Defining Your Supply Chain.
Extending EAI outside the Enterprise.
Binding the Home System to a Stranger’s.
Supply Chain Technology.
ERPs and the Supply Chain.
Supply Chains Organize.
The Rise of XML.
XML and Middleware.
RDF and EAI.
XSL and EAI.
XML and EAI.
Integration, not Perspiration.
Why a New Direction?
Considering the Source (and Target).
Message Translation Layer.
Graphical User Interface.
Static and Dynamic Adapters.
Using an API.
The Future of EAI and Brokers.
What is Process Automation?
Process Automation and EAILevels.
Implementing Process Automation.
Tools and Approaches.
Process Automation and EAI.
Problem Domains Change.
Moving from Intra- to Inter-Enterprise Application Integration.
Moving from Data-Level to Application-Level Integration.
Technologies Join Forces.
Importance of the Architecture.
Importance of Application Design.
EAI and the Modern Enterprise.
Enterprise Application Integration, or EAI, is a buzzword that gives a name to the informal process that's been going on for years--the integration of various applications so that they may share information and processes freely. However, with a new, intense focus on EAI from both the vendor and analyst community, the opportunity finally exists to get ahead of the curve on a problem--the integration of applications--that costs the Fortune 1000 over $100 billion per year.
Forester Research estimates that more than 30 percent of IT dollars are currently being spent linking systems together for the common good. Perhaps it's time to consider whether that is too great a cost.
The EAI twist to this old story is not so much about system integration as it is about rethinking the technologies and approaches that would allow EAI to become a short-term and cost-effective reality. EAI also represents a technology-business philosophy that focuses on the business issues at hand and suggests that all systems existing either inside or outside an enterprise should be free to share information and logic in ways inconceivable in the past. EAI is the nexus of technology, method, philosophy, and desire to finally address years of architectural neglect.
Make no mistake--this is an emerging space. Now is the time to ask the tough questions. Now is the time to determine the real value of applying EAI in an enterprise. It's time to question which technologies add value, and to determine which problems they solve. And now is the time to reflect on some of the architectural and design decisions that have been made over the years.
Again, EAI as such is not new. However, the science behind linking varied types of information systems certainly is. EAI has become a sophisticated set of procedures with newly refined technologies, such as message brokers, that allow users to tie systems together using a common glue. The concept of EAI may not be new, but the power of the tools and technology, as well as the techniques available to solve the EAI problem, sure are. Middleware, for example, once clearly a programmer's toy, is now a business tool that allows enterprises to freely move information between any number of systems at will--in many cases, without having to change the source or the target systems. Cutting-edge technology has created the opportunity to solve a problem that has been becoming more intractable for years.
Companies such as SAP have become multibillion dollar entities thanks to the wide acceptance of ERP applications in larger enterprises. What's more, interest in packaged applications has increased in general, with sales automation packages, customer care packages, and vertical market-oriented packages making headlines in the trade publications.
As much as ERP applications can help the integration solution, however, they can also hurt. Organizations are discovering that ERP applications are difficult to install and configure and that, too often, once they are up and running, they turn out not to be all that they were cracked up to be. There is the "little problem" of extracting information from these beasts, information that may be vital to other information systems within the enterprise. For example, if SAP replaces five systems within an enterprise and those five systems supply information to any number of other systems that may also be in place, then the SAP systems must also communicate with these other systems in the enterprise. Making this happen demands an incredible degree of coordination, programming, and testing.
Although coordinating these systems may seem like a minor problem to those who have linked custom systems, it is important to remember that a packaged application typically does not allow for any modification to its source that would enable it to pump information out of a common middleware pipe. This requires interfaces that the ERP application vendor provides. While it would seem like an easy stretch to expect the vendor to have solid and easy-to-use interfaces already in place, the reality is much different. In fact, the major ERP application vendors are beginning to create these interfaces within their products. For the time being, the interfaces are immature and difficult to use. This immaturity represents another aspect of EAI and its real value within many enterprises. EAI is able to link many disparate systems--including ERP applications. It is not unreasonable to suggest that the growing interest in ERP could very well be driving the interest in EAI as well.
Why Write a Book on EAI?
We will present approaches to implementing EAI within typical enterprises, or between two or more enterprises, using the supply chain integration scenarios. We will also discuss the enabling technologies of EAI, technologies such as middleware, system management layers, standards (such as XML), and application development tools that allow applications and databases to share information with one another. Interfaces into complex systems such as SAP and PeopleSoft will not be left out of the mix. We'll also take a look at the future of EAI technology and discuss how you can prepare for it now.
Ultimately, this book is designed to save you money. Because the lack of proper EAI means that many existing information systems cannot coordinate or share information--resulting in a tremendous loss of revenue--then the addition of EAI within most enterprises has the potential of saving that revenue. Much of those savings come either with the automation of processes that are currently being completed through mechanical mechanisms or through viewing all enterprise systems as a single virtual system and thus having access to all relevant data for decision support.
Of course, any number of other types of savings may be derived from EAI; they vary case by case, enterprise by enterprise. In most situations, the value of EAI is apparent.
In addition to the benefit of application integration within the enterprise, a tremendous benefit is also derived from sharing information with applications that exist outside of the enterprise. eBusiness integration is a mechanism by which information systems are connected with information systems that are owned and maintained by a trading partner. The result is the ability to share information, such as order inventory and sales data. Sharing such information speeds up all aspects of business, including production, sales, order processing, and invoice processing. Increased efficiency in any and all of these areas results in increased profitability.
eBusiness is the next frontier of EAI. Analysts have already begun to double the estimates for business-to-business electronic commerce.