Essential ERP—Its Underpinning Technology
P.J. Jakovljevic - September 5, 2005
Originally published - December 29, 2000

1. Introduction
2. ERP Hardware
3. Internet/Intranet Architecture as a Latest Trend

Introduction

Enterprise resource planning (ERP) software is a set of applications that automate finance and human resources departments and help manufacturers handle jobs such as order processing and production scheduling. ERP began as a term used to describe a sophisticated and integrated software system used for manufacturing. In its simplest sense, ERP systems create interactive environments designed to help companies manage and analyze the business processes associated with manufacturing goods, such as inventory control, order taking, accounting, and much more. Although this basic definition still holds true for ERP systems, today its definition is expanding. Savvy ERP users, increasing customer expectations, changes in manufacturing requirements, and technology's relentless pursuit for innovation are just some of the forces reshaping the definition of ERP. In today's dynamic and turbulent business environment, there is a strong need for organizations to become globally competitive. The survival guide to competitiveness is to be closer to the customer and deliver value-added product and services in the shortest possible time. This, in turn, demands integration of the business processes of an enterprise, which is the stronghold of ERP.

ERP's Underlying Information Systems Characteristics

It is impossible to devise an ERP system without sophisticated information technology (IT) infrastructure. ERP is the epitome of inseparability of business and information technology. Most IT-based descriptions of ERP systems state that these systems exhibit the following characteristics:

  • They are based on distributed open systems or, in today's jargon, 'client/server' architecture. This is in marked contrast to yesterday's material requirements planning (MRP) systems that were mainframe or minicomputer-based on proprietary computing architectures, or to stand-alone microcomputer (PC) based systems.

  • They are based on distributed relational database technology. This means the database software must support multiple copies of a production database that are transparent to the user anywhere around the globe. In addition, database access would be through 'standard' structured query language (SQL) inquiries. Furthermore, the database management system (DBMS) should be an integrated design with the application software (e.g., manufacturing, distribution, order entry, procurement, etc.). Only high-end DBMSs can provide the demanding support needed by ERP software. IBM DB2, Oracle, Informix, and Microsoft SQL Server can support most of ERP systems today. Certain DBMSs ‘row-level locking’ and some ERP vendors demand that feature. Until recently, row-level locking has not been a feature of Sybase. Not all vendors have ported their ERP software to be used on all of the most commonly used databases. The market is continuously changing in that regard. As a general guideline, Oracle and Informix have been a preferred choice at the high end of the ERP market, while SQL Server has been prevalent at the medium end.

  • They are based on fourth-generation (4GL) software code, which is in contrast to the third-generation languages, like COBOL, which were used to program older MRP systems. Within the last three years, object-oriented programming (OOP)/componentization has been transitioned from 'nice to have, but not necessary' to 'highly desirable' feature.

  • They possess a graphical user interface (GUI), which is the interface the computer terminal user sees and interacts with in utilizing an application program. GUI refers to an icon-based 'point and click' screen design as initially popularized by Apple's Macintosh and then made ubiquitous by Microsoft's Windows. This is in contrast to the character-based screen ('green screen') that has been the mainstay of the computer user's world for decades. GUIs provide the benefit of requiring much less training for the user to become proficient, and they have been shown to greatly increase user productivity over their predecessors.

  • They are enterprise-wide, and support multi-plant global operations. In addition, the integration is expected to continue its expansion to other vital functions within the enterprise (e.g., product data management, manufacturing execution system, etc.) as well as to the entire global supply chain (customers' and suppliers' systems).

 

ERP Hardware

Incremental improvements in IT and the drastic decline in computer prices have made it possible for smaller enterprises to consider acquiring an ERP system. ERP software applications are nowadays possibly the most demanding software in terms of hardware requirements, being a high-end, mission critical application that should provide exceptional scalability in order to address the needs of corporate giants (often with over $100 billion [USD] in revenue). Typical RAM sizes would range from minimum 1 GB to several dozen GB for larger installations. The disk size requirements would be equally very large, often starting from several dozen GB—typically around 100 GB of disk space. The mission-critical nature of the application demands several log files to be maintained, which forces larger disk sizes. These large disks must be high-speed and 'highly available' by way of redundancy measures such as redundant array of independent disks (RAID).

ERP OS

ERP applications also require a high-end operating system that supports multi-tasking, multi-user application and multi-threading to support high performance. To provide scalability, the operating system should support high-end processor features such as 32-bit support or higher, and symmetric multiprocessing (SMP) support. Leading edge operating systems that are nowadays used in ERP applications are high-end Unix versions (Sun Solaris, HP-UX, Dec-Unix, IBM AIX), Windows NT, IBM OS/400, and IBM MVS (with Linux making its first steps onto the ERP arena). Unfortunately, not every ERP vendor ports its software to every operating system.

There is no hard-and-fast rule for identifying an optimal operating system for an ERP implementation. As a general guideline, high-end Unix systems have been a preferred choice at the high end of the ERP market, while Windows NT has been prevalent at the medium end (approximately 50 percent of the mid-market share). With continued enhancements Windows NT/2000 is expected to become a serious contender also in the high-end market segment in the future.

ERP Architecture

From an architecture standpoint, first ERP software packages were originally written in a mainframe computer environment. In that setup, the mainframe represents the brain, while so called 'dumb terminals' allow the user only to access and input data. Since a dumb terminal is a mere combination of a keyboard and a terminal, it cannot process information itself.

Personal computers are nowadays powerful enough to take on some of the processing tasks that used to be performed solely by mainframes. When PCs are combined with larger computers - either mainframes, minicomputers, or PC servers - the system is referred to as a client/server platform.

'Client/server' means that the processing of work is divided between two computers. The 'client' is the computer on the desktop, which performs display and some logic functions (e.g., the Windows GUI), while the 'server' is the more central computer that contains the database and application programs (see figure 1).

Figure 1. Two- and Three-Tier Client/Server Architecture Approaches

Client/server architecture, or distributed computing, is the prevalent choice of many companies today for several reasons. First, using PCs instead of dumb terminals creates an increase in computing power. Graphic processing is highly CPU intensive and is impractical to perform at a central computer. Hence, it became necessary to offload that processing to PCs. Second, overall system speed is increased due to the possibility of also using distributed databases. Furthermore, hardware costs are considerably lower compared to using a mainframe system.

The primary strategies for implementing client/server are two-tier, three-tier/n-tier, and Internet/intranet. The concept of tiers provides a convenient way to group different classes of architecture. Figure 1 illustrates the difference between two-tier and three-tier.

In a two-tier approach, the client machine connects to a single server machine. Usually the server controls the central database while the client controls the user interface. The main difference between the two is that the server responds to requests from many different clients, while the clients usually initiate the requests for information from a single server. Data is managed by a dedicated database to improve multi-user performance.

Two-tier designs usually locate business logic with the data server to centralize control and management. The designer decides how much of the processing logic should be implemented at the client and how much at the server. If most of the work is done at the client PC, it is called a 'fat client' application. Conversely, a 'thin client' application means that most of work is done at the server.

A three-tier application adds a third program to the mix, usually a database, in which the server stores its data. The business logic can be split onto many computers to improve reliability and spread the processing load. In a three-tier approach, the client machine controls the user interface and some processing logic, an application server manages the enterprise business application processing, and one or more enterprise servers manage the corporate database. This approach aids management of version releases and the enterprise business rules. Most current leading ERP applications are built with three-tier architecture.

Three-tier is the fundamental n-tier architecture. N-tier architecture splits the processing load for large applications by distributing pieces of the program onto multiple servers. By definition, n-tier applications can be broken into modules on multiple computers. Once the modules are put onto different computers, each computer and module can be optimized for a specific use, i.e., database, business logic, or user interface. Then the networked computers can share components with other computers and applications to eliminate redundancy and further optimize performance. In some n-tier scenarios, modules can be relocated to improve network performance for remote locations without compromising application integrity.

N-tier architecture allows an unlimited number of programs to run simultaneously, send information to one another, use different protocols to communicate, and interact concurrently. This allows for a much more powerful and scalable application, providing many different services to many different clients. It also contains a number of serious caveats that create complexity problems in design, implementation, performance, and load balancing. Many technologies exist that add to this complexity including common object request broker architecture (CORBA), enterprise JavaBeans (EJB), distributed common object model (DCOM), and remote method invocation (RMI).

Generally, if using a distributed-object architecture allows a customer to write programs that are faster, larger, more powerful, and more robust, then it is definitely worth the effort. Since customers have been increasingly realizing that architecture plays a key role in how quickly vendors can implement, maintain, expand/customize, and integrate their products with other vendors' modules, ERP products developed or enhanced within the last three years incorporate object-oriented (componentized) development environments, as well as n-tiered architectures.

 

Internet/Intranet Architecture as a Latest Trend

Client/server technology relies on robust communications between the machines that are involved. Local area networks (LAN) and wide area networks (WANs) become an expense and a management headache for most companies. Moreover, updating software versions, particularly on the numerous distributed PCs becomes an almost unsolvable problem. Many IT departments are considering moving toward Internet/intranet technology as a solution.

In the Internet/intranet approach, communications utilities provide the wide area communications backbone. PCs merely communicate the universal resource locators (URL) to reach the servers they need help from. Software coded in the Java language that runs on the PC clients gets downloaded when needed, ensuring that it is always the latest version. With an Internet-only ERP system in place, client-side software upgrades become unnecessary, browser-based applications significantly simplify the training, and tying together far-flung locations of an enterprise becomes simpler too. Of the leading ERP vendors, PeopleSoft and Oracle are the biggest proponent of this architecture approach, while Lawson Software is leading the pack of mid-market players.

Miscellaneous Technologies

It is a common situation that companies implementing ERP solutions have multiple locations of operation and control. Hence, the online data transfer has to be done across locations as well as between business partners in a supply chain. To facilitate these transactions, some other important enabling technologies for ERP systems are workflow, workgroup, groupware, electronic data interchange (EDI), Internet, intranet, data warehousing, etc.

Summary

Today's ERP systems are required to address more than the processes taking place within the walls of an enterprise. They must be able to address the players and processes involved in extended enterprise—the people and partners that the manufacturers collaborate and coordinate with in their supply chains. In short, the E in ERP will no longer be representative of just the internal enterprise. Rather, it will transcend the walls of the traditional manufacturing environment to encompass the extended enterprise. Therefore, the product architecture is going to do much more than simply provide the functionality, the user interface, and the platform support; it is going to determine whether a product is going to endure, whether it will scale to large number of users, and whether it will be able to incorporate emerging technologies, all in order to accommodate increasing user requirements.