The Software Development Process in SAP

The software development process definition is one of the most neglected jobs in the SAP Competence Center’s area of responsibility. This job ain’t done by hiring of a few developers, particularly when they aren’t employees, but external freelancers.

It’s like a soccer team: There are several different roles, which must been taken on and there is a coach, who defines the tactics. The interplay of functional consultants, developers, key users, system administrators and – yes! – quality managers is as important as that each of them wants to do the best work they can, work that they can be proud of.

Author: Ralf Wenzel                 http://www.heuristika.de/

Published on: https://blogs.sap.com/2015/09/21/the-software-development-process-in-sap/

Software Development, of course, is kind of creative work, but nevertheless it is an industrial process. That means, this process can and should be monitored and estimated. Furthermore, the software developers management can learn much from industry in terms of quality management. An ABAP based application is a product, which has to be purchased, planned, developed, tested, sold and maintained. Technological progress has to be used, to improve the SAP based applications and – not to forget – to boost the sales and the revenue of the SAP Competence Center.

The reality in most SAP running companies is far away from this. Although the IT department have been outsourced to IT subsidiaries (which means: they have to sell their own products to the functional departments, which are their customers), they don’t treat their SAP applications like they should handle their product. I shocked some of them by using the statement:

“If you’d build your enterprises’ main products as you develop tour SAP applications, you would be bankrupt a long time!“

Gil Amelio, a former head of Apple Computer, made the following statement:

„Apple is like a ship with a treasure, leaking water, and my job is to point this ship into the right direction!“.

Applied to the attitude of many SAP running companies, they behave similarly.

The SAP system is the collection of all business processes in a company, therefore it is a treasure, which values lots of money. Undocumented processes are worthless, because they can not be improved or changed. Imagine, a company like Apple does not have any documentation of the technical details of their iPhones. „Steve knows that, we can ask him“ is a bad answer – not only when Steve dies, but also when he leaves the company, he falls il, is on vacation, etc.

There are masses of books, how to do product lifetime management with SAP, and (knowing, that all general statements are wrong) no one does this within SAP. SAP PM provides many features for product maintenance administration, but it’s not being used by the IT companies, which are running SAP systems for their customers. They do not even implement a ticket system in most cases, because of the effort! This calculation is as wrong as the statement „I do not have any time to to clear my desk“ (a clear desk is a very underrated timesaver!).

How far would you trust a company, which does not use their own products, they want you to buy? How far would you trust a consultancy, creating your business processes, which does not have any for their own business?

The reality is: Users do their incident notification via phone, specifications do have the size of a beer coaster, the “testing process” is just trying some usecases (mostly just one), documentations won’t be written, and so on. This may sound horrible for engineers in car or plane construction or any other branches, but this is the reality in their own IT.

The most impacting improvement are standards. Standards for specifications, coding standards, documentation standards and standards for the whole development process itself as well as for the incident handling and emergency plans.

Beethoven vs. Henry Ford – get ready to rumble!

One of the reasons is the developer’s mentality. Many developers are of the opinion, that they are creatives, similar to daVinci or Goethe, which results into a collective rejection of all these important quality management features, SAP customers love. “How do you want to quantify my work – by counting my coding lines?” is the most used comment, “I do not work on an assembly line, I do sophisticated and excellent work, which only has a qualitative dimension, not a quantitative one“. I gave a speech in front of about 25 of this kind of developers, caused by a massive overhung of univoiceable / unproductive working hours. This situation led their mananagement in serious trouble, because there were plans to sell the IT subsidiary if the efficiency won’t increase. In this struggle for bare survival of the whole company, a management needs the corporation if their employees, but after my first sentence (“we have to work more professional and avoid wasting of time“), I could go home. No one wanted to hear something about professionalism, even I had seen many companies, they could learn from. To be honest, this first sentence has been chosen silly – I am not a candidate for diplomatic foreign service. Because of course, none of this developers were of the opinion, that they are wasting their time! After that speech, I began to study the presentations of Steve Jobs – and I learned much and my speeches are much better, now.

This IT company – one of the top 5 in all over Germany! – did dispatching like this: The team manager walks over a long floor, entering developer offices to his left and his right, asking “I’ve got an order for an application – do you have any time for this?” – Customer threatens to order and the team manager has to make his team working. The high order requirement to all applications were: Be cheap and fast. I’m not kidding by telling this story, this is simply the truth. If the functional department asks for a progress report, the team manager has to ask the developer! This results into a serious problem, if he is on vacation or ill, because the team manager does not know anything about the progress.

Another customer, I worked for, has implemented Jira for a single project, to speed up the incidence handling in an integration test week. And guess what: On the first testing day I got an Excel list with incidents! Because their employees are not motivated to learn Jira (which could be done in an hour!)

Imagine the following situation: A car manufacturing company like Mercedes or BMW has the following test process for all cars, they produce: One of their employees enters each car, turns the key and listens, if the engine is running. Would you buy a car, which has been tested like this? No? But this is the way, most applications have been tested, although SAP provides multiple tools to support professional application testing, fulfilling the requirements of an industry level!

And this is not only important for the quality of the application, it has a security and privacy dimension as well. Most of the security issues, I detect by auditing ABAP applications (I have to say, that I am not only a SAP consultant, but a Data Privacy Consultant, as well) are the result of a so called testing program as described above.

Now that we can figure out, where we wanna up to, let’s talk about the options of improvement. Let’s define an application lifecycle, which could fulfills the requirements of the 21st century. And, yes, you will tell me, that it’s too expensive and consuming too much time. But you won’t get your car to a garage to repair the brakes, because they are fast and cheap, just because their employees do not work like a professional and they do not have any test efforts. We are professionals and want to develop high quality applications, running fast and secure.

From requirement….

At the beginning of each software application, there is a requirement. In most cases, this requirement is detected in the functional department. The first failure, which can be made, is deeply enrooted in the one-dimensionally understanding of the business process itself. Each business process works hand in hand with others, a company’s success is the result of interaction within the business processes’ network. This means: You can not define or modify a business process by blending out other processes, even when this are processes of another department. The module centered view to an SAP system is outdated, we have to come to a business process based view, across multiple departments and multiple subsidiaries, multiple companies, including the requirements of distributors and customers. Lack of seeing the big picture is the most order reason for crippled business processes, multiple copies of similar or even the same applications in one SAP system.

…via functional specification….

After design of the business process and the interplay with others’, it has to be described in a functional specification. This specification is self-contained, which means, that a requirement, which not has been described in this document, has not been ordered! The requesting department is in charge for the completion of all requirements, because modification the business process can result in a complete redesign of the resulting application. But this document is not only describing requested features, but unwanted features as well! Most of the security related bugs in an application are caused by coding, which fulfills the requested features, but undocumented other features as well and most of them are unwanted.

…and technical specification…

After this document has been written and approved, the SAP Competence Center has to do the effort estimation in cost and time. In detail, the developer has to talk with the related functional consultants, on which way this business process can be implemented into the system. The result is a technical specification document, which describes, how the application has to be built to fulfill this requirements, including all testing and documentation efforts. In some cases, the result may be a reference to a standard application, which has been delivered with the system itself, which results into a user training document instead if a technical specification. To make sure, that this estimation consciously and accurately, there should be a standard budget for this kind of work, i. e. 2 man days, to be payed by the requesting department. We shouldn’t forget, that each employee has to report his productivity to his manager!

Of course, there is another way to get to a functional specification. In terms of sales promotion, the SAP Competence Center has to offer business process improvement suggestions to the functional departments. But this is another story.

Let’s inspect the case, that a new application has to be designed or an existing has to be enhanced. The technical specification, which shows screen mockups as well as database table descriptions and all other details of implementation, has to be sent to the person in the SAP Competence Center, who is in charge for quality management and software logistics. This person has to have a general overview to all over the system – the big picture – and has to check the specification for already existing development objects. There are many SAP systems, where multiple classes “customer” are existing and this person has to avoid side effects like this. His suggestions are to be considered.

This final technical specification has to be sent to the requesting functional department for approval, which results in the development order (or in a rejection, of course). This approval phase has the same significance, “last orders, please“ has in a British pub: From now on, no changes or enhancement of the order is possible. It tells the SAP Competence Center: Do that as described in this document!

But there is another reason for being of this document: It is the major part of the documentation, whose delivery has to be part of the application’s going live. In Germany, a manufacturer has to deliver a German end-user manual wird each B2C product – otherwise the customer can reject the product and has to get his money back, regarding to German law. This applies for televisions, smartphone devices and eBook readers, but not for SAP based applications, because the customer is a company. This does not unravel the mystery, why this kind of customers do not stipulate a documentation. “We know how that works” results into legacy coding, if the knowing employees leave the company – an often seen effects like this: There is an application, which implementation details no one really knows! Consider the employee Steve, I talked about earlier!

…to implementation’s beginning!

The first step to increase the application’s quality is the way, the developers write their coding. Most of the developers may think, they write their coding to feed the ABAP compiler. Perhaps they are of the opinion, that they have to write coding, which they can understand by themselves. But the other side of the coin is underrated: A developer has to write the coding in a way, another developer can understand! A developer with another background, with no special knowledge about special business processes. This is the reason, why coding comments have been invented! A professional developer comments EVERY NON-OBVIOUS CODING SEQUENCE! Each non-obvious context relation has to be explained. The very most important reason for this requirement is: The company owns the coding. The company owns the business process definition. And the developer is in charge to enable the company to transport this knowledge (which it has payed for!) from one developer to another. This requirement is easily overlooked by most of the SAP developers.

The most unloved working process, a developer can imagine, is writing a documentation. Despite the fact, that the coding comments are part of this documentation, there have to be two: A user documentation, which describes, how this application is to be used properly. Written by a key user, who has been involved in the functional specification design phase, represents this document a user’s view onto the application. The developer documentation, of course, should be written by the develeoper(s), to describe all technical aspects of the implementation, based on the technical specification. This documentations should be written in the system, which means, that it has to be written in SAPscript. Of course, a company can decide to take another documentation platform, i. e. a Wiki – even though these documents (which kind they ever may be) have to be linked to directly from the application. No one wants to search for a single documentation in a huge filesystem tree. We left the 80’s behind us, so we shouldn’t use the tools of this age!

Of course, the application development has to be based on the object oriented paradigm and related to MVC design pattern and each method has to be accompanied by a test class, just for it. This has lots of advantages: The specification is fixed in the application itself in the language, the developer and the system speaks. If a test is not implemented correctly, that shows that the developer did not understand this part of the specification. And another developer can retrace, why a method behaves as it does. The test class includes the following kinds of methods:

• Methods to verify requested features,

Everytime, when a developer touches the application, he can destroy requested and working features by accident.

• methods to falsify unwanted features and

An unrequested feature is to be handled like an unwanted feature, which particularly can result into security or privacy issues.

• methods to simulate all issues, detected in the user acceptance tests and the productive running application.

A bug, reported by a user, should occur never again, even when a developer touched the development object.

The result of the test class bundle is, that the whole application can be tested again and again by doing single clicks. Furthermore, this are all tests with well-defined input and output, which makes their results compareable. A developer, who can test the application this way, will never destroy any requested feature by accident! This growing test program results into a increasing application quality.

The quality manager, I mentioned before, is to be involved in the whole development process, by inspecting the whole coding for fulfilling all style guides, readability of the coding, etc. If the quality manager does not understand the coding, it’s a signal for the developer, that his comments do not fit their requirements. Keep an eye on the statement, that the company owns the coding, not the developer – which results into a coding, that another developer can understand. Finally, the quality manager decides, if the coding is good enough for going live.  Because he is in charge, legacy coding – if ever found – will come back to him, personally!

Part of the standardized going live process (woe, there ain’t one!) is a checklist, each application has to pass. User documentation complete? Developer Documentation complete? All tests, defined in the functional and the technical specification passed? Each issue, reported via ticket system, has to be mentioned, accompanied by a status report. The quality manager’s coding audit passed? Only, if all checks are passed, the going live is approved for the next release update (yeah, we have to think in release cycles!).

I am asked, frequently, by my customers, what they can do to improve their development processes. In some cases, my answer was „what processes are you talking about? This company does not have any defined development process at all!“. Somehow or other, in most cases this question results into a consulting mandate, a document like this blog post (but much more detailed and matching their individual requirements) and a speech, addressed to the SAP Competence Center crew.

Unfortunately, I have to be happy, if a company implements just a part of this ideas, I described in the document. Even big IT companies can not realize, that the SAP system has a huge value, measurable in Euro and Cent, and they do not treat their customer’s system like a treasure, the customers have entrusted to their care.

 

Further informations: Fixed price SAP forms, SAP form development, Consulting