Home > Articles > Databases > SQL Server

SQL Server Reference Guide

< Back Page 205 of 361 Next >

Enterprise Resource Planning

Last updated Mar 28, 2003.

SQL Server has plenty of uses as a platform for applications. Applications come in all sizes, and one of the largest is Enterprise Resource Planning, or ERP. Enterprise Resource Planning really isn't a piece of software, though; it's a category.

Enterprise Resource Planning Defined

Webopedia defines ERP as:

"Short for enterprise resource planning, a business management system that integrates all facets of the business, including planning, manufacturing, sales, and marketing. As the ERP methodology has become more popular, software applications have emerged to help business managers implement ERP in business activities such as inventory control, order tracking, customer service, finance and human resources."

While that definition is accurate, it's a bit unsatisfying for a DBA. Just how does this affect the database server architecture? It might be more helpful to think of the title as the definition. Let's break it down:

Enterprise: ERP software affects the entire company, all around the world. While I have seen ERP systems implemented in a "silo," where only a few groups actually use it, those projects usually gain little general buy-in and as a result they often fail. Properly implemented, ERP software is pervasive, affecting all workers in the company, even if they don't use the software themselves. It must take into account all parts of the company as a whole, instead of making various parts just work together. This affects the design in ways that don't otherwise occur, such as program flow and data storage.

Resource: ERP software controls the resources of the entire company. Resources include capital (money), personnel, and infrastructure (such as buildings and equipment). While it's common to store data about various resources, interaction between all corporate resources calls for a new level of design.

Planning: This is where the other two parts come together. The individual parts of the overall application include timecards, budgeting, and project planning. To effectively plan, the software must have a historical feature to identify trends. Since the software includes budgets and personnel information, security is quite complex.

Those are only a few of the challenges of implementing an ERP package. One of the largest doesn't have anything to do with technology at all.

Many software installations include only a couple of departments. Some, such as e-mail or Web services, only require the direct involvement of IT. The opposite is true of an ERP implementation. Most often, the business side of the house initiates the project, and IT is brought in later in the game. With the number of resources the project will affect, just about every part of the business has a direct involvement with the implementation of an ERP system, and IT might not be in the driver's seat.

The level of involvement and the number of participating departments makes an ERP implementation very challenging. Add to that the fact that IT normally has free reign over most technical projects (but not here) and you've got the makings for a significant amount of political issues. Expect a lot of meetings and cooperation to pull the implementation together.

SQL Server and ERP

How does SQL Server operate differently with an Enterprise Resource Planning system than with other applications?

Enterprise Resource Planning applications are highly normalized. This means that there are even more tables than in a standard On-Line Transaction Processing application database. Sometimes, many more. In a product like SAP R/3, the number of tables can reach into the thousands!

ERP applications are also network-intense. Since the database model for ERP is OLTP, there are many small transactions. In other OLTP or reporting applications, the data sets are larger and less frequent.

High numbers of users are involved in an ERP system, since it involves so many different departments. Also, because of the number and variety of users, you can expect a more distributed architecture. This means lots of operating systems, browsers, even hardware. In the ERP system at my firm, the clients range from handhelds and phones to PCs and Macs.

Along with the multiple client types at your own firm, you'll probably have to make at least some of the system available to clients and vendors. The security and performance pictures become very complicated when the system has to be opened up to this new audience.

Design Decisions

With all these complexities, you'll be glad to learn that you don't have to design the database for commercial products. Of course, if you're rolling your own, you have the design of your life on your hands.

Even if you buy an ERP system, you still need your design skills. Most of these systems are so large that one size does not fit all. This means that most every large commercial product allows a fairly large amount of customization. Most of this customization is done using a tool supplied by the vendor, but in some systems you're still required to design at least views, if not tables. More recently vendor provided tools insulate you from the database layer.

Whether or not you have to design database objects, you'll be involved in the planning for the infrastructure. Here are the various areas you'll need to plan for regarding the database system.

Memory

ERP systems vary in the amount of memory they need, but as a rule they implement a structure that buffers as many objects as possible to provide good performance. As with most applications, more is better. The issue comes into play when you get above 3 gigabytes of RAM. At that point you need to make sure you check out the Enterprise version of SQL Server, and pay attention to the options regarding AWE memory.

CPU

ERP systems have various levels of complexity. The more complex the logic in the system, the more CPU power is called for to process it. CPU requirements are also dictated a great deal by the ERP system's architecture; if the system is distributed, you can get away with fewer CPU's on the database server. If the business logic is stored primarily in the database, however, you might need more, since the stored procedures and I/O calls affect the CPU load as well.

If the ERP system has several choices for the back end, such as SAP, the processing for business logic isn't normally stored in database stored procedures. This is because the vendor would have to write and maintain several flavors of these stored procedures to take advantage of each RDBMS' platform. Here you're looking more for availability and redundancy than strictly performance from the database server.

Hard Drive

Of course you want to consider a full SAN for any serious ERP implementation. The decisions here are affected more by the data set size. Normally in an ERP system the recordsets are quite small, and quite frequent. This means you should optimize your I/O for faster, smaller hits than in a reporting system.

Network

The network is perhaps the most overlooked component of an ERP implementation. Make sure you get an average load per click for the application, and ensure that your network can handle it. We're not talking about user load, since we're focusing on the server, but in how each server communicates. Your vendor should be able to provide this metric, so be sure to insist on it. Network upgrades can be as simple as a new switch, or as complex as a campus rewire.

As you can see, there's a lot to consider in an Enterprise Resource Planning implementation. You should expect to spend a significant amount of "meeting time" and lots of difficult decisions. With proper planning, it can be one of the most rewarding projects a business undertakes. Done improperly, it can adversely affect the bottom line.

Online Resources

CIO has a quick intro to ERP. It's worth looking over.

IFS makes ERP solutions for Europe. Although you might not use their software, this link has a great chart you can use to visualize the various functions in an ERP system.

Really into ERP? These people are.