Expand +



Coping with Application Integration - It's a Critical Challenge for Every IT Organization

by Matthias Haendly | SAPinsider

April 1, 2002

by Matthias Haendly, SAP AG SAPinsider - 2002 (Volume 3), April (Issue 2)

Driving integrated business processes across heterogeneous and highly dynamic system landscapes — and doing so in a cost-effective way — is now a critical IT challenge. Businesses now demand that diverse systems and applications work together, yet most software components are not built for that integration — which often leads to a system landscape something like the one in Figure 1. It’s then incumbent upon IT departments to master various internal and external interfaces, navigate through complicated system and release-specific issues, and acquire in-depth knowledge about each participating application and system and the relevant processes.

Figure 1 The Integration Challenge

Add to this the pressure to quickly adjust business processes to meet prevailing market conditions, and you begin to get a sense of the enormity of this challenge and the reason why significant portions of an IT budget are consumed by these activities.

Over the past ten years, lots of technical solutions have been introduced by various vendors to achieve some relief. And therein lies the problem: application integration is not merely a technical problem! You first need to address it from a business process perspective. Second, you must recognize the need for a common, cohesive, and standards-based infrastructure. Then, and only then, can you achieve the flexibility necessary for success — and more importantly, long-term success — on the application integration front. This is precisely what SAP has done with our new exchange infrastructure.

Facing the Integration Challenge with the SAP Exchange Infrastructure

The exchange infrastructure is not just a technical platform. It also provides and captures relevant semantics for SAP and non-SAP systems alike, and supplies the tools to provide the necessary semantics in instances where SAP’s pre-built integration scenarios don’t address your specific tasks and systems.

So what differentiates SAP’s exchange infrastructure from application integration solutions offered by other technology vendors? SAP is not just a technology vendor! SAP produces technology and applications, and this, I would argue, is why SAP is uniquely qualified to address this challenge. Application integration takes place on many layers of the application stack. Not too many vendors can achieve integration at all the necessary touch points, up to and including the very semantics of the application. I consider SAP to be alone in this respect.

How Much Do You Spend on Integrating Applications?
Probably More Than You Think!

I recently learned of a US customer who was assessing the costs of designing, implementing, and maintaining their 15,000 (yes, you heard right!) application interfaces. Care to guess how much money they spent, on average, designing and implementing just one interface? $75,000 USD! And how much do you think they spent maintaining each interface? $15,000 USD. For this customer, the cost of application integration added up to a whopping sum.

You may not have 15,000 interfaces to contend with. You also might not be faced with the same average design, implementation, and maintenance costs. Then again, you might. The true cost of application integration can be deceiving.

Let’s first look at what I call the secondary cost factors that need to be considered1. * These are the costs associated with just the integration tool, not the interfaces you will ultimately build with that tool:

Licensing fees: Software licensing and yearly maintenance fees for the integration tool, such as those from SeeBeyond, Vitria, WebMethods, or other providers
Hardware: Purchasing and installing additional hardware on which to run the tool

Training: Needed for users and administrators of the integration tool

All these things must be in place before you can actually design and implement the interface, efforts that constitute the primary costs of application integration. For every interface that is developed, you need to take the three steps listed below.
Essential Steps for Designing and Implementing Application Interfaces
Thoroughly analyze and design the overall business process, and then the specific interface, to ascertain its underlying functionality and technical requirements.
For this phase you need to combine technical and application knowledge.
Develop the required connection.
Most integration projects implement what I call “point-to-point,” hard-coded connections. In effect, you construct a new and unique connection for each and every integration point. The code that supports each connection resides inside the participating applications. These types of coding exercises require you to define distribution and mapping rules. They also require you to assume responsibility for ensuring reliability of the connection.
Test and debug the interface
to ensure its usability and reliability.


How Much Money Can SAP's Exchange Infrastructure Save You?
Probably More Than You Think!

Let’s look first at the secondary costs of the exchange infrastructure — those associated with licensing, hardware, and training.

Licensing fees for SAP exchange infrastructure will be commensurate with those of other integration tools, so there won’t be a savings there.

The exchange infrastructure can run on your existing hardware or on a dedicated server, depending on your specific requirements. Note that if you run the exchange infrastructure on an existing SAP platform, you can leverage standard SAP administration and monitoring features, and that will translate into additional savings potential.

Substantial savings will be found in training (or lack thereof!). Think about it: When integrating two different applications with one another, you need to define the respective application interfaces (and the transformation of information that will transpire between them) from a structural and/or content perspective. If you are using different tools for different application systems, you revisit and reinvent these connectivity prerequisites with each and every integration exercise. The SAP exchange infrastructure is the only tool I am aware of that will handle SAP-to-SAP integration as well as non-SAP integration within and across enterprise boundaries. Learn it once, reuse it everywhere — that’s a non-trivial benefit!

Another key benefit — perhaps the key benefit — is that with SAP’s exchange infrastructure, we obviate the need for you to learn the in’s and out’s of the SAP side. mySAP solutions will be based on the SAP exchange infrastructure, which means they’ll plug right in. With this you get the integration knowledge right out-of-the-box, so you can focus your efforts on building connections to third-party, legacy, or homegrown systems.

With these elements in place, you can turn your attention to the design and implementation of an application integration interface. So how does the exchange infrastructure stack up in terms of cost savings?

Essential Steps for Designing and Implementing Application Interfaces
Thoroughly analyze and design the overall business process, and then the specific interface, to ascertain its underlying functionality and technical requirements. For this phase you need to combine technical and application knowledge. As for what you’ll need to learn about that target legacy system, SAP minimizes the training requirements. Lots of collaborative knowledge comes along with the exchange infrastructure, and anything you need to add on to your own legacy or homegrown systems can be leveraged over and over again. Since the exchange infrastructure is designed to work with a plethora of third-party systems, you get one integration tool that can use that information in a variety of integration exercises. Develop the required connection. Without an integration tool, you will have to construct a new and unique connection for each and every integration point. The code for that connection will reside inside the participating applications. But with the exchange infrastructure, we don’t have to talk about such “point-to-point,” hard-coded connections. It allows you to focus on defining your legacy systems interfaces and how to transform them into the target format. And because the SAP exchange infrastructure uses XML and open standards, it permits easy and affordable exchange of the required collaboration knowledge. Test and debug the interface
to ensure its usability and reliability.
The exchange infrastructure will take error handling and monitoring from the pure technical analysis of XML messages and make it accessible from the application. You have problems with a truck that isn’t loaded? Then you need the capability to retrieve and analyze all the technical messages related to this activity. The exchange infrastructure allows you to do just that.

Remember that even after the interface is developed, the job is not really done. Whenever a connected system is upgraded or its configuration is changed, you need to evaluate the impact on the specific connection. With the exchange infrastructure, the changes related to the connections for SAP systems will be in synch with application changes, so there’s no need to worry. For your own legacy systems, you would still need to reflect the changes, but you can use the very same tool to do that, too.

So you tell me: How much savings could you realize with SAP’s exchange infrastructure? Estimate the cost savings for just one interface, then extrapolate that over those planned throughout the remainder of this year and into the next. I’ll bet the savings is substantial!

Integrate Your Current and Future Applications

The exchange infrastructure was built from the ground up to capture application semantics at design time, and to ensure that participating applications thoroughly understand these semantics. And in many instances, SAP has already captured this information for you, by delivering shared collaboration knowledge — the information that is needed to integrate applications — along with the exchange infrastructure. New applications, like the recently announced mySAP SRM (Supplier Relationship Management) product, are based on and take advantage of the SAP exchange infrastructure in this way.

What about existing applications? BAPIs, RFCs, and IDocs are supported, and new Web services can be added at any time. Looking forward, new mySAP solutions (e.g., SRM) will be built on the exchange infrastructure. In the long term, the exchange infrastructure will replace other SAP integration solutions as SAP moves toward offering a single, homogeneous integration solution for all SAP and non-SAP integration challenges. (It should be noted that the SAP exchange infrastructure can work with other integration solutions as well. For example, integration with MQSeries or other messaging systems is possible via the JMS Adapter, supporting the Java messaging standard.)

Making shared collaboration knowledge readily available through the exchange infrastructure eases change management tremendously, giving you central access to this knowledge in an easy and transparent way. This easy access drives down the total cost of ownership, too, since you do not have to uncover, for each and every one of the different application systems, the ways in which integration-relevant information (interfaces, etc.) has changed. What’s more, by basing all integration requirements for these numerous, heterogeneous systems on one, homogeneous infrastructure, there is huge savings potential: just imagine, your people need to be trained on one tool, not many!

The SAP exchange infrastructure is already being used as an integration layer in the mySAP SRM solution, as well as in other upcoming solutions. Selected customers will receive the exchange infrastructure in 2002 for use in pilot application-to-application integration projects. From a functional perspective, these pilots can be put to work on all elementary integration tasks.

Let’s look at some integrated business scenarios that put the exchange infrastructure to work.

Some Examples of Integrated Business Scenarios

Consider a simple landscape consisting of two existing R/3 systems, a legacy system (a homegrown warehouse management system), and a third-party system that handles materials management. The first step toward full integration of these systems through the exchange infrastructure (see Figure 2) can begin with just a few systems.

Figure 2 Integrating the Legacy and Third-Party Systems Through the Exchange Infrastructure

Integrating Legacy and Third-Party Systems

Let’s assume that you collect inventory changes (e.g., materials movement) with a barcode reader and transfer the data in the format of a data file. Currently, most customers would use an individual, hard-coded piece of software to transform the data from the legacy system into the right format, and then call some routines to provide this information to the third-party system.

With the exchange infrastructure, the first step is to re-route this file-based communication between the legacy system and the third-party system. To perform this change, you would need to configure the right integration information — i.e., mapping, routing, and interfaces — in the exchange infrastructure.

With this approach, you gain central monitoring capabilities on every message that is transferred through the Integration Server. Depending on the effort you put into your existing hard-coded transfer program, you may also increase the stability of the connection, since the exchange infrastructure provides reliable, exactly-once file transfer.

Integrating Legacy and R/3 Systems

Now that the third-party and legacy systems communicate through the SAP Integration Server, you can now easily expand the scope of the exchange infrastructure.

Let’s assume that some of the data collected from the materials movement in your warehouse (legacy) system is also valuable input for your existing R/3 4.6C system. You can easily transform the information to feed it into your R/3 system.

The clear benefit of using the exchange infrastructure is that you use the same (now-familiar) tool to define all the needed transformations, and by concentrating integration-relevant knowledge in a central location, you reduce the complexity of the overall landscape and ease future maintainability. What’s more, you improve data consistency across systems by distributing the same data to multiple recipients all at once, in contrast to multiple point-to-point connections in several steps over different systems.

To extend integration further, adapters allow technical connectivity to database systems or messaging products, and application-specific adapters provide connectivity to other packaged software products. Because it adheres to XML and open standards, the exchange infrastructure can easily connect to any products that also conform to these same standards.

These business scenarios highlight the benefits — from preloaded configuration knowledge (e.g., usable interfaces) to integrated monitoring capabilities — that go far beyond what many integration suites can achieve when existing applications need to be integrated.

Key Ideas Behind the SAP Exchange Infrastructure

SAP’s exchange infrastructure is based on the following principles:

There needs to be only one integration infrastructure for application-to-application integration (be it SAP or non-SAP) — it’s the same one that reaches out to business partners, and is the foundation of private exchanges as well as public marketplaces.

Only this approach will guarantee the flexibility you need to easily outsource work or readjust business processes across company borders. For instance, what if your own FI department has been responsible for paying your employees, but you now want to outsource this HR-related functionality? Using one infrastructure will make this transition much easier.

The information stored as shared collaboration knowledge is based on XML and open standards (XPath and Java for routing, XSLT and Java for mapping, WSDL/XSDL for Web services).

This makes it easy to share information with customers and partners. It also fosters the ability to provide/reuse this knowledge for partners and customers and for third-party and legacy systems, taking it well beyond pure SAP-to-SAP integration.

Although collaboration knowledge will be centralized, the infrastructure will support central and distributed execution.

For efficient integration management and administration, it is key that relevant information on integration (“collaboration knowledge”) is visible in a central place. This approach prevents you from having to delve into all connected systems to understand their dependencies. However, it is also critical to allow for distributed execution of this shared collaboration knowledge. To address this need, SAP will build these execution capabilities (in the form of the Integration Engine) right into any new SAP application, so they are inherently enabled to easily take part in a wider integration game.

The exchange infrastructure will deliver content on SAP-to-SAP integration, plus the potential for out-of-the-box integration of SAP components with other systems.

With SAP solutions, you will not only receive a technical infrastructure, but you also get the required semantics to easily implement integration among SAP and partner products.

Integrating a New mySAP Solution Into the Landscape

Let’s consider one more scenario: the integration of a new mySAP solution (e.g., SRM) into this landscape. These mySAP solutions will be built on top of the new exchange infrastructure, and therefore separate integration-relevant elements from the application code itself.

Suppose you want to integrate mySAP SRM into your landscape — specifically, a business scenario dealing with operational sourcing.1

In this scenario, the exchange infrastructure automatically handles, for example, mapping a demand in one system (SAP Enterprise Buyer Professional) to the RFQ that must be created in the second system (the Dynamic Bidding component). The exchange infrastructure is designed so that mapping and routing information is not buried within each participating application — it is centrally stored as shared collaboration knowledge, and is therefore easy to see, extend, and replace if necessary.


The business scenarios in this article represent only a small subset of what is possible with the SAP exchange infrastructure. In addressing the challenges of increasingly complex and heterogeneous — and often expensive — system landscapes, the exchange infrastructure offers not only a powerful integration solution, but also a unique approach to designing new applications to run more easily and efficiently in a heterogeneous world.

For more details on the benefits and technology behind the exchange infrastructure, and how you can begin using and even creating your own integration scenarios, see the articles by Sven Leukert and Christoph Wachter in this issue of SAP Insider. An in-depth review of the exchange infrastructure is also available in the white paper “Exchange Infrastructure: Process-Centric Collaboration” available at

1 Operational sourcing is designed to support procurement professionals, and help them more efficiently deal with unassigned demands (for example, a purchase request where the item is not in stock or the supplier cannot respond in time).

Matthias Haendly joined SAP AG in 1992 and is currently a Product Manager for the SAP exchange infrastructure within mySAP Technology Product Management. Prior to this he worked on topics ranging from application development (Warehouse Management, Employee Self Service) to implementation tools (Accelerated Data Transfer and Best Practices/Preconfigured Systems) in positions such as developer and manager at SAP’s offices in Walldorf, Germany, and Palo Alto, California, USA. Matthias holds a master’s degree in Business Administration and Engineering from the Technical University of Karlsruhe, Germany. He can be reached at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!