As enterprises look at their SAP business processes and implement business process improvement programs, they may...
find themselves facing a hardware infrastructure problem instead. While the notion that server infrastructures should be virtualized and elastic enough to handle anything a business can push, in the real world of distributed global systems, that’s not always the case.
Still, it’s important to understand that SAP applications, particularly SAP ERP, are proven and performance tuned, said Derek Prior, a research director for Gartner Inc. who specializes in SAP technology, operations and lifecycle support. “SAP has their technical approach to getting the performance right,” he said. “They’ve got application benchmarks; they’ve got software sizing processes; they’ve got performance monitoring software performance tools for their products and they work closely with the hardware vendors to make sure they do things in a compatible way.”
Many companies start outsizing servers or virtualized instances for new application workloads by looking at concurrent users for modules. According to Prior, they may discover that even going so far as recognizing that load factors for some modules, such as financials, might be very light compared with a company’s manufacturing-focused workloads.
“The only way you’re going to get a technical assessment of the workload on the system is not by the number of users, because that hides the detail,” Prior said. “You have to understand the transaction volume during the peak hour of the month that’s going to go through the system. You have to work out your loads.”
Loads are rarely static -- over the course of several months and sometimes years, changes to business processes can radically affect transaction data volume on some days and barely affect anything the rest of the time. To help organizations keep a handle on process changes and system performance, SAP has done a good job of providing built-in tools for automating monitoring and planning, Prior said, adding that there are also many third-party tools SAP customers can turn to as well.
The lurking danger with custom SAP coding
While some high-transaction volume industries are more prone to business-process-related performance problems -- such as retail, utilities, telecom, banking or insurance -- the most likely culprit for hardware and network-related performance problems is custom code.
“In my estimation, custom programs are 80% of the root cause of people having performance problems,” Prior said.
When companies introduce customization, Prior said, “Don’t be surprised if you run into a performance problem. … If you have high transaction volumes, you need to be even more careful.”
To break free from custom-code related bottlenecks, companies first need to measure the system and the application performance, and then collect detailed data to prove where the root cause is, Prior said.
“You’ll typically find that your custom code has not been optimized fully. The first thing you do is find some real application programming performance tuners to take another look at your custom programs,” he explained.
Better yet, Prior noted, companies can use software tools to automatically diagnose, analyze and identify all their SAP custom coding programs. On top of that, they can get a clear picture of custom application usage, which is often lower than people believe. By realigning or reworking business processes through built-in SAP modules, companies can often eliminate performance issues.
As the global nature of many SAP-focused organizations comes into play, Prior said, “The most successful customers have support organizations which focus on end-to-end business processes and less on the underlying application modules.”
Although custom code can create SAP system performance issues, companies typically turn to it for a competitive edge, an answer to a problem that will help an enterprise earn more business.
According to Clay Richardson, a business process management (BPM) analyst for Forrester Research Inc., many SAP customers are extending their systems with some sort of BPM environment because they are challenged by the static, standard SAP processes.
“One customer summed it up when he said, ‘We’re in a market where all of our top competitors also use SAP, and if we’re all using the same processes, that doesn’t make us very competitive.’ So they used SAP NetWeaver BPM to extend an order management processes,” Richardson explained. He noted that the company was, almost on a quarterly basis, changing its order management process by using custom ABAP code.
“They moved away from that because they had to make so many changes and they wanted a process model where they could make the changes with the business rather than making the code changes,” Prior said. “And that’s what we’re seeing -- SAP customers using the NetWeaver environment to accelerate change and create a differentiated process to help them be more competitive.”
In fact, Richardson said that Forrester’s latest research is pointing toward a future of packaged applications that are a “blend between BPM -- model driven, visual composition -- combined with more of the packaged app providing best practices in the data foundation,” he said.
“There will be more customization, more significant flexibility that customers will want to put in,” he noted. “So not only will they have to think about the development impact, the configuration management, they also have to think about the hardware impacts.”