Quality Management in ABAP Development Projects

[ttrapp]

Which Qualifications Does a Quality Consultant Need?

Quality management is harder than development.

When developers make mistakes, they get instant feedback. Programs produce incorrect output, they are too slow, or they crash, or they make it hard for us to fix mistakes or to add new features. Quality management is much more abstract, thus positive and negative effects are hard to measure.

Objectively seen, it's an interesting question: What quality procedures have proven their worth? Are there special things to look at in SAP development, an if so: which ones?

How do I recognize good or bad quality management? I therefore want to discuss quality management in ABAP-development projects, as well as with the job description of the quality manager who has to come up with procedures, regulations and quality protection procedures - in other words, he defines quality management defines in detail.

In general project management doesn't need special technical knowledge. A project manager needs management skills to lead his staff and deal successfully with customers and external staff. There are successful software houses that demand no special knowledge about single development platforms from their developers. When then developers from an individual software field take their first steps in SAP software development, usually the same mistakes are made over and over again.

At first they state that the SAP standard is insufficient for their needs and that everything has to be programmed again from scratch. As one is so knowledgeable about databases, and furthermore realized that the DBMS of one's choice by chance doubles as the database server of the SAP system, one can ponder if Trigger or Stored Procedure can't solve a given problem "elegantly".

If they totally run out of luck, they find a skilled GUI-designer in the project, who states that the SAP standard dialogues aren't up to date and that things urgently need to change. As the results of such first steps of the individual software developer have nothing in common with standard software, the project manager does well, if he puts an experienced development leader in charge, who makes sure that there aren't too many detours. Just, what about quality management?

The crucial question is, whether or not a quality manager needs any technical knowledge. There is the opinion that it is not necessary. One can define standardized models for the testing phases: integration-, acceptance- and mass tests. Furthermore there usually are established concepts that allow the definition of criteria to tell if and when the finished project is acceptable. It's just that quality management is more than test management, which by the way also includes many technical aspects. Doesn't quality management have to be representative of the whole life cycle of a software and won't standard procedures suffice?

Let's say you're in charge of the development project of an airplane and you had to appoint someone, who is responsible for quality management and should also line out the analytical and constructive quality management for development. Would you choose someone who has never in his life been on an airplane and who doesn't have the least technical knowledge about avionics? Would you be content if the person maybe held a driver's license for a small motorbike and assured you that he has watched planes crossing the sky?

Let's assume you would choose that candidate nevertheless, wouldn't you expect at least that he doesn't transfer his experience with the small motorbike one on one to the plane, but gets information on the quality risks of airplane engineering? That he learns about existing risks and security standards? How to tell in time that an airplane will lift up into the air and not directly after the start fall like a stone or as a small motorbike that has been fitted with wings and overly accelerated?

These thoughts might seem trivial, but throughout the software branch, unfortunately, they are not uncommon. It often seems that those who have been chosen for quality protection processes have too little experience with the chosen platform to be able to work in a structured manner. There also is a certain logic to it. Those with experience have to do the actual development and thus don't have the time to define guidelines for development and create ordered checklists.

One reason that this point of view could prevail is that there are recognized attributes of software quality: correctness, robustness, performance, maintainability etc. Aren't they universal? Aren't programming languages, too? Isn't ABAP a kind of mixture of Cobol and Java?

The Connection Between Quality Management and Risk Management

Once you have reached this attitude, there are serious dangers, for in SAP development there are some exceptions.

• The language ABAP has some particularities. For example it comprises some very old-fashioned as well as very modern concepts - and often both of them have to be used at the same time.
• The pure programming language causes the least problems. It's more of a problem that the single SAP system is highly integrative. A simple DDIC modification or a changed customizing entry can have severe consequences.
• A cumbersome transport system is added to the high integration. It's not easy to set up a software in a way that it can be delivered in modules. Likewise parallel further development and maintenance is not always easily achieved.
• "SAP standard" (for example the components SAP_BASIS and SAP_ABA) is very complex and subject to changes. Which parts should be used and how can software be set up in a manner that it's robust against modifications in the basis components?
• The big challenge in the field of SAP is to develop standard software, and at the same time to keep it flexible enough that most clients' needs are met. Often even clients' enhancements are approved, that further increase the complexity of the software system.
• You don't have the limitless freedom of individual software development. For example, you shouldn't access the database with Native-SQL, just as there can't be an alternative GUI library added at a whim, but you have to rely on the SAP standard.

Facing these risks, a quality manager might come to the following conclusions:

1. Crucial decisions about design have to be made by an expert. The project relies on his competence.
2. To counter high integrativity, you need a very modular architecture.
3. You need rules and previews, respectively reviews, to ensure that the expert's specifications are met.
4. To monitor success or failure of development, you need a solid mile stone planning.
5. You need a good test concept.
6. You have to tell early, if the software will prove its worth in production.

In principle it comes down to technical decisions being made an expert. The quality manager should meet with him and discuss the risks and how to deal with him. This principle is true for any software project. Quality management is never a goal in itself, but always aims at avoiding problems or to deal with them.

The Emergence of Software Bureaucracy

Reality sometimes is different: quality management is often isolated. What can happen if a quality manager doesn't have the same level of experience as the programmers? The danger is that solutions, which might have proven themselves in individual software, might be transferred without further questioning.

In this case processes, document templates and tools are created that aren't meeting the problem and they threaten to paralyze the team. The more ineffective or even harmful an installed quality management is, the more likely it will be boycotted by developers and futile discussions and fighting will ensue. Furthermore, the people involved develop bogeyman images about each other: quality management is supposed to be a form of harassment and developers in general are slobs who therefore need even more patronizing through processes.

The solution is simple: All quality management also has to be checked for quality, otherwise it becomes an inflexible bureaucracy. In real life we strife for a reduction of bureaucracy, for bureaucratic administrations have a tendency to develop uncontrolled dynamics and entelechy. The examples from above exist - in my opinion - because quality managers don't see themselves as risk minimizers but want to run processes for the processes' sake. This guarantees self assurance: They prove that they aren't "some simple developers" anymore, but define processes and enforce them. Thus they see themselves as almost equal to process designers or even project leaders.

My advice is that a quality manager should try and consider the developer as a client. Which problems are there? How can I support the development or the test? What are the most efficient measures that facilitate the project best? Developers are constantly told that an architecture then is the most elegant one, when nothing can be left out anymore. Why shouldn't this rule also be applied to quality management?

The project manager who wants to establish quality management in his project has to decide whether he wants to minimize risks in the development process, or if he wants to install a software bureaucracy. He has to decide, if his quality manager has to have some basic technological competence or at least the willingness to learn. If he decides otherwise, he must take into account that the quality management will only exist in Powerpoint presentations and thus rather hinder a team than bring it forward.

Overcoming Bureaucratic Structures

Just like almost any problem this one is self-made. Quality management is established by the corporate management and is only accountable to them or controlling, or on project level to the project leader. In both cases quality management notoriously defies its own quality assurance. The solution is self reflection.

Albert Einstein answered critics of his theories by explaining them in which cases he would regard his theories confuted. How many quality managers might have thought about the conditions under which they are willing to change their quality measures prior to or while establishing them?

In summary I want to put the following on record:

• Quality management has to be linked to risk management. If the special challenges of the SAP world aren't met, quality management is no use at all.
• Quality management is the only process that calls for quality assurence, while at the same time defying it. In parts this might make sense, for with the abandonment of standardization quality management defies liability. Once liability defies any criticism by practice, it degenerates and becomes a disconnected ritual of submission.

Luckily software bureaucracies aren't long-lasting. For if one has once experienced good quality management, one doesn't want to miss it anymore and many developers will ask for it.

Contrary, quality management often finds itself between two front lines: On the one hand there often are delays on part of development, on the other hand the project has to be shipped quickly In that situation one is constantly forced to work effectively and to prioritize and with that also jettison bureaucracy. In this case quality management is subject to feedback by practice.

And herein also lies the problem: If a quality management seals itself off against any change, just as China did by building the Chinese Wall, it automatically becomes regressive. If a developer bellyaches about any kind of quality management, he disqualifies himself just alike, for he can't be trusted to deal constructively with the topic. Empathy and objectiveness therefore are important steps towards a constructive cooperation.