Erp on the Wire

ERP ON THE WIRE

Enterprise Resource Planning Applications and Their Effects on the Network

CONTENTS

Introduction *

ERP Architecture *

Two-tier Implementations *

Three-tier Client/Server Implementations *

Transaction Flows and Volumes *

Looking at the Numbers *

Deploying Throughout the Enterprise *

Local Area Network Performance *

Wide Area Network Performance – T1 *

Wide Area Network Performance – 56Kb *

Wide Area Network Performance – 28.8Kb *

Putting the Results in Perspective *

Conclusions *

How Ganymede Can Help *

Introduction

"In the beginning God created the heavens and the ERP." – ORACLE 1:1

Enterprise Resource Planning (ERP) applications might not have had divine origins, but there is little doubt that somewhere, right now, a business or technology professional like yourself is praying for a successful ERP deployment.

As the name implies, ERP software is a set of applications that ultimately are relied upon to automate and integrate many or all functions of an enterprise. Common components include Finance modules, Human Resources software, as well as Manufacturing and Logistics applications.

After a successful roll out, ERP applications offer a variety of returns on the initial investment. Benefits might include more efficient business processes, tighter cost controls, and better customer service. However, these gains do not happen overnight. ERP applications are notoriously complex and usually require extensive customization. Recognizing these gains in your enterprise will require significant investments in time and money. Business processes may need to change, and users will need time to become efficient in using the new system.

In the middle of planning for and making these changes, there is one item that often gets overlooked: The network. "Systems" people spend a good deal of timing sizing servers and figuring out how many users they can support. "Desktop" folks plan for the software distribution on the client side. Department heads discuss when and how their people will be trained to use the new application. In many cases it is simply assumed that the network will handle this application just like it handles every other application.

Is this a fair assumption? Do ERP applications behave like other network applications? The answer to both questions is - No!

In a 1999 Computerworld cover story article entitled: ERP Pioneers, Keith Bearden, CIO of A-dec Inc., described some of the challenges he faced when he was tasked with addressing the performance issues associated with an ERP application which A-dec had recently purchased and deployed. It took about six months to fix the performance issues during which time they changed databases and performed server and network upgrades. Another six months was spent redesigning business processes and training end users – doubling the cost of the project. Mr. Bearden was quoted as saying: "We lost a lot of business, because [workers] didn’t understand it, and the performance was so bad."

In this White Paper we will discuss the behavior of ERP transactions and the crucial role that the network plays in delivering acceptable levels of performance to the end users. We will detail the potentially dramatic performance impact associated with running these applications across slower, higher-latency links and demonstrate why an up-front analysis of network performance is critical.

ERP Architecture

ERP applications are most commonly deployed in a distributed and often widely dispersed manner. While the servers may be centralized, the clients are usually spread to multiple locations throughout the enterprise.

Generally speaking, there are three functional areas of responsibility that is distributed among the servers and the clients. First, there is the database component – the central repository for all of the data that is transferred to and from the clients. Then, of course, the clients – here raw data gets inputted, requests for information are submitted, and the data satisfying these requests is presented. Lastly, we have the application component that acts as the intermediary between the client and the database.

Where these components physically reside and how the processes get distributed will vary somewhat from one implementation to the next. The two most commonly implemented architectures are outlined below.

Two-tier Implementations

In a typical two-tier architecture, the server handles both application and database duties. The clients are responsible for presenting the data and passing user input back to the server. While there may be multiple servers and the clients may be distributed across several types of local and wide area links, this distribution of processing responsibilities remains the same. Figure 1-1 below provides a simple illustration of a two-tier implementation.

Three-tier Client/Server Implementations

In three-tier architectures, the database and application functions are separated. This is very typical of large production ERP deployments. In this scenario, satisfying client requests requires two or more network connections. Initially, the client establishes communications with the application server. The application server then creates a second connection to the database server. Figure 1-2 illustrates this type of implementation.

Transaction Flows and Volumes

So far, this all looks pretty unremarkable, right? We have clients talking to servers, servers talking to other servers, no big deal… After all, in the vast majority of cases, there are several other applications already in place that are doing similar things in terms of transactions flows long before the ERP application enters the picture. There are PC, Mac, or UNIX clients talking to web servers, sending and receiving email, transferring and printing files, running legacy host-based applications, etc. etc.

Pay attention now, we’re getting to the good part! It isn’t the pattern of the transaction flows that we are worried about here. It is the shear volume of constant back-and-forth transactions traveling between the client and the server(s). On a high-speed, low-latency link, this may not present a problem. In fact this is why performance problems may not surface until after the application roll out is well underway. During the initial development and pilot testing of the system, the clients and the servers are often sitting on an isolated network or a single subnet. In this environment, the end-users may experience no performance problems whatsoever. But what happens when the application gets rolled out to other buildings on the campus, branch offices, or remote users?

Looking at the Numbers

So how much client to server interaction are we talking about here? Well, keep in mind that most ERP applications are customized for each individual customer, so the results you see will in all likelihood be unique to your organization. But let’s try to put things in perspective. In building Application Scripts that emulate real application transaction flows, Ganymede Software has done extensive analysis of how various applications perform "on the wire." Here are some of the results we have observed.

As a baseline, let’s start with a typical network transaction such as sending an email message using SMTP (Simple Mail Transfer Protocol). From the network perspective, this type of transaction will result in about a dozen "sends" of data to and from the email client. By "send" we mean a transmission of data that is initiated by either the client or the server. So how does this compare to a typical ERP transaction? Here are some sample transactions from the top five ERP applications and the number of sends associated with those transactions:

What’s going on here? Why are there so many exchanges taking place over the wire? Keep in mind that ERP applications and the individual transactions themselves can be quite complex. A single transaction such as adding an inventory item may require the end-user to fill out several forms of information. As each form in completed, data is transmitted back and forth across the network. Each of these forms has several fields that must be filled in. This is done by typing in text or perhaps selecting an item from a drop-down menu. In some cases we have observed that simply displaying these menus or even tabbing from one field to the next results in data being transmitted between client and server.

Note the difference in the traffic flows between two-tier and three-tier environments. Three-tier environments provide unique performance management challenges due to the number of variables in the end-to-end equation. When end-users complain of poor "application" performance, isolating the problem to a particular server or network connection can be a difficult task.

You are likely to find that the behavior of these transactions on the network is quite unlike anything else you have ever seen. If you were under the assumption that ERP applications behave like any other application on your network, you can throw those assumptions out the door! Keep in mind that the numbers listed above are representative of a single transaction being executed by a single user. Imagine what will happen as the application scales and dozens or hundreds of users are executing a mix of these transactions simultaneously across an already busy network.

Armed with this information, let’s take a stab at answering the question that was raised previously: What happens when the application gets rolled out to other buildings on the campus, branch offices, or remote users?

Deploying Throughout the Enterprise

The test results in this section were generated using Chariot from Ganymede Software Inc. and The Cloud from Shunra Software Ltd. Chariot was used to emulate the network flows and volumes associated with a typical ERP transaction. The Cloud was used to emulate several different WAN environments. In each of the tests below, we used Chariot to emulate the "Add Employee" transaction listed in the above table. This transaction is comprised of 242 sends between the client and the server. We executed this transaction 10 times during each test.

From an overall performance perspective, the Add Employee transaction could be described in the following manner:

Total transaction time = Client data entry time + Server processing time + Network transmission time

If you take the total amount of time needed to complete this transaction and remove the server time and the client time from the equation, you are left with the network transmission or response time. Regardless of how fast the server can run the application and look up data or how fast the user can type, the network component will remain fairly constant unless the makeup of the network itself or the traffic volumes change. Since the subject of this paper is the network component, our tests focus on the network response time.

Local Area Network Performance

For our first test, we used Chariot to emulate the Add Employee transaction over a 100Megabit LAN connection. Here are the results:

Wide Area Network Performance – T1

Next, we used The Cloud to emulate a T1 link between the client and the server. The same test yielded the following results:

So we jumped from 6.2 seconds on our LAN test to 10.5 seconds on the T1. At first glance, that doesn’t look too bad. But let’s examine this scenario in more detail. In this test, we are simulating a user who had an "empty" T1 all to himself – no other traffic and no other users. In reality, this is a shared resource and each user will only get a small piece of the total available pipe. So while 10.5 second response times are theoretically possible, perhaps during off-peak times, this is not a realistic expectation for day-to-day production transactions.

Wide Area Network Performance – 56Kb

For our third test, we executed the same transaction over a simulated 56Kb link:

Once again, this test assumes that the pipe is empty and that a single user has access to the full resource. In reality, this starts to give you a little better feel for what you might expect as a user on a shared T1 line. Our 6.2 seconds of network time for each transaction has now climbed to close to 40 seconds.

Wide Area Network Performance – 28.8Kb

To satisfy our curiosity, for our final test we simulated a 28.8Kb dial-up link:

This test demonstrates the type of response times that a user could expect if they were accessing the application over a dial-up modem link. Our maximum response times are now over 80 seconds. A user on a busy T1 might expect to see similar results.

Putting the Results in Perspective

Let’s think about this from the perspective of the end-user of the application sitting at the other end of that 56Kb link. They call the help desk and complain about performance. Help desk personnel PING the server and PING the end-user. In both cases they get response times that are well within reason, perhaps 100ms. The conclusion is that this isn’t a network problem and the trouble ticket gets handed over to the "Systems guys." A single PING simply does not tell the story here; in fact it can be very misleading. The reality of the situation is that for each transaction, the network is introducing at least 40 seconds of delay.

Another key point: In our tests, we were assuming "clean" Wide Area Network connections. In the real world there are any number of anomalies that might occur throughout the course of the business day: Congestion, packet loss, out-of-order packets, duplicates, fragments, bit errors, etc. Any of these conditions will adversely impact the results that we have shown here.

Lastly, let’s not overlook the fact that the transaction that we tested with had only 242 sends. Some of the transactions that we have analyzed have over four times this number.

Conclusions

1. ERP applications and transactions are probably unlike anything else that you have running on your network. It is not safe to assume that the network will handle them well.
2. Every ERP deployment is different. The application modules are customized and the architecture of the system and distribution of computing resources will be unique to your environment.
3. It is critical to understand how your application performs on the network before beginning enterprise-wide deployment.
4. Test your network in advance to understand how these applications will perform and what impact they will have on existing applications. Pay particular attention to WAN links and heavily utilized LANs.
5. The location of computing resources may have a significant impact on how the application performs, particularly in three-tier environments. Understand the traffic flows between the client and the server as well as the server-to-server communication flows.

How Ganymede Can Help

Ganymede Software’s family of performance monitoring and management solutions can take much of the guesswork out of ERP deployments and help eliminate surprises once the application begins to scale.

Using Chariot, you can now answer pre-deployment questions such as: "How well will this application run on my network?" or "What will this application do to the response time of existing applications running on my network?" Chariot provides a simple, yet scaleable way to emulate a single user, or hundreds of users, running a variety of applications and transactions to and from any point on your network.

When a performance problem occurs, Chariot allows you to immediately isolate whether or not the problem is network related. This can dramatically reduce the time, effort and expenses associated with troubleshooting problems and provide an even bigger payoff in terms of user productivity gains.

Since ERP application performance is critical, many corporations have invested in traffic queuing technology and prioritization tools in an attempt to provide end-users with a guaranteed Quality of Service (QoS). Chariot provides the means to verify that these technologies are working correctly in your environment and the performance data you need to "tune" end-to-end performance.

Since every ERP application is unique, Ganymede has developed a tool that can provide Application Scripts that are customized to match your environment. Application Scanner captures application transaction flows and automatically produces Application Scripts that will precisely emulate the way your application performs.

ERP applications can help your organization improve efficiency, reduce costs, and realize dramatic improvements in customer service. With proper up-front planning your implementation will be a success. Good luck!

For more information on Ganymede’s Enterprise Performance Management solutions, please visit our web page: