|
THE ORIGIN AND SEGMENTATION OF ENTERPRISE INTEGRATION SOFTWARE
The integration of software assets has grown in importance over the last several years. In fact, in IDC's Software Strategies and Investment Survey (fall 2001) we found that, as a strategic business initiative, the internal integration of applications ranked second only to application maintenance, as seen in Figure 1. This means that internal application integration ranked higher in importance than building, deploying, or customizing new applications and building ecommerce solutions.
The primary driver behind today's emphasis on integration is the rapid evolution of the software industry along several key dimensions, including:
System heterogeneity, which builds from the origin of mainframes through the addition of midrange Unix and Windows servers to desktops and remotely connected devices, thereby expanding the number of operating systems and protocol stacks that need to be supported
Programming, which originated as a procedural process model but now has largely been replaced by declarative or event-driven process models that are easier to componentize and can be dynamically bound at runtime, thereby better facilitating application integration
Processing, which originated with mainframe-centric monolithic processing but is now widely distributed across server farms that employ a combination of partitioning and replication techniques to share workloads while remaining synchronized
Latency, which originated with OLTP and batch processing but now has expanded to include near real-time processing and related queue-based asynchronous processing models
Although "application integration" has become a colloquial expression that is used to refer to anything that is integration related, numerous software products specialize in supporting integration. These products can be segmented into those centered around data integration, business process integration, and access integration. They share classic three-tier architectural characteristics, with data integration associated with the data management tier, business process integration associated with the application logic tier, and access integration associated with the presentation tier. Each of these application integration product categories is defined in the following section.
Extract, transform, load (ETL) tools. These tools provide the foundation for data integration tasks and enable extracted data from source systems, transforming it, and loading it into target systems.
Data analysis and reengineering tools (DART). These tools support activities such as data profiling, data matching, and semantic mediation.
Data quality software (DQS). DQS supports data validation, data auditing, error analysis, and error correction.
Data replication software (DRS). DRS synchronizes data across dissimilar databases through techniques such as change data capture.
Data adapters. Data adapters provide data-focused component interfaces to a wide variety of data stores.
BUSINESS PROCESS INTEGRATION PRODUCTS
Integration server software platforms (ISSPs). ISSPs provide a centralized infrastructure for application integration and business process integration along with API-level interfaces.
Message-oriented middleware (MOM). MOM fosters application interoperability through messaging.
INTERFACE INTEGRATION SOFTWARE PRODUCTS
Enterprise information portal (EIP). EIP integrates access to information and presents it to a business user in a useful format.
Access integration middleware (AIM). AIM provides transparent access and updates to legacy applications.
Data integration software products are in many ways the foundation for enterprise integration. Data integration software products have existed longer than their application integration or access integration market counterparts and are often the starting point for organizations pursuing integration. Data integration products are chosen because persistent data is easily accessible, is not sensitive to state, and is typically well structured, which enables operations to be easily defined and bounded as well as executed completely. Application integration, on the other hand, can be far more complex, requiring an interface with a message broker at a minimum or, more often, application interface coding in the form of proxies, user interface coding, API coding, stored procedures, or triggers, most of which require invasive coding to the applications and databases.
Integration makes it possible to leverage existing software assets while continuing to invest in newer technologies. Given the wide range of solutions available for addressing the integration dilemma, what are the characteristics that make up a comprehensive and sound integration solution?
|
