Вы находитесь на странице: 1из 17

DB CR DB

cc .R ec . Re ve nu
CR

PART 3

nu

es

In re dep qu e ire nd m en en t t

Cr ea VL te 01 de N liv er y

41 3

sa Do le m re es ve tic nu es
DB CR

In ve s

Readings on Enterprise Resource Planning


Ex M ec D ut 01 e M RP
DB

In v ch en an tor ge y Fi pr nis od he uc d t
CR

Preliminary Version - send comments to pml@hec.ca

In ve so nto ld ry pr ch od an uc ge t

R co aw ns m um ate pt ria io l n

tm

en ts

ut

In ve st DB m
CR

pu t

en ts
DB

Ca sh
CR

Fa c pr tory od o uc ut tio p n

DB

Ra w GR /IR
CR

CR

at

Fi pr nis h o DB d ed uc ts
CR

DB

M pu Co E5 rc nv 9N ha er se t to or de r
Pu r or cha de se r

o DB raw ns.
CR DB

o ro DB utp d.
CR

ut

DB

GR

/IR

m Raw at er ia C l

CR

C pr Con O15 od fi uc r m tio n

41 30

DB

Ac c. Pa y. C

Po M s IG re t go O ce o ip ds ts

40 5

Ca s
t

Go od sr ec ei p

Pr od or uct de io r n

DB

Ac c. Pa y. C
R DB

ERP System and Enterprise Architecture

CR

Po M st IRO in vo ice

40 6

Po s

t p F-53 ay m en

40

M pr od Re D0 l uc e a 7 tio se

pr Ma CO od ss 4 uc re 1 tio lea n se or de r

41

103

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

In v ch en DB an tor ge y

DB

CR

Nitin Kale (University of Southern California)


CR

Chapter Outline
This chapter introduces the system architecture that ERP systems are based upon. Understanding the system architecture in addition to ERP functionality (covered in other chapters) will provide a thorough understanding of ERP technology and how it benefits enterprises.
Ca sh en ts In ve st DB m
CR DB CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

ERP systems are dependent on the consistent storage of large amounts of data: master and transactional data. An enterprise class relational database is used for this purpose. Examples of such databases are Oracle database, Microsoft SQL Server and IBM DB2. This data is processed by numerous programs within the ERP software and the results are presented to the end user through some user interface. The architecture that supports the connection between the database, processing, and presentation is called Client/Server architecture. Most current ERP systems utilize a relational database for the data layer in three-tier client/server architecture. The logic or processing layer is the second tier in such architecture. Herein lays the implementation of business logic, business processes, business rules, authentication and user management. The presentation layer forms the third tier. This is usually in the form of a user interface on a multitude of devices ranging from workstations to mobile devices. As users interact with the presentation layer, data is transmitted, read, written, deleted or updated in the data layer. The orchestration of the read/write/ update is done by the logic layer. In recent years, new technologies have developed that make ERP software less monolithic and more flexible. As the amount of data stored in the database and the number of sources of data increase, there is a need for efficient storage and retrieval of corporate data from a business intelligence perspective. Data warehouses have evolved to handle this explosive growth. Finally, advances in embedded and in-memory analytics are providing up to the minute business intelligence.
Ex M ec D ut 01 e M RP
Ra w

Figure 1 - Client Server concept

cLient

network

30

The relationship between the client and server is many to many i.e. a client can request services from many servers. A server can serve many clients. The actual computer or device that the client and server reside on is not critical to the discussion of architecture. The client and server are usually hosted on separate computers but they could be on the same computer.

41 3

41

Pr od or uct de io r n

CR

serVer

Go od sr ec ei p

8.1 What is Client/Server Architecture?


sa Do le m re es ve tic nu es

R co aw ns m um ate pt ria io l n

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

104

CR

Po s

In broad terms, a client is a process that makes service requests to a server. A server, therefore, is a process that responds with the requested service to a client (Figure 1). The third component of this architecture is the network. The network can provide communication to multiple servers that service multiple clients.
DB

The overall application logic that the client/server architecture is designed to support has several components that can be distributed across clients and servers. These components are: Presentation Logic, Processing Logic and Storage Logic (Fig 2). Presentation Logic: The end user interacts with the presentation logic tier.
R

Po M st IRO in vo ice

CR

at

DB

8.2 Components: Presentation, Processing, and Storage


/IR
CR

GR

40

Client and server processes are separate and autonomous even though the request is made by the client. The sharing of the processes between a client and a server is the basis for defining thin and fat clients (these correspond to fat and thin servers respectively). A thin client has minimal processing responsibilities, which implies that the corresponding fat server does the majority of processing. On the other hand, a fat client takes on a larger load of processing. The increase in inexpensive desktop processing has helped popularize fat clients. On the other hand, web based client/server architectures are pushing the thin client (sometimes mobile) paradigm. The client is often called the front-end or front-end application. The server is called the back-end application. The network provisions the transmission of data between clients and servers. A communications middleware it the software that orchestrates the communication over the network. The middleware plays an important role whereby client and server computers can run different operating systems, yet seamlessly channel requests and responses.
Pu r or cha de se r

M pu Co E5 rc nv 9N ha er se t to or de r

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

t p F-53 ay m en

40

M pr od Re D0 l uc e a 7 tio se

o DB raw ns.

Chapter 8: ERP SYSTEM ARCHITECTURE

DB

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Ca sh

41 3

In ve st DB m

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

Processing Logic: This component receives user input from the presentation logic component, validates the data, and applies
en ts
DB

CR

41

It is responsible for formatting the data, rendering the user interface, presenting the data and also accepting user input. These tasks are device dependent. Examples of devices include desktop computers, laptops, notebooks which all have a keyboard and mouse for input. Also included are mobile devices such as smart phones that have multi-touch screens which require different rendering and input logic compared to single touch screens.
Fi pr nis od he uc d t
CR

In v ch en DB an tor ge y

Storage Logic: This component is responsible for handling data retrieval and storage (in the physical storage devices) requests from the processing logic component. The database management system (DBMS) is synonymous with storage logic.

Figure 2 - Components to a Client Server System Processing Logic

PRESENTATION LOGIC

Storage Logic

User input Data Output Rendering the user interface

Business transactions and rues Communicating with storage logic Managing and balancing load Input/Output processing

DBMS Data storage Data retrieval Read/write/update - Physical storage device

Ex M ec D ut 01 e M RP

8.3 N-Tier Approaches to C/S

Two-tier CLient SerVer Architecture Three-tier

Po M s IG re t go O ce o ip ds ts

It is important to note that the three logic components can be distributed across multiple tiers of an n-tier client/server system. In general, the presentation logic resides on the client. Storage logic resides on the server, which is usually a database server in close proximity to the data itself (physical storage). This leaves the processing logic to be placed on either the client or on the

M pu Co E5 rc nv 9N ha er se t to or de r

In re dep qu e ire nd m en en t t

server. The processing logic server is separate from the storage logic server. Application partitioning is the process of writing programs that are distributed onto clients and servers as needed to maximize performance and data security. Partitioning the processing logic leads to two, three, and n-tier environments.
Pu r or cha de se r

40

30

GR

CR

OPTION 1
m

/IR

OPTION 2 CLient (fat)


Po M st IRO in vo ice

CLient (thin)

Ra w

at

DB

sa Do le m re es ve tic nu es

Processing Logic

R co aw ns m um ate pt ria io l n

In ve so nto ld ry pr ch od an uc ge t

Storage Logic

Storage Logic
GR /IR

Ac c. Pa y. C

Processing Logic

SerVer (thin)

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

105

CR

Po s

t p F-53 ay m en

SerVer (fat)

40

Presentation Logic

Presentation Logic

DB

CR

40

Figure 3 - Option for Two-Tier C/S Architecture: Thin Client vs. Fat Client

Go od sr ec ei p

Pr od or uct de io r n

CR

M pr od Re D0 l uc e a 7 tio se

the majority of business rules. This will require communication with the storage logic to retrieve additional data. Business transactions are processed in this component. Results from the processing are written to the storage logic.
o DB raw ns. C
CR DB

DB

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

CLient SerVer Architecture


CR DB

m Raw at er ia C l

41
SERVER
Po M st IRO in vo ice

0
t

o DB raw ns.

In v ch en DB an tor ge y

CR

Figure 4 - Three-Tier C/S Architecture


Pr od or uct de io r n

CR

Three-tier Architecture
CLIENT
Ca sh

41 3

SERVER

SERVER

en ts

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

User Interface

Application Server

Database Server

N-Tier CLient SerVer Architecture


Figure 5 - N-Tier C/S Architecture

Ex M ec D ut 01 e M RP

CLIENT

SERVER Processing Logic Web Server

M pu Co E5 rc nv 9N ha er se t to or de r

N-tier Architecture
SERVER
Pu r or cha de se r

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

User Interface

40

Presentation Logic

30

Processing Logic Application Server

8.4 3-Tier C/S in ERP Systems


As depicted in Figure 4, three-tier architecture has two server layers to manage the processing and storage logic. Generally, the processing logic resides on an application server that executes most application programs. The drive towards three and higher tiered architectures is driven by flexibility and scalability. By delineating the tiers, it is easier to swap out any one tiers technology with a newer one without having to rewrite the code for the other tiers. Scalability is achieved by introduction of multiple application servers.
Ra w m
R co aw ns m um ate pt ria io l n sa Do le m re es ve tic nu es
DB

Go od sr ec ei p

Presentation Logic

In ve st DB m

Processing Logic

DB

CR

CR

41

Storage Logic

Storage Logic Database Server

A transaction processing monitor is used to monitor the load on an application server. Load balancing is thus achieved amongst several application servers as needed.
/IR

GR

at

The three-tier architecture is the main stay of ERP systems where thousands of end users may be accessing the application concurrently. Figure 6 shows a typical schematic of an ERP system.
Ac c. Pa y. C

CR

DB

CR

40

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

106

CR

Po s

t p F-53 ay m en

40

M pr od Re D0 l uc e a 7 tio se

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

Figure 6 - ERP System Architecture


o DB raw ns. C
CR

m Raw at er ia C l

41

In v ch en DB an tor ge y

Ca sh

41 3

en ts

In ve st DB m

CR

DB

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

41

30

Pr od or uct de io r n

CR

Ex M ec D ut 01 e M RP

8.4.1 Database Tier for ERP Systems

R co aw ns m um ate pt ria io l n

In ve so nto ld ry pr ch od an uc ge t

Places the client requests in request queues, and then processes them in order.
R

Ac c. Pa y. C

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

107

CR

Po s

Before an ERP system is put into production, it must be implemented, configured, tested, and then deployed. Keeping the data of each phase of the implementation cycle separate from the other phases would require the use of multiple databases. This is inefficient and unnecessarily complicated. An innovative way to utilize the same database for all phases of implementation is to use a field (sometimes called client number) in all tables, making it a part of the primary key. A primary key is a field (or set of fields) that uniquely identifies each row in a table. In this way the configuration phase can use rows with client number 100 and the testing phase can use rows with client number 200.
Ra w m
sa Do le m re es ve tic nu es
DB

Go od sr ec ei p

Most ERP systems use a relational database to store data about their customers, vendors, materials etc. in hundreds of tables. This data is called master data. As the ERP system is put into production, every transaction that is saved (committed) to the database will update one or more tables. This data is called transactional data. As you can surmise, master data changes slowly, whereas transactional data changes rapidly, growing by large amounts depending on the volume of business.

M pu Co E5 rc nv 9N ha er se t to or de r

8.4.2 ERP Business Logic


The entire business logic resides in the application server. A dispatcher is the central control process. The dispatcher performs the following important tasks:
t

Po M s IG re t go O ce o ip ds ts

Each table of the database has rows of data for the configuration phase as well as the testing phase. They are identified by the client number field. The processing tier manages the database authorizations so that only rows with client number 100 will be seen by configuration personnel.
Pu r or cha de se r

In re dep qu e ire nd m en en t t

40

Interfaces with the presentation level. Manages the buffer areas in the main memory. Organizes all communication activities.

t p F-53 ay m en

40

Evenly distributes the transaction load among the work processes.

Po M st IRO in vo ice

CR

at

DB

Together with the operating system, manages the resources for the ERP application.
CR

GR

/IR

40

M pr od Re D0 l uc e a 7 tio se

DB

CR

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

In v ch en DB an tor ge y

Ensures proper lock management to maintain data integrity.


Ca sh

41 3

en ts

In ve st DB m

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

Figure 7 - SAP ECC Sales Order Transaction

DB

CR

41

Figure 7 and 8 show some sample UIs for ERP systems.

Ex M ec D ut 01 e M RP

M pu Co E5 rc nv 9N ha er se t to or de r

Pu r or cha de se r

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

30

Go od sr ec ei p

Pr od or uct de io r n

CR

Distributes the pending requests to the appropriately defined work processes.


DB

The client side user interface can be either a custom program or a web browser. Either way there is a rendering program that renders the appropriate look and feel of the UI on the client platform. Mobile apps have limited screen space so UIs have to be designed specifically for this limitation.
C
CR

GR

/IR

CR

Ra w

Po M st IRO in vo ice

CR

at

DB

40

R co aw ns m um ate pt ria io l n

sa Do le m re es ve tic nu es

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

108

CR

Po s

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

o DB raw ns.

CR

Dispatches the requests to available work processes. A work process is specialized to process exactly one request type.

DB

8.4.3 Presentation Tier

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

Figure 8 - Microsoft Dynamics CRM


o DB raw ns. C
CR

m Raw at er ia C l

41
Po M st IRO in vo ice

0
t

In v ch en DB an tor ge y

Ca sh

41 3

en ts

In ve st DB m

CR

DB

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

41

Ex M ec D ut 01 e M RP

M pu Co E5 rc nv 9N ha er se t to or de r

Pu r or cha de se r

In re dep qu e ire nd m en en t t

Go od sr ec ei p

R co aw ns m um ate pt ria io l n

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

109

CR

Po s

t p F-53 ay m en

Applications need to connect and communicate to a source of data over a network. The mechanism for orchestrating this is called database connectivity. The data source is generally a relational database; however it could be any other form of data, such as a text file. Middleware is the glue that binds all client server applications. Interoperability is the reason why middleware exists. One or more middleware solutions are used within n-tiered client server applications to facilitate this interoperability amongst dissimilar operating systems and components.
Ra w m
sa Do le m re es ve tic nu es
DB

GR

Several types of middleware are available. Here are some important ones as classified by Hurwitz (Hurwitz, 1998):
/IR

Asynchronous: In asynchronous communication, the client sends a message (request) to the server but does not wait for a response. Examples are email and file transfer. Middleware examples: Asynchronous remote procedure call (RPC): Client makes a request after establishing a point-to-point connection. Does not wait for response.

CR

at

DB

CR

40

8.5 Database Connectivity and Middleware ODBC, JDBC

Po M s IG re t go O ce o ip ds ts

40

30

Pr od or uct de io r n

CR

40

M pr od Re D0 l uc e a 7 tio se

DB

CR

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

In v ch en DB an tor ge y

en ts

Synchronous: Synchronous communication is used when a response is required by the client (in real time). Examples are chat and audio/video communications. Middleware examples:
Ca sh

41 3

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

SQL-oriented data access: Middleware that translates generic SQL requests into the database specific SQL. Synchronous RPC: Synchronous version of RPC

Figure 9 - Google Maps API in Action

Ex M ec D ut 01 e M RP

M pu Co E5 rc nv 9N ha er se t to or de r

Pu r or cha de se r

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

30

Object request brokers (ORB): Object-oriented sending and receiving of information.


CR

In ve st DB m

DB

CR

41

Go od sr ec ei p

Pr od or uct de io r n

Message-oriented middleware (MOM): Uses queues to store requests from clients, especially those that require multiple processing steps.
CR DB

GR

/IR

CR

Ra w

Po M st IRO in vo ice

CR

at

DB

40

R co aw ns m um ate pt ria io l n

sa Do le m re es ve tic nu es

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

110

CR

Po s

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

o DB raw ns.

CR

Publish/subscribe: Middleware that pushes information that subscribers have subscribed to.

From an ERP perspective, middleware is important because it allows data integration and application integration between one database and another. Application Programming Interface (API) is used to support interaction between two applications (or programs). The API is a set of routines, structures, classes and protocols provided by libraries and operating systems to simplify the creation of software applications. Think of it as building blocks that a programmer can put together to build applications. Database oriented middleware usually provides an API to access the database. An example of an API is Google Maps APIs. This gives developers several ways of including Google maps within their web pages either for simple use or with extensive customization. Several APIs are available: Google Maps API for Flash, Google Maps API for JavaScript etc. A developer could use the Google Maps AI for Flash to create an interactive map that shows buildings, departments, residences, services etc. on a campus map as seen in Figure 9 (Notre Dame Map, 2011).
C
CR DB

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

8.5.1 ODBC
In v ch en DB an tor ge y

41 3

Open Database Connectivity (OBDC) is an interface for accessing databases (both relational and non-relational). Similar to an API, it provides abstraction from operating system, database and programming language. ODBC drivers are used to translate the middleware commands into the DBMS specific commands. Changes in the database specification only require an update to the driver (ODBC - Open Database Connectivity Overview, 2010).
CR DB CR

In ve st DB m

CR

Cr ea VL te 01 de N liv er y

Java Database Connectivity (JDBC) is similar to ODBC. It is an API for the Java programming language (not language independent like ODBC) that allows any client program to access a database. Java applets can harness a JDBC driver (called adapter) to communicate with a relational database. It has gained popularity because Java is a network oriented language.

C pr Con O15 od fi uc r m tio n

8.5.2 JDBC

So far we have mostly discussed client server architectures for enterprises distributed over a local area network (LAN). However, since the early 1990s, the web browser is displacing specialized client user interfaces. The ubiquitous availability of browsers for desktop and mobile devices is driving this displacement. The time and cost of web development has gone down significantly. ERP vendors have responded with user interfaces that integrate the browser into their presentation logic layer. This poses some new challenges and opportunities.
C
CR

Ca sh

en ts

DB

CR

41

Figure 10 shows how a web-enabled ERP architecture may look.

Figure 10 - Web-Enabled ERP Architecture

Ex M ec D ut 01 e M RP

M pu Co E5 rc nv 9N ha er se t to or de r

Pu r or cha de se r

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

30

Go od sr ec ei p

Pr od or uct de io r n

GR

/IR

CR

In ve so nto ld ry pr ch od an uc ge t

The main difference between a web-enabled and a non web-enabled architecture is the inclusion of a web server. If a client requests a static web page (html), it will be served by the web server and displayed in the client browser. If the client request requires data retrieval from the database, the web server will use the processing logic to create a query, which will be sent to the database server. The results will be formatted for presentation and returned to the client.
Ra w m
R co aw ns m um ate pt ria io l n sa Do le m re es ve tic nu es
DB

The web server requires additional security, which is why the enterprise intranet is behind a firewall. In addition, a proxy server can be added to serve frequently requested pages (which are cached) without having to add load to the web server.
DB

Po M st IRO in vo ice

CR

at

40

Ac c. Pa y. C

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

111

CR

Po s

t p F-53 ay m en

40

M pr od Re D0 l uc e a 7 tio se

8.6 Web Based ERP Applications


o DB raw ns.

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

8.6.1 Web SerVices


In v ch en DB an tor ge y

In ve st DB m

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

Web services description language (WSDL) Simple object access protocol (SOAP)

Using Web services, one can convert an application into a Web application which can then be shared and consumed by others. The repository of Web services can be found at the Universal description, discovery, and integration (UDDI) business registration. An example of a Web service would be Amazon fulfillment Web service, which allows merchants to send orders to Amazon.com with instructions to fulfill customer orders on their behalf.
Ex M ec D ut 01 e M RP

Privacy and confidentiality breach: As users, enterprises, banks, and governments put personal and financial data on databases, there is a greater threat of loss of privacy and confidentiality. A breach in security can lead to theft, fraud, blackmail, financial hardship, and even national security risks. Human error: Accidental compromise or loss of data by humans is possible and not uncommon. Software bugs: Software is very complex and communicates with other software. This multiplies the probability of unforeseen bugs that can introduce unexpected and potentially damaging errors. Hardware failure: Although not avoidable, hardware failure does occur. Server administrators must have comprehensive backup and recovery procedures in place.
Pu r or cha de se r

There are two major advantages to Web services: Interoperability: Allows applications to exchange data easily Reusability: Web service can be consumed as needed without the need to rewrite code
In re dep qu e ire nd m en en t t

M pu Co E5 rc nv 9N ha er se t to or de r

8.6.2 SerVice Oriented Architecture (SOA)


We have discussed APIs as a way to facilitate interoperability. SOA provides a suite of services that can be consumed by other applications in a loosely coupled environment. Although SOA is often enabled using web services, it is not mandatory to do so. The benefit of the SOA approach to enterprise systems is that businesses can be more agile. They can respond quickly to changing market conditions by reducing the time to develop applications. Chapter 10 will discuss SOA in more detail.

GR

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

Cyber-security has emerged as a major concern in the client server model of ERP application development and deployment. Most applications we use today are based on this model, which can pose serious risk to security if not properly addressed. Data has to be secured from both accidental and intentional threats. Web based access to data, often through mobile devices, has made securing such systems more difficult.
R co aw ns m um ate pt ria io l n sa Do le m re es ve tic nu es
DB

Ra w

8.7 ERP Security

Ac c. Pa y. C

ut

pu t

Preliminary Version - send comments to pml@hec.ca

112

CR

Po s

t p F-53 ay m en

Authorization rules: Authorization rules restrict who can access what type of data, and what actions they can take on that data. They can also be applied at the application or operating system levels. Data administrators are responsible for creating and implementing these rules. They must also ensure that the rules are reevaluated from time to time to ensure their continued relevancy and efficacy.
Po M st IRO in vo ice

CR

at

DB

CR

Database security: All servers within the ERP system must be protected against intrusion, but the most critical is the database server. The physical server and data must be properly secured with access limited to a very high level of authorized personnel. Server and administrator passwords provide key defenses against attacks.
Go od sr ec ei p t

Po M s IG re t go O ce o ip ds ts

Security is not a single task that can fix threats and attempts. It is a multilevel, multipronged approach to securing all components in an ERP environment.

40

30

As the web takes center stage in ERP systems, the concept of loosely coupled yet interoperable application components has gained momentum. Web services are a set of protocols to support computer to computer interaction over the web through the use of XML and HTTP. XML stands for Extensible Markup Language. It is a markup language similar to html but with different goals. It is used to structure, store and transport data. The tags in XML are wrappers for data. The sender and receiver must have software to send, receive, and process the XML file. Many languages have been developed using XML.
CR DB CR

en ts

DB

Loss of system/services availability: Computer viruses, worms, and sabotage can all cause unplanned system downtime. Corporations and customers cannot afford system unavailability. Compromise of data integrity: At the core of a database is the integrity of data, which must be guaranteed at all times. A loss of this integrity can cause costly errors unless there is a backup and recovery plan.

Ca sh

41 3

CR

CR

41

Pr od or uct de io r n

There are several targets for data security threats the database, the network, the operating system (on both the client and server side), physical hardware, physical buildings, and users. Security threats could lead to the following potential crises in an enterprise:
o DB raw ns. C
CR

m Raw at er ia C l

41 40 6

/IR

40

M pr od Re D0 l uc e a 7 tio se

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

In v ch en DB an tor ge y

Figure 11 - Authorization Rule Matrix


Ca sh

41 3

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

Write Warehouse Manager Read ERP100 - John Update Sales Representant Delete
Ex M ec D ut 01 e M RP M pu Co E5 rc nv 9N ha er se t to or de r

Authorization for US

30

ERP USER

ERP PROFILE

In ve st DB m

ERP AUTHORIZATION

ERP AUTHORIZATION OBJECT

en ts

DB

41

Pr od or uct de io r n

CR

ERP OBJECT CLASS

CR

Materials Management

Authorization for CA No Authorization for MX Sales and Distribution

In re dep qu e ire nd m en en t t

- User supplied authentication: Password - User biometrics: Fingerprint or retinal scan - User possession: Magnetic card or similar Passwords need to be strong enough so as not to be guessed by a computer (before being locked out by the system defense). Basic guidelines for passwords are: at least 8 characters long, include alphanumeric and non-alphanumeric characters, should not be dictionary words, and should be changed periodically.
Ra w m

Go od sr ec ei p

R co aw ns m um ate pt ria io l n

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

113

CR

Po s

Encryption: Sensitive information such as personal information, financial information, social security numbers, credit card numbers, and other account numbers must be protected by encrypting them even if they are stolen from the database or during transmission. Encryption scrambles
sa Do le m re es ve tic nu es

Web security and privacy: ERP systems now have web access as the presentation logic. In the past, many ERP systems used customized client side user interfaces to avoid some web related vulnerabilities. But as web access has become the de facto standard, extra security measures have to be taken. The Web Server is usually protected behind a firewall. In addition, encryption can be used to encrypt all data that travels between the client and the server. Web servers should have the lowest possible number of ports open for communication.
CR

GR

/IR

Po M st IRO in vo ice

CR

at

DB

40

Network security: The network that connects the components of an ERP system must be secured as well. Routers can be monitored to identify attacks from specific clients. They can be configured to restrict access by client IP addresses, country and regions.
t

Po M s IG re t go O ce o ip ds ts

Authentication: Once a user has been assigned the appropriate authorization rule using the matrix above, he/she is assigned authentication to access the ERP system. There are three methods of authentication. One can also enforce a combination where two modes of authentication are required for high security access.

the data in such a way that humans cannot decrypt them, at least not without using supercomputers that would take days or months. A common encryption available is called Secure Socket Layer (SSL). The 128-bit version provides extreme high security by using a public and private key for locking and unlocking the encryption.
Pu r or cha de se r

40

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

An authorization table is maintained using users, their profiles, their authorizations, the objects, and classes of objects. Each profile can have many profiles. Each profile is assigned multiple authorizations. The authorizations allow
Fi pr nis od he uc d t
CR DB

specific type (read, write, update, delete) of access to the authorization object. The authorization object belongs to an object class. See Figure 11 to see the matrix of an authorization table for a user ERP100 named John.
CR DB

o DB raw ns.

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

In v ch en DB an tor ge y

Personnel security: Organizations routinely have controls in place to keep personnel from conducting fraud or sabotage. This applies to ERP system users as well. Apart from training users on security issues, it is also important to separate duties so that there is no conflict of interest and no single employee has full control over a process or system. Procedures for dismissal also have to include de-authorization from the ERP system. Data privacy controls have to be in place to prevent unauthorized people within a company from viewing information about others. In the health care industry this is critical, and is regulated by state and national laws.
Ca sh en ts In ve st DB m
CR DB CR

41 3

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

41

8.9 New Directions


In the past few years, some new developments have taken place in Enterprise Information Systems. Although the Client/Server architecture is same, the implementation and consumption of these services is seeing disruptive innovation. These types of innovations fundamentally improve upon a service or product in unexpected ways by providing a significantly lower cost of ownership, or by identifying a new customer base. Enterprise software companies and IT professionals have to be extremely vigilant of disruptive innovation because it can cause sudden shifts in their customer base and profitability. Ultimately their survival in the market will depend upon how rapidly they can adapt to change. A highly visible example of disruptive innovation is Netflix. Netflix revolutionized the video rental business a few years ago. It severely disrupted the traditional business model used by neighborhood brick and mortar stores such as Blockbuster for years. Netflixs monthly subscription model allows customers to order movies through a website, have them delivered to their homes and to keep movies for as long as they wish. As network bandwidth increased, Netflix added free streaming video service for their customers. This on-demand streaming video is another disruptive technology used by Netflix. Both the disruptive business innovation and disruptive technology innovation have left the competition playing catch up.
Pu r or cha de se r

8.8 Data Warehouses and Business Intelligence


A transactional system such as an ERP generates enormous amount of data on a daily basis. To keep the database size manageable, older data is archived periodically. What if you wanted to know the buying history of a customer for the past 10 years? Or the average price of a raw material for the past 5 years? You would need the entire data history of all master data and transactional data of your company. In addition to the data you already have, you may want to access data from data providers such as the stock market or demographic information. The challenge, therefore, is to collect and store data from multiple sources into one coherent structure based on which business analytics can be performed.
Ex M ec D ut 01 e M RP

M pu Co E5 rc nv 9N ha er se t to or de r

In re dep qu e ire nd m en en t t

GR

CR

Enterprise Data Warehouses aim at physically framing multiple sources of data (e.g., databases and other) in an architecture that requires the mapping of data from one or more operational data sources to a target database management system (DBMS) that supports the many decision making processes and business intelligence (BI) systems of an enterprise. (Inmon, 2005) Business Intelligence for ERP is the user-centered process of exploring data, data relationships and trends - thereby helping to improve overall decision making for enterprises. This involves an iterative process of accessing data (usually stored in the enterprise data warehouse) and analyzing it, thereby deriving insight, drawing conclusions, and communicating results to authorized users.
Ra w m
R co aw ns m um ate pt ria io l n sa Do le m re es ve tic nu es
DB

Po M s IG re t go O ce o ip ds ts

40

30

Go od sr ec ei p

Pr od or uct de io r n

Open ports are vulnerable to attack. Client side privacy cannot be ensured because websites often leave cookies for tracking purposes. These cookies can be used by other websites without the users knowledge. Individuals have to be vigilant in protecting their privacy.
Fi pr nis od he uc d t
CR CR DB

The database underlying the data warehouse is generally separate from the transactional database that supports the ERP. Data in the data warehouse is periodically extracted, transformed, and loaded from several data sources. Once in the data warehouse, the data is read-only from an end user perspective. A star schema is used to model a multidimensional cube where dimensional tables contain master data, and a fact table contains transactional data. Online analytical processing (OLAP) is a set of tools to slice, dice, and drill down into this cube to gain insight. You will learn more about data warehouses and business intelligence in Chapter 16.
DB

m Raw at er ia C l

41
Po M st IRO in vo ice

0 40 6
Ca s h

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

114

CR

Po s

t p F-53 ay m en

The ERP world, although stable and generally slow changing, is susceptible to disruptive innovation as well. Several new technology and business ideas are changing the traditional landscape of in-house ERP systems, which require huge investments in IT infrastructure and personnel. In addition to the cost of acquiring and maintaining hardware, software, and networking for ERP systems, there is also the tremendous cost of hiring, training, and keeping IT professionals to run such systems.
DB

CR

at

/IR

40

M pr od Re D0 l uc e a 7 tio se

o DB raw ns.

CR

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r Po M st IRO in vo ice

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Changes in software versions, operating systems, and DBMS versions require expensive upgrades and time commitment. In todays rapidly changing global economic environment, companies need to be more agile, requiring such changes to be quick and painless. In response to this need, cloud based solutions are emerging to capture a share of the ERP market.
Fi pr nis od he uc d t
CR

DB

2. Little or no IT infrastructure needed.


o DB raw ns. C
CR

m Raw at er ia C l

41 40 6
h

0
t

In v ch en DB an tor ge y

3. No upfront cost of system (servers and software) ownership. Low total cost of ownership (TCO).
Pr od or uct de io r n

4. Pay-as-you-go subscription model reduces risk of IT costs when business slows down. Low commitment. 5. A-la-carte model allows clients to pick and choose functionality as needed by business growth. 6. High reliability. 7. Access to expertise from solution provider. 8. Higher security, particularly for small businesses that do not have adequate in-house expertise. 9. Access from anywhere, at anytime. 10. Scalability. There are certain disadvantages to SaaS: 1. Businesses have to trust SaaS vendor to provide security, privacy, and confidentiality of corporate data. 2. Low control over customizing SaaS software to fit business needs. 3. SaaS for vertical market is still relatively rare. 4. Subscription costs can add up quickly especially in per-user model of payment.
C pr Con O15 od fi uc r m tio n

Ca sh

41 3

Should I buy a house or should I rent an apartment? The answer depends on many variables, and both options have pros and cons. A similar option has emerged in the ERP world where Software can be rented on-demand. Instead of making huge initial investments in IT infrastructure, a business simply subscribes to the software on a pay-as-you-go model. A monthly fee per user is assessed by the software provider. The software and its accompanying technology stack are hosted in the cloud. The business accesses this service over the Internet with little involvement in the maintenance and upgrade of the technology underneath the service.
en ts In ve st DB m
CR DB

Cr ea VL te 01 de N liv er y

CR

41

8.9.1 Software as a SerVice (SaaS)

CR

Ex M ec D ut 01 e M RP

Here are some important advantages to SaaS: 1. Short implementation time.

M pu Co E5 rc nv 9N ha er se t to or de r

Several disrupters have emerged in this SaaS market. Free services include Google Docs, Google Apps, Google Sites and Gmail. Paid service examples are NetSuite for ERP, Salesforce.com for CRM, Oracle CRM, SAP Business ByDesign (Figure 12), Rackspace for IT hosting etc.

5. Future of business data after termination of contract or end of SaaS vendor.


Pu r or cha de se r

Figure 12 - SAP Business By Design On-Demand ERP Solution and Salesforce.com CRM Solution
In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

GR

/IR

Ra w

CR

at

DB

CR

Go od sr ec ei p

30

R co aw ns m um ate pt ria io l n

sa Do le m re es ve tic nu es

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

115

CR

Po s

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

DB

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

m Raw at er ia C l

41
Po M st IRO in vo ice

0
t

In v ch en DB an tor ge y

Ca sh

41 3

en ts

In ve st DB m

CR

DB

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

41

Ex M ec D ut 01 e M RP

8.9.2 MobiLe AppLications for ERP

To add to Tom Friedmans famous book (Friedman, 2005), the world is not only flat, it is also going wireless!, Business, communications, and entertainment are going increasingly more mobile. There will be nearly one mobile device per capita by 2015 (Deans, 2011). As mobile devices gain more popularity and capability, business users will rely on them more to do business activities that were traditionally relegated to the office. The explosion of apps for such devices is now providing mobile interfaces for ERP systems. A simple task like entering a Sales Order or potential lead can be entered into a mobile app at a client site. Many apps now have online (wireless connection to ERP backend) or offline (out of wireless range or no connection to ERP backend) modes whereby a sales representative can enter a Sales Orders without concern for wireless access.
Ra w m
sa Do le m re es ve tic nu es
DB

M pu Co E5 rc nv 9N ha er se t to or de r

Pu r or cha de se r

Upon making connection with the ERP system, the Sales Order is updated in the database. Additional details can be added at a later time either by the sales rep or other personnel. Other areas of mobile app development are work lists, business communications, collaboration, analytics, approvals, travel and reimbursement management, and mobile offices. Mobile apps for ERP (Figure 13) have several advantages increased productivity, convenience, lowering lead to deal time, quick access to customer information for making informed decisions, reduction in waiting time for approvals, increased profitability, and better customer service.
Go od sr ec ei p

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

30

Pr od or uct de io r n

CR

GR

/IR

CR

at

DB

CR

40

R co aw ns m um ate pt ria io l n

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

116

CR

Po s

t p F-53 ay m en

40

M pr od Re D0 l uc e a 7 tio se

o DB raw ns.

CR

DB

CR

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

Figure 13 - iPhone and iPad Apps for ERP CRM


o DB raw ns. C
CR

m Raw at er ia C l

41
Po M st IRO in vo ice

0
t

In v ch en DB an tor ge y

Ca sh

41 3

en ts

In ve st DB m

CR

DB

CR

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

41

Ex M ec D ut 01 e M RP

In re dep qu e ire nd m en en t t

Figure 14 - Mobile Apps in ERP Mobile Device - Presentation Layer

Go od sr ec ei p

GR

/IR

Web Services Layer - HTTP(S)


Ra w m at

Application Logic Layer

R co aw ns m um ate pt ria io l n

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

117

CR

Po s

Storage Layer

Ac c. Pa y. C

A new development in increasing analytics performance is in-memory analytics. The main innovation is that data is stored in memory (RAM) instead of in database tables. Data is stored in a much simpler format. Table joins are made as needed for querying. This greatly improves performance through faster data retrieval, calculations, and querying.
R

CR

DB

CR

40

Presentation Logic Layer - Application Provisioning

The standard process that businesses utilize for analytics consists of business intelligence tools that query a data warehouse. This data warehouse is a historical repository of transactional data from one or multiple sources. The data has been cleansed, transformed, and mapped to provide a single source of truth, which is critical for business intelligence. A multidimensional model is used model a cube that stores the vast amount of data that can be sliced and diced by a variety of tools. Many techniques are used to optimize the manipulation of this cube for fast data access. However, as data warehouses grow in size to several peta bytes, there is greater demand for fast access and easy analysis. Cubes require significant expertise to model, maintain, and optimize.
Po M s IG re t go O ce o ip ds ts

Pu r or cha de se r

Figure 14 shows how a mobile app integrates within an ERP framework.

M pu Co E5 rc nv 9N ha er se t to or de r

8.9.3 In-Memory AnaLytics

40

30

Pr od or uct de io r n

CR

sa Do le m re es ve tic nu es

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

DB

CR

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

In v ch en DB an tor ge y

Friedman, T. (2005). The World is Flat. New York, United States of America: Farrar, Strauss and Giroux.
Ca sh

41 3

en ts

Inmon, W. H. (2005). Building the Data Warehouse. Indianapolis, Indiana, United States of America: Wiley.
In ve st DB m
CR DB

Cr ea VL te 01 de N liv er y

C pr Con O15 od fi uc r m tio n

ODBC - Open Database Connectivity Overview. (2010). Retrieved from http://support.microsoft.com/kb/110093

Scheer, A.-W., Abolhassan, F., Jost, W., and Kirchmer, M. (2011). Business Process Automation: ARIS in Practice. Saarbrucken, Germany: Springer.

Further Readings
Bradford, M. (2010). Modern ERP Select, Implement & Use Todays Advanced Business Systems, Cary, North Carolina, United States of America. Retrieved from: lulu.com
Ex M ec D ut 01 e M RP

A Leading Research and Consulting IT Company. Extensive Repository of Research Papers and Case Studies. Retrieved from http://www.gartner.com/technology/home.jsp. Subscription required. Langenkamp, J. (2011). Magazine and Website Related to Information Management. Retrieved from http://www.information-management.com/
Pu r or cha de se r In re dep qu e ire nd m en en t t

M pu Co E5 rc nv 9N ha er se t to or de r

SAP. 2011. Advances in In-memory Computing. Retrieved from http://www.sap.com/platform/in-memory-computing/index.epx

Po M s IG re t go O ce o ip ds ts

40

30

Notre Dame Map (2011). Campus Map. Retrieved from http://map.nd.edu/#/placemarks/1028/zoom/16/lat/41.69826290628501/lon/-86.23395323753357

CR

41

Hurwitz, J. (1998). Sorting Out Middleware. Retrieved from http://web.archive.org/web/20061017153344/http://www.dbmsmag.com/9801d04.html

Go od sr ec ei p

Pr od or uct de io r n

CR

Deans, D. (2011). Visualizing Global Mobile Data Traffic Growth. Retrieved from http://blogs.cisco.com/featured/visualizing-global-mobile-data-traffic-growth/
DB

GR

/IR

CR

Ra w

Po M st IRO in vo ice

CR

at

DB

40

R co aw ns m um ate pt ria io l n

sa Do le m re es ve tic nu es

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

118

CR

Po s

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

References

o DB raw ns.

CR

CR

m Raw at er ia C l

41

Fa c pr tory od o uc ut tio pu n t

Re ve nu e

CR

Ac c. Pa y. C

DB

DB

o ro DB utp d.

Ac c. R

CR

CR

CHAPTER 8

ec .

DB

Kale - ERP System Architecture


pr Ma CO od ss 4 uc re 1 tio lea n se or de r

DB

Fi pr nis h o DB d ed uc ts

CR

ut

Fi pr nis od he uc d t

DB

m Raw at er ia C l

41
Po M st IRO in vo ice

0
t

o DB raw ns.

Questions
In v ch en DB an tor ge y

1. Research and draw a schematic of the client server architecture of your universitys information system(s). Identify the three (or more) tiers of that architecture. List the hardware and software choices that were made in that particular implementation. 2. Contact a system architect for an enterprise that uses an ERP system. Research and draw a schematic of the client server architecture of that enterprise. Identify the three (or more) tiers of that architecture. List and explain the hardware and software choices that were made in that particular implementation.
Ca sh en ts In ve st DB m
CR DB CR

41 3

Cr ea VL te 01 de N liv er y

3. More and more people are using mobile apps for communication and business. Discuss some solutions for apps to continue working when the device is offline. (Hint: HTML5) 4. Cloud computing and cloud services are the buzz words these days. Explore the service from Amazon called Cloud Drive for buying, storing, and playing music. Also explore the CRM solution from salesforce.com. Discuss the advantages and disadvantages of each of these services in light of personal and organizational needs. 5. Why is in-memory analytics faster than on-disk analytics? How is data persistency achieved in an in-memory database? What are the differences and similarities between an in-memory database and an on-disk database?

C pr Con O15 od fi uc r m tio n

41

Ex M ec D ut 01 e M RP

M pu Co E5 rc nv 9N ha er se t to or de r

Pu r or cha de se r

In re dep qu e ire nd m en en t t

Po M s IG re t go O ce o ip ds ts

40

Go od sr ec ei p

30

Pr od or uct de io r n

CR

GR

/IR

Ra w

CR

at

DB

CR

40

R co aw ns m um ate pt ria io l n

sa Do le m re es ve tic nu es

Ac c. Pa y. C

In ve so nto ld ry pr ch od an uc ge t

GR

/IR

In ve s

Ca s

Readings on Enterprise Resource Planning


es nu

tm

en ts

DB

CR

DB

ut

pu t

Preliminary Version - send comments to pml@hec.ca

119

CR

Po s

t p F-53 ay m en

40

DB

M pr od Re D0 l uc e a 7 tio se

CR

DB

CR