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.

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.

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. Transaction Flows and Volumes So far we have seen 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. 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.

Written by :

delvin