Thomas was adamant in his opposition to customization: "Don't do it at all, don't do it yourself, don't get an SI to do it," he insisted. "Because any changes you make to the underlying module, it's not simple recompiling-it's customization that needs to be done from the ground up, and we would have to redo that customization...we want to have our customers give us feedback-we will change our business processes [based on feedback]," he said.

"Firstly, we need to clarify configuration," said Mark Frear, director, business development, SAP NetWeaver. "This happens in every project and involves setting flags to affect business logic (the main way to implement SAP) and bespoke coding, which is program writing and is usually small compared to the processes which are configured. Coding normally occurs for batch file integration or data conversion-a one-off exercise to get data out of old systems and into SAP."

"Configuration does not introduce security risks," said Frear. "A customer writing its own code could introduce risks, but our security [measures] prevent, deter and monitor the risks. SAP applications have many safeguards to stop customer written code (custom code) from getting to the productive environment, including the inability to modify SAP code with the security access and even notifying SAP with a source code object key. Then there is Dev, QA code promotion controls and audit trails not only on who creates the code, but the data records it updates."

"In a nutshell, we have a final backstop, which is a real-time code inspection via the compliance calibrator and a separate audit log. Even if a customer continues to ignore all these security measures, there is a forensic trail."

Code-mixing