Resource of Information about SAP Business One


SAP-B1 Authors: Liz McMillan, Maureen O'Gara, Dana Gardner, Bruce Armstrong, Pat Romanski

Related Topics: SOA & WOA Magazine, Java Developer Magazine, SAP B1, SAP4SME


Finding the Flaws of the Whole, Not Just the Flaws of the Parts

Why automated analysis and measurement is a must for SAP systems

The Visible and the Invisible in SAP
It would seem like the last thing we need in SAP systems is more metrics. Automated solutions that investigate, monitor and track ERP systems are common, so why are major corporations increasingly employing automated metrics for SAP systems?

Like all systems that span the enterprise, SAP systems suffer from the "six blind men and the elephant" problem - each man is able to envision his own part of the elephant, but putting together a picture of the whole animal is a problem. It is this "whole is greater than the sum of its parts" view that SAP developers need to get their arms around.

In what has become an all too frequent post-customization scenario, SAP developers are called to fix a transaction performance problem. Usually they find that availability is great, there's nothing wrong with the code - no odd changes - but somehow latency is in the tank. So what's wrong?

Some recent research on this very issue looked at 30 customer installs at large installations at Fortune 1000 companies with a lot of customization. The study looked closely at how database calls are handled in these installations.

The result was startling - 80 percent of the database interactions were being improperly handled. Large packet sizes, too much chatter, improper error handling, loops in queries and lapses in connection handling were prevalent. These problems caused periodic and significant business disruption. As we know, intermittent problems are the hardest to trace and fix because if you can't replicate it, you can't see what to fix - it's the kind of problem that traps you in the office on a Sunday until 3 a.m.

How does this kind of thing end up happening with such alarming frequency? After all, no ABAP developer worth his or her salt would ever do such things and no database admin would be caught dead writing inefficient queries. It must be those darn six blind men!

Figure 1: A Typical SAP Ecosystem

The blind men are the symptom caused by three types of complexity:

  1. Technological Complexity: A typical SAP install has a large number of interconnected, customized components, with dependencies spanning from the GUI to the database layer. Business transactions cut across applications, functional roles within IT, business processes and business divisions. No single developer or even team of developers can comprehend the system end to end. Changes have ripple effects that are difficult to predict and control. None of these is by itself a bad thing, but together they make it very hard to get a sense of how the system is working as a whole to accomplish its critical business tasks.
  2. Process Complexity: Because the system crosses organizational boundaries within and outside IT, it runs into different processes within these groups. Each process demands a unique skill set for the people involved, and has its own timeframe, maturity level, inputs and outputs. It is inevitable that when seen as one large "super-process," a lot falls through the cracks because no one person or team has the complete end-to-end view.
  3. Governance Complexity: When you add organizational and reporting structures to the process complexity layer, you get governance complexity. This is about the hierarchies of authority and influence that manipulate the processes. The result is a highly scrutinized business-critical system that outruns technology, process, and governance boundaries. In such situations, one team's priority may not be another's, resulting in an inability to see the end-to-end view.

As we see in the next section, this fragmented view of the systems causes all the typical problems that beset ERP systems.

Structural Visibility of the Whole System
Inability to capture the end-to-end view leads to the usual problems people cite with ERP systems - escalating maintenance costs (over and above the 18% license cost) and nagging performance and stability problems. The root causes of these problems are hard to discern, but they have become almost clichéd and yawn inducing in their recurrence...

What people who cite these problems don't realize is there's nothing any individual developer can do (other than what they're already doing) to fix these problems. It's not what I do or what you did - it's what happens when we put together what a couple of hundred of us did at different locations, on different parts of the system, at different times, under different deadlines.

It's like the deficit. You didn't cause it and there's nothing you alone can do to reduce it. It's the result of thousands of things coming together to add up to something enormous that's beyond the control of any one person or group. Nevertheless, it could harm us all, so what can we do?

When the whole is greater than the sum of its parts, what we need is structural visibility into how the parts come together to create the whole. In the case of an ERP system, you need measures of two levels of quality: the software's architectural quality - the structural quality - and the quality of coding practices and level of compliance with security standards - the implementation quality. These measures are essential for catching business disruption problems early before they become too expensive to fix.

Figure 2: Sample End-to-End System Quality Metrics

Moreover, you cannot just measure the individual parts because that fails to take into account how each of them comes together to form the final product. And while an individual may be able to assess the quality of a single part manually, manually measuring the whole product is a daunting and grossly inefficient task, one that no one team member can or should be asked to undertake. Automating analysis of the parts and the whole is a far more efficient means to an end.

Three Conditions an Automated Analysis and Measurement System Must Satisfy
A fundamental fact about software quality that makes it a challenge to quantify is that quality is contextual - you cannot evaluate the quality of an element independently of its environment. This means that any process for measuring the structural quality of the entire system must satisfy three conditions:

  1. It must be automated to avoid falling into the technology, process and governance white spaces.
  2. It must be comprehensive in its technology coverage, yet come in a single package. Not surprisingly, it has to cover the entire system from GUI to middleware, to the customized parts, all the way to the database.  In modern systems, this means it has to cover a multiplicity of languages, technologies and frameworks. This comprehensive coverage must all come together in the same package; if you use a patchwork of tools, you will inevitably fall into the cracks between technology, process and governance boundaries.
  3. It must rise to the structural level to measure quality in the context of the system as a whole. From an implementation standpoint, this will most likely mean that it must produce detailed architectural maps of the entire system - views of the components and how they are connected - and run sophisticated pattern-matching algorithms that are specifically calibrated for measuring quality - performance, stability and maintainability - in the SAP environment.

An example of how to accomplish this is to base automated analysis and measurement of ERP systems on a very detailed understanding of the architectural structure of the system - what the components are and how they're interconnected - by building the architectural model from the ground up in intense detail. Such sophisticated pattern-matching algorithms are then specifically tuned to measuring quality in terms of performance, stability and maintainability in the ERP environment. A top automated analysis platform for ERP systems may have more than 100 pattern-matching rules for SAP. (Note: The number of pattern-matching rules can vary from one ERP to another.) A robust end-to-end automated quality measurement system for the Siebel platform may also have more than 100 rules for detecting patterns and anti-patterns that are critical to system quality, while leading PeopleSoft-specific solutions may need more than 400 sophisticated pattern-matching rules to evaluate the holistic engineering quality of the system).

Regardless of how many rules are in place, it is vital that the platform detects changes between the original core application and the customized application, or between patched and un-patched version of the same application. Along with detailed architectural visibility and objective measures of quality hot spots, such a solution will give IT organizations and system integrators a detailed, practical roadmap for sequencing their development, maintenance and upgrade tasks.

The technological, process, and governance complexity of SAP systems make them very difficult to manage for peak cost and business performance. Furthermore, because the whole system is more than just the sum of its parts, the analysis and measurement must rise to the structural level to quantify and evaluate the structural quality of the system, making an automated analysis and quality measurement system a necessity.

More Stories By Jitendra Subramanyam

Jitendra Subramanyam is Director of Product Strategy and Research at CAST, Inc., in New York City. He is responsible for helping to develop and grow the ecosystem of IT service providers who benefit from integrating CAST into their operations, governance and process improvement programs.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.