Enterprise Application Integration: New Solutions for a Solved Problem or a Challenging Research Field?

Enterprise Application Integration New Solutions for a Solved Problem or a Challenging Research Field?


Joachim Schelp
University of St. Gallen, Switzerland

Frederic Rowohl
University of St. Gallen, Switzerland

Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.


When closing the loop back to legacy systems, data warehousing is becoming a general IT integration topic, which is — partly — discussed under the label enterprise application integration. This article enables the interested reader to identify current problems in enterprise application integration. It shows solutions reached in previous research efforts, as well as solutions provided by today's software vendors. Finally, it sums up the pending gaps and open research fields.


For many years, the integration aspect has been a main topic in both theory and practice of computer science. The overall aim is to integrate heterogeneous applications across processes in the whole enterprise. During the last decade, several approaches have been made in both research and practice to establish such integrated information systems (Mertens, 1966; Scheer 1995; Merttens, 1995). The theoretic approach often is to propose new application systems or architectures. For example, Scheer (1995) and Mertens (1995) worked on reference models for the integration of applications (and data). Other approaches focus on data flows, processes or functions.

Still today, there is an increasing demand for integrating applications in the business area. Pending integration efforts, like data warehousing projects, are to be extended to bring their results back to legacy systems, e.g., to feed customer relationship management systems. New business models require the adoption of new technologies without leaving enough time to build up completely new systems: existing applications have to be extended by connecting them to new application types bearing these new technologies. The development of horizontal applications is an example of this trend (Winter, 2000).

Although several approaches were developed to integrate existing applications, software vendors still present new toolkits based on new technologies to address the specific needs of enterprise application integration problems. As these technologies are not mentioned explicitly in the existing approaches for application integration, we have to ask whether these approaches fulfill today's needs and represent the state of the art in application integration. Main problems occur in both increasing complexity and dynamics of today's businesses and information technologies, as well as in varying decentralized architectures. Furthermore, for most of the approaches presented in research, existing applications or architectures are discarded in favor of new ones without referring to or even integrating the existing set of systems.

This article derives specific problems occurring from integration and requirements for the integration of existing heterogeneous applications regarding current business needs. After an initial discussion, we will show the result reached in several research projects in the past and compare them with the problems and requirements described before. In a third step we ask for current solutions provided by both software vendors and the scientific community. Again, we will compare these solutions with the problems and requirements described initially. Finally, we show the gaps still pending and deduce the open research problems. A short conclusion will round up this paper.

Current Requirements for Integration of Applications

As stated above, still today integration is an urgent need for companies. This has several reasons, which result from the rapidly evolving technological environment and the fast adoption in business processes:

  • New technologies enable new application types, opening new distribution channels for companies. For example, in the banking area there are not only ATM-networks as an additional front-end to the customers but also WWW- or WAP-interfaces. And again, new technologies like UMTS are at the horizon (EITO, 2001).
  • Because of the internet, there is an urgent need for enabling online transactions instead of the old-fashioned batch processes. Batch processing methods require time frames which customers do not accept when initiating online transactions.
  • New applications for customer relationship management extend the need for transferring analytical data from data warehouses back into transactional systems. This remarkably impacts performance, access, and data organization for these systems. Data has to be organized by subjects and not only by relations, online transactions are required as well as short request times. These are challenges for both analytical and transactional systems, which today fulfill only one or two of these requirements.
  • Integrated solutions, like enterprise resource planning systems, reach their limits when new technologies must be incorporated. Therefore, additional tiers must be introduced in the information system environments to add an additional transformation layer between old and new applications.

To sum up these problems, we can derive the following requirements. The above problems can be united to complexity (in different ways), compatibility (e.g., to exchange data), and limited capacity of existing systems.

  • The higher a legacy systems' data, function, and process models' complexity is, the more complex is an integrated logical view on them. But this is required to couple the systems together. Therefore, there is a strong requirement to build integrated logical models of different levels of complexity.
  • Especially old legacy systems have limited means of importing or exporting data in foreign formats. To exchange and convert data between different systems, metadata has to be collected, structured, and exchanged. Therefore methods and tools for metadata management are required which can enable data quality issues as well.
  • From a more technical point of view, additional application layers are required as the older legacy systems are often working at their capacity limit. Because of little system performance, sometimes they cannot export and import data to additional systems even if they have the functionality to do this. The resulting enhanced IT landscape of a company must be planned and maintained.

These requirements are a challenge. As technological improvements are still at the beginning, companies are urged to work with continuously changing environments. Heterogeneity in the IT-landscape within an enterprise will be an ongoing challenge, which has to be met by IT-concepts and strategies as well as by middleware applications in use.

The addressed requirements can be met on a more conceptual and on a more technical level. Conceptual approaches developed in the previous decades are discussed in the following section, technical solutions as well as current conceptual work are presented later.

Previous Integration Approaches

Since the early 1970s, the need for integration and concepts of integration of enterprise applications has been a broadly discussed topic in the computer science community. Several existing suggestions have been made and further developed in literature. However, not all were implemented in practice, so a proof of concept has not been made for each proposed solution. With today's increasing demand for integration models, the view of existing approaches could give an indication of recent research efforts. This chapter gives an overview of existing integration models and procedures.

Different views on integrated information management can be distinguished (Mertens, 1995):

  1. Integration object

    The integration object can be data, functions, processes, methods, and programs.

  2. Direction of integration

    The direction of the integration can be horizontal or vertical.

  3. Range of integration

    The integration can take place in one area of an enterprise, in the whole enterprise, or between different enterprises.

  4. Degree of automation

    The intended degree of automation can be full automation or automation in parts.

Concerning the integration object, recent models focus on both data and functions, and partially on processes. The other views are secondary and often follow the integration object. Different levels of integration of data and functions are shown in Figure 1. In the left figure, two systems exchange and process data automatically. This is a very simple way of integration, but the data has to be stored redundantly. In the middle figure, different applications use the same database. The data has to be modeled in an appropriate way to integrate it in one database. In the right figure, the functions are linked together on a technical level. The result is an integration of functions (see also Mertens, 1995, p. 24).

click to expand
Figure 1: Integration of data and functions (Mertens, 1995)

Basically, existing integration models can be divided in data oriented, function oriented, and others (Mertens & Holzner, 1992).

Data Oriented Integration Models

The models developed by Vetter, Scheer and Rauh are good examples for data oriented integration concepts. At least Scheer's model is known beyond German speaking countries, because of his model's (ARIS) role in the customization process for enterprise resource planning systems like SAP R/3.

"Conceptual Data Model" by Vetter (1990)

Vetter separates in his Conceptual Data Model different phases of development, namely the design of the object system, the information system, the database concept, and the processes. He defines a bottom-up approach when he develops the enterprise wide data model by joining the separated data models of applications from the business departments. The aim is to develop an extensive data model of the informational environment.

"ARIS" by Scheer (1991)

Scheer developed "Architecture of Integrated Information Systems (ARIS);" a framework for development, optimization and realization of integrated applications. The "ARIS-House" (Figure 2) is an architecture combining multiple views and levels of integration.

click to expand
Figure 2: The "ARIS-House" (Scheer, 1991)

He defines process chains as the starting point of the development of the system architecture. The process chains are assigned to separated levels: on the application level there are single proceedings, on a higher level the process types and the standard processes. On this level, the enterprise information systems are allocated. On a meta level the general process model is defined.

The development of ARIS consists of four phases. First is the analysis of the process chains. Second is the modeling of the conceptual model, followed by the design of the data-process concepts. The fourth and last step is the design of the implementation concept. Phases 2 to 4 are subdivided by different views (function, organization, data, control). The conceptual data model is an important element of ARIS, whereon the focus on data integration is based.

ARIS consists of entity relationship models for different functional areas, in detail for production, technology, procurement, sales, human resources, accountancy and administration. The ARIS-approach is top-down because of the definition of process chains from an external point of view.

UFM-UDM by Rauh (1990)

Rauh developed a function model of the enterprise (UFM) and a data model of the enterprise (UDM) and combined them. The UDM should be a complete description of the enterprise from a data point-of-view. The data are assigned to functions, such as procurement, production, sales, human resources and accountancy, management, controlling, and information management. These functions again are divided into strategic, tactical, and operative functions. The aim is to base the function model on an enterprise wide data model.

Function Oriented Integration Models

The two function-oriented integration models presented here were developed from a more theoretical point of view.

"Kölner Integrationsmodell (KIM)" by Grochla (1974)

In the mid 1970s Grochla developed, at the University of Cologne/Germany, the "Kölner Integrationsmodell (KIM)" (Cologne Integration Model). The KIM is an integrated total model for planning, realization and control tasks of information systems. Data-proceeding jobs are seized within and between the enterprise areas of procurement, logistics, production, sales etc. The model consists of a literal and a graphical part.

In the literal part, a task description list, a channel list and a connector list are separated. The channel list describes how the tasks are combined and work together, the connector list brings tasks together with others. The graphical part exists of models for the named tasks — planning, realization, and control. The KIM is very detailed and extensive. The focus is not on databases but on functions in the enterprise information system environment.

Integrated Information Processing by Mertens (1995)

Mertens divides, in his model of integrated information processing (the 11th edition), horizontal and vertical integration (Figure 3). The main focus for the horizontal integration aspect (which is more interesting in this context) is the value chain of an enterprise. Therefore, he mainly deals with the coherence of processes (e.g., procurement) and does not start with an integrated enterprise-wide data model. His model is defined as text, in a function tree, a data flow plan, and in different tables.

click to expand
Figure 3: Total concept of the integrated information processing (Mertens, 1995)

Although he points out that there is a risk for interrupting business processes when taking a view from departments or sections of an enterprise, and not from the process point of view (1995, p. 4), Mertens deals with the functions within areas like R&D, sales, procurement, logistics, production, etc. His model is likewise a total integration model and comprises the whole organization.

Other Approaches for System Integration

Integration is an implicit issue within the various approaches in business process (re-)engineering — especially when this topic is discussed from information technology's point of view. One of these approaches, Scheer's Architecture of Information Systems (ARIS) was discussed in a previous section. During the last decade a wide range of other business process engineering approaches were discussed. As most of them have a subset of the power in expressiveness or range of models, the following discussion will focus on SOM (Semantic Object Model), which is object-oriented and is different from the other approaches.

Introduced by Ferstl and Sinz in 1990 (Ferstl & Sinz, 1990), the SOM is another approach to model business processes. It is targeted on enterprise planning, business process modeling, and the specification of business application systems. Enterprise planning is done to identify all relevant objects within the company's universe, as well as outside. Then these objects are used as a base for the more detailed specification of the business process model from the behavioral perspective. The processes are split up in transactions between two objects. Transactions control and execute exchanged services and messages.

The business process model can be modeled from different perspectives: the interaction model specifies the flow between objects and the process event scheme shows the events related to transactions in a way similar to petri nets.

Similar to ARIS, there is a special modeling tool available for the SOM approach. In contrast to ARIS, it keeps only one meta model in its repository and all graphs are generated from that model. Also, every modification made from one perspective will modify the central model and, accordingly, the other perspectives (Ferstl et al., 1994). Also based on this central model, the third modeling goal in the approach will be supported: the specification of business application systems to ease its implementation.

As most business process (re-)engineering approaches, SOM is aimed to build a new application system from scratch. The tools accompanying these approaches are helpful to reduce the complexity of the according data, function, and process models, respectively, to handle them. But the resulting application is still complex and a closed one. When further applications have to be integrated, the right solution from this point of view is to develop a new application.

Current Approaches to Application Integration

The heterogeneous environment of information systems leads to both many integration problems and big challenges for system architects. Historically, built information infrastructures collided with claims made by current e-business needs. Related business processes are divided on different islands of hardware and software. EAI is demanded when business processes on different information platforms must be contracted. Currently, breaks in media and inappropriate human-to-machine interfaces are a standard in today's information environments. First steps of solving the problems lead to point-to-point connections between single applications. But the massive need for integrated systems in e-business can not be met with m*n single connection points. Experts say that after the database segment and the enterprise resource planning (ERP) segment, EAI-applications will be next to become a big market of standard software tools (Nußdorfer, 2001). Therefore, the next section describes the solutions provided by the market before some of the theoretical work in this field is discussed.

EAI Solutions Provided by the Market

EAI-tools link different data sources and applications at the application or process level. They portray business logic through process modeling and workflow control, less than connecting systems, technically or semantically on the functional or data level. They present a dedicated transaction platform, either as a central hub-and-spoke model or as a distributed bus-oriented approach (Knapp, 2001).

Integration can be done at three different layers of applications: on the presentation layer, on the function layer, or on the data layer. Integration at the presentation layer is quite simple because the respective information is put together at the user interface. The user is able to work with different programs at one interface. It is possible to add features like workflow or validation rules. The disadvantage of this solution is the system performance because of the additional software layer upon existing programs. Implemented functions can be used further when the integration is made at the function layer. The applications communicate on interfaces and either exchange data or call a function. Integration at the data layer uses the data sources directly. This method is useful when data must be exchanged between different applications. Problems arise in understanding the data models and the business logic. Furthermore, the interfaces must be adapted when changes at the data models are made; the administration tasks are quite intensive.

EAI and middleware are often used synonymously. But as experts point out, EAI actually is the logical development of known middleware concepts. The middleware works on a lower level of abstraction, either synchronous or asynchronous, and is message oriented or transaction oriented. However, the method of EAI is more likely comparable to tools from the extraction-transformation-loading (ETL) area in data warehousing. Both provide the unit of data (Knapp, 2001).

"[...]middleware is a general term for any programming that serves to 'glue together' or mediate between two separate and usually already existing programs" (TechTarget.com, 2001). Many software producers offer their tools under the term middleware, whereas their marketing departments talk about EAI-solutions. However, the market can be subdivided in five different categories (Oberdorfer, 2001):

  1. Remote Procedure Call (RPC) Technique

    With RPC functions on, a remote computer can synchronously be started by using a network. This oldest middleware technology comes from the 1970s and is used for most distributed object technologies.

  2. Database Access Middleware

    This middleware enables the access on remote databases. Today, standards like Open Database Connectivity (ODBC) or Java Database Connectivity (JDBC) are accepted and supported by most databases. Database access middleware is suitable for access at the data layer only.

  3. Message Oriented Middleware (MOM)

    MOM is used for the exchange of messages between applications. This service is an asynchronous method for integration. Each participant can be a sender or receiver, and the middleware plays the role of the post. Messages can be sent and received either with the messaging method or through defined interface. Products are, e.g., MQSeries by IBM, MSMQ by Microsoft, Java Message Service (JMS).

  4. Distributed Object Technology (DOT)

    With the DOT, objects are distributed in a network and can be called by defined interfaces. Today's applications often work with object-oriented languages, so DOT plays an important role for EAI. Problems occur in the complexity of the interfaces. Products are, e.g., DCOM by Microsoft, CORBA by the OMG, Java2 Enterprise Edition (J2EE) by Sun.

  5. Transaction Oriented Middleware

    In this technique, transaction processing monitors (TPM) handle the communication of different applications. TPMs are the central node of the application logic and are named as the first generation of today's application servers. The procedures are based on single transactions. TPMs ensure the integrity of the transactions and manage the resources. Products are, e.g., Tuxedo by BEA, MTS by Microsoft, CICS by IBM.

Different methods are often used in combination. In addition to this, some of the current buzzwords introduced by vendors (e.g., web services) can be seen as extensions or a further development of these five above-mentioned middleware technologies.

In contrast to the approaches mentioned above, applications are loosely coupled when integrated within an EAI project. In addition to the concepts mentioned before, also mixed architectures are possible. An example may be the integration of a portal system with existing transactional systems. A messaging-based approach may cause problems under certain circumstances, especially when transactional systems are running with a high load, close to their capacity limits, and with a slow response time. The solution may be to store data redundantly in a separate data store and to query only selected, most current data from the transactional systems (e.g., stock information) and to keep data like user profiles in this separate data store. An example of such an architecture is depicted in Figure 4.

click to expand
Figure 4: Example of a mixed EAI-architecture

The aim of using middleware components is to generate consistent data structures in information systems. Moreover, EAI integrates business processes and data, but not only data like middleware does. On the other hand, middleware is basic for EAI-tools. While middleware does not provide a central control instance and leaves the business logic in the applications, EAI is process oriented and manages business logic and processes in a central authority. Uncoupling technology and applications enables the reuse of the single parts.

EAI ranks on a higher level than the single application or information system (and therefore middleware) does. The challenge of EAI is the aim to integrate existing systems on the one hand and, on the other hand, to define the business logic on a meta level (from technology point of view). The starting point in EAI-projects must be the existing business logic and process connections realized in the applications. Hence, EAI primarily is technology driven, and business driven secondarily.

EAI in Literature

There is not much research work done explicitly on enterprise application integration yet. Most sources stating EAI in their title simply document concepts and systems implemented in practice. But when the focus is widened, there is a lot of work concentrating on middleware, data base systems, data warehousing, systems architecture, portals, etc., addressing integration issues as well. Concerning the components shown in Figure 4. There are a wide range of ongoing research projects that focus on different aspects like, e.g., extraction, transformation and load tools or meta data (see Marco, 2000; Poole et al., 2002) and, accordingly, repositories used in data warehousing in a similar way.

The current EAI discussion, led by vendors of EAI tools, is often dominated by messaging concepts and web services. The underlying middleware concepts are well discussed in the scientific community. Also, EAI topics initiated by vendors from related fields have a well-known base in research. An example is the transfer of analytical data from the data warehouse back to transactional systems. This may be the case when customer relationship management tools are introduced and an architecture as described in Figure 4 is chosen. Storing data redundantly for transactional purposes is a concept discussed — again — in the data warehouse field and is known as the usage of operational data stores (Inmon, 1999).

Like the vendors, the researchers enter the EAI arena from different starting points as well. For example, research work in (enterprise) portals faces the problem of integrating different application systems to feed the portal with data (Linthicum, 2001). Like research on portal technology, the research on collaboration technologies may be another starting point: the core of an application integration solution may also consist of a workflow management system (Kloppmann, 2001). Solutions like this may reflect the importance of the underlying business processes more than some of the EAI vendors' approaches concentrating on integration technology only.

Finally, standardization becomes more and more important for EAI projects. Standards for data exchange show their potential, not only in the inter-company communication, but also in the intra-company communication between different applications. Therefore, current standardization efforts to establish an EDI successor based on XML (Kotok & Webber, 2002) are also relevant for EAI.

Although a wide range of research efforts in fields related with enterprise application integration are ongoing, the number of publications dedicated to EAI is fairly small (e.g., Ruh et al., 2001; Linthicum, 2000), and most of them are still in the early stages of research work.

Comparing Existing and New Integration Concepts with Current Requirements

The previous chapter showed that vendors meet the technological challenges and that most of the scientific approaches concentrate on the conceptual view. The "traditional" scientific approaches are too simple to be helpful; building a new integrated application is a clear solution, but when facing limited time and budgets, this integrated application is too complex to be a useful solution. Additionally, when integrating further applications, the answer cannot be to build a new integrated one when considering limited time and budgets.

Therefore, the early scientific solutions mentioned above are helpful to address some of the complexity problems. They help to handle the complexity of data, function, and process models by structuring them and — partly — offering the tools to do that in a structured and well-documented way. But they are useful to document existing structures only. They are not connected to metadata repositories controlling ETL — or messaging tools. At the least, all documentation work has to be done twice.

The more theoretic approaches are helpful, but not satisfying, as they do not provide methods to model different applications and the relationships concerning data, functions, and processes between them. They do not provide methods for an integrated interface management, integrated metadata collection and structuring, nor means to assure data quality — at least not in an integrated way. The process models for these approaches fit to ordinary application development and often rely on prototyping, which is not adequate when the functionality for data exchange is not implemented at the required full extent.

The solutions offered by software vendors are focused on technical issues only. They offer tools to convert data between various formats, to exchange data between different kinds of data storage systems, and to establish communication between older legacy and newer internet applications. Also, they offer tools to manage metadata and to interchange it with the operational systems as well as with other tools.

On the other hand, they do not offer tools to model the integration. Data quality is recognized as an important problem, but the organizational side of this challenge is not addressed. The same is true for metadata management or the planning and maintenance of an IT landscape of a company. Most tools cover one of the topics mentioned only, few more than one. And no tool or integrated set of tools covers everything mentioned.

Theoretical as well as practical solutions address only parts of these complex problems. An integrated approach is still missing. The basic elements of such an approach to be developed are presented in the following section.

Table 1: Integration issues and their coverage in some research approaches







Integrated models for








































(•: fully covered, o: partly covered)

Open Research Issues and Outlook

An integrated approach to address the problems mentioned above must cover—among others—the following topics:

  • Metadata management as described before.
  • Data quality management as described before.
  • Data standards (XML, etc.) are to be chosen to exchange the data between various operational applications.
  • Transformation models are required to transform exchanged data between these systems.
  • Project management has to address chains of integration projects, as integration is an ongoing task and cannot be done doing single and separated projects alone.
  • The complex information technology infrastructure must be structured and planned to increase the flexibility of the overall IT-system of a company. Infrastructure development has to follow the evolution of the company's business and process models and not vice versa.

To address these issues existing methods and tools, especially in the data warehousing field, have to be reviewed. Some methods and tools can be enhanced, additional tools and methods have to be defined and proofed in projects.


Barker, R. (1990). CASE*MethodTM: Entity Relationship Modeling. New York: Addison-Wesley.

Emmerich, W., & Gruhn, V. (1990). Software Process Modelling with FUNSOFT Nets (Software-Technology Memo No. 47). Dortmund.

European Information Technology Observatory (EITO), & European Economic Interest Grouping (EEIG) (Ed.) (2001). European Information Technology Observatory, 2001. Frankfurt.

Ferstl, O. K., & Sinz, E. J. (1990). Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). Wirtschaftsinformatik, 32 (6), 566–581.

Ferstl, O. K., & Sinz, E. J. (1994). From business process modeling to the specification of distributed business application systems: An object-oriented approach. Bamberger Beiträge zur Wirtschaftsinformatik No. 20.

Ferstl O. K., Sinz, E. J., Amberg, M., Hagemann, U., & Malischewski, C. (1994). Tool-based business process modeling using the SOM approach. Bamberger Beiträge zur Wirtschaftsinformatik No. 19.

Grochla, E., et al. (1974). Integrierte Gesamtmodelle der Datenverarbeitung. München.

Grünauer, K. M. (2001). Supply chain management: Architektur, werkzeuge und methode. (Ph.D. thesis, St. Gallen, 2001).

Inmon, W. H. (1999). Building the Operational Data Store, 2nd ed., New York et al.

Kloppmann, M., Leymann, F., & Roller, D. (2001). Enterprise Application Integration mit Workflow Management. HMD, 2137, 23–30.

Knapp, C. (2001, March 23) Intelligente Verbindungen - Mit EAI Prozesse und Workflow übergreifend steuern. Computerwoche Extra, 2, p. 11

Kotok, A., & Webber, D. R. R. (2002). ebXML - The new global standard for doing business over the internet. Boston: New Riders Publishing.

Linthicum, D. S. (2000). Enterprise application integration. Reading, MA: Addison-Wesley.

Linthicum, D. S. (2001). B2B application integration: e-Business-enable your enterprise.Reading, MA: Addison-Wesley Professional.

Marco, D. (2000). Building and managing the meta data repository: A full lifecycle guide. New York: Wiley Publishing.

Mertens, P. (1966). Die zwischenbetriebliche Integration der Datenverarbeitung im Einkaufsund Lieferwesen. Zeitschrift für Datenverarbeitung, 4, 207.

Mertens, P. (1995). Integrierte Informationsverarbeitung, 1 (10).

Mertens, P., & Holzner, J. (1992). Eine Gegenüberstellung von Integrationsansätzen der Wirtschaftsinformatik. Wirtschaftsinformatik, 34 (2), 5.

Nußdorfer, R. (2001, March 23). Der Markt hebt langsam ab—Enterprise Application Integration in Deutschland. Computerwoche Extra, 2, 4–7

Oberdorfer, R. (2001). Allround-Adapter—EAI: Ordnung in Unternehmensanwendungen. iX: Magazin für professionelle Informationstechnik, 5, 136–139.

Poole, J., Chang, D., Tolbert, D., & Mellor, D. (2002). Common warehouse metamodel: An introduction to the standard for data warehouse integration. New York: John Wiley & Sons.

Rauh, O. (1990). Informationsmanagement im Industriebetrieb - Lehrbuch der Wirtschaftsinformatik auf Grundlage der integrierten Datenverarbeitung. Herne, Berlin.

Ruh, W. A., Maginnis, F. X., & Brown, W. J. (2001). Enterprise Application Integration: A Wiley Tech Brief. New York: John Wiley & Sons.

Scheer, A.-W. (1991). Architektur integrierter Informationssysteme. Berlin: Springer-Verlag.

Scheer, A.-W. (1995). Wirtschaftsinformatik. Studienausgabe, Berlin: Springer-Verlag.

UBIS GmbH (Ed.) (1993). BONAPARTTM: Model your business - Objektorientierte Unternehmensmodellierung mit BONAPARTTM. Berlin.

Vetter, M. (1990). Strategie der Anwendungssoftware-Entwicklung: Planung, Prinzipien, Konzepte (2nd ed.). Stuttgart: B. G. Teubner.

WhatIs.com. (2001) Content. Retrieved from http://whatis.techtarget.com/definitionsSearchResults/1,289878,sid9,00.html?query=middleware

Winter, R. (2000). Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur. In R. Jung, & R. Winter, (eds.), Data Warehousing Strategie — Erfahrungen — Methoden — Visionen (pp.127–139). Berlin: Springer-Verlag.

ERP & Data Warehousing in Organizations. Issues and Challenges
ERP and Data Warehousing in Organizations: Issues and Challenges
ISBN: 1931777497
EAN: 2147483647
Year: 2002
Pages: 174

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net