Many large organizations run their ERP applications on a small number of proprietary systems — primarily because ERP applications have historically been marketed and implemented as integrated, company-wide solutions.
Intel IT has taken a different approach. We’ve eschewed a monolithic, company-wide ERP implementation in favor of different business groups implementing ERP applications individually to support their own operations. Each of these decentralized implementations runs on industry-standard servers located in corporate data centers. This decentralized approach offers several advantages, including lower server acquisition costs and increased flexibility and agility.
Intel IT’s Decentralized ERP Strategy
At Intel, the sales and marketing group was the first to implement ERP applications to support its own operations. Other business groups followed suit, and today Intel has separate ERP implementations for finance, materials management, warehouse management, and other functions. These implementations add up to a very large ERP environment — with over 10,000 active users logging onto approximately 250 servers. This approach means that each implementation is optimized for the unique needs of the group it serves. Intel uses middleware from the ERP supplier to share and synchronize data between these systems.
When selecting a server configuration, Intel, like many IT departments, tries to standardize as much as possible: It is much faster and more cost-effective to choose an existing reference design than it is to qualify a new platform. It is also typically more cost-effective to select a larger server that has more capacity than initially required, rather than qualify a new server in an attempt to find the perfect fit for a specific instance. This also helps reduce support costs.
Server sizing and selection to support a specific ERP instance, therefore, is an essential part of our strategy. At Intel, we have standardized on a small set of server platform reference designs based on industry-standard four-socket and two-socket servers. We use these reference designs to support most of the ERP instances in our environment, selecting four-socket or two-socket designs for each instance, depending on the requirements.
How to Select the Appropriately Sized Server
When Intel selects a server platform to run a specific ERP production instance, the goal is to size the server so that it provides predictable, high performance while minimizing disruption to the business. At the same time, we seek to minimize server TCO.
Various factors determine our ERP platform selection and sizing decisions, including workload growth projections, the maximum utilization target, the size of workload spikes, and the capacity of four-socket and two-socket servers. We have developed a quantitative model that assists with server platform selection and sizing by enabling us to analyze the effects of these factors on platform utilization. The model is based on the Intel IT approach to sizing servers for our own ERP environment. Our analysis has resulted in the current Intel IT ERP server platform positioning framework, shown in the figure below.
Within Intel’s ERP environment, two-socket servers are used predominantly in cases that do not require the scalability of a large production instance. These cases include smaller production instances and a range of non-production uses, such as development, production support, and QA.
Intel IT has standardized on four-socket servers for larger ERP production instances and supporting database environments. Four-socket servers are targeted for higher-end applications and more mission-critical functions. They tend to rely on more mature and proven technologies and have longer design and validation cycles. They provide enough headroom to continue delivering good performance while accommodating workload growth, spikes in demand, and failover situations.
We therefore expect to continue to use four-socket servers to run our most demanding ERP application production instances, as well as instances used for benchmarking and disaster recovery. Their scalability also makes four-socket servers well suited to act as virtualization hosts, and we are investigating using them as hosts for virtualized non-production ERP instances used for development, testing, and application support.
Risks of Under-Sizing: Avoid a Mid-Life Refresh
Under-sizing — selecting a server that exceeds its maximum utilization target before the end of its planned life cycle — has significant consequences. Each Intel ERP production instance includes a scale-up database and several application components. If the ERP server cannot accommodate growth in the database, the server typically must be refreshed mid-life in order to help ensure that ERP performance continues to meet service-level agreements. This mid-life refresh disrupts business operations, adds logistical complexity, and substantially increases TCO — resulting in significant hardware and non-hardware costs due to the need to purchase new servers and to implement and test changes across this business-critical environment.
Intel needs to qualify each new server platform for use in its ERP environment. Intel IT has a team of three people who work part-time on this, representing a total of about 6 to 12 person-weeks. A pipeline architect, a database administrator, and an ERP application specialist work together to refresh the servers running each of the ERP instances. This represents a total of about 12 to 36 person-weeks of effort.
Business group regression testing and checkout is the biggest cost, accounting for an estimated 36 to 72 person-weeks of work. Because
Intel’s business groups rely so heavily on ERP, they tend to be risk-averse and require repeated testing of any proposed changes.
The hardware costs of a mid-life refresh can vary significantly. For each Intel business group ERP implementation, there is a pipeline of ERP application instances. Each instance supports a specific function, such as development, benchmark testing, production, or production support, and may be implemented using one or more servers. The hardware costs of a mid-life refresh are determined by the number and type of servers that need replacement within this pipeline. A couple of factors can influence this:
- The hardware and software platforms available as replacements may differ considerably from the platforms that were originally deployed, depending on the length of time since the original deployment. If there has been too much change to the hardware, OS, and drivers, it may not be feasible to mix new platforms with the original platforms within a pipeline.
- It is highly desirable, for support reasons, to have as much hardware and software consistency across an entire pipeline as is economically feasible. This consideration may drive wholesale replacement across a pipeline even if it is conceptually possible to mix new and existing platforms.
The greatest impact of a mid-life refresh — even more significant than the cost of acquiring new servers — is the business disruption incurred as new instances are tested and deployed on the new servers. Disruptions include:
- The need to allocate testing and validation resources that could otherwise have been applied to other projects
- The downtime required on each system during the implementation of each change
- Production systems that are unavailable for use during the cutover to the new servers
We strongly recommend that companies consider the combined effect of all of these factors when determining which server has enough headroom to support your critical ERP environment — without requiring a mid-life refresh.
To learn more about the sizing factors that influence Intel’s server platform selection, see the online version of this article. For more information about Intel Information Technology, visit www.intel.com/IT.