Functional custom application design specifications resulting from traditional SAP gap analysis methodologies usually consist of a series of one-off requirement documents. Later these are typically each assigned individually and separately to different ABAP developers without much regard for the tendency of many of these custom applications to have similar or even identical components or subprocesses. Each of these subprocesses is then replicated by each programmer as they create their programs. Of course, one programmer may not create the same subprocess in an identical way as another programmer.

A better approach for creating functional specifications is based loosely on the enterprise service-oriented architecture (enterprise SOA) paradigm and use of ABAP Objects. SOA development seeks to identify the multiple individual and discreet reusable services or processes that are required to accomplish various business procedures rather than viewing each business procedure as a single, standalone entity. Once a reusable service has been developed for use in the implementation of one business procedure, it can be reused to implement another. This speeds the overall development and achieves standardization of services. If functional analysts adjust their thinking and use this approach, they can lay the groundwork for more successful custom application development and implementation.

Why ABAP Objects?

The outsourcing of custom application development is on the rise and so are the problems associated with foreign or remote programmers not really understanding what an actual business process is supposed to do. The outsource programmer might be good at creating nice-looking report output but bad at understanding a specialized business process unique to a particular company. In fact, these problems are largely inherent in the design process itself and are only accentuated by the additional difficulties presented by remote development.

Instead of the all-inclusive, one-off design specifications usually created for a custom development application, the design document should reference a series of discrete, reusable processes or services that, when aligned in a particular order, create the desired application. By decomposing an application into its related processes or services it becomes easier to assign the development of simple or common services to a remote developer while retaining the development of the more complex and critical processes and services. ABAP Objects are the key to facilitating this type of development.

Why Should Functional Analysts Care?

A basic question likely comes to mind: Why should I care how the programmers implement the functionality I need for my custom ABAP applications? Won’t the programmers handle all of that later when they come on the project?

The reason is that the functional analysis usually takes place well before the arrival of any technical analysts on the project. After blueprinting analysis has been completed and accepted, most project managers and users don’t expect and cannot easily accept any design or concept changes at a later date. They have a hard time accepting that a technical analyst wants to revisit the already accepted specifications.

Consequently, most programmers are loath to even question existing specifications let alone try to change or rework the paradigm under which they were created. Most technical analysts would rather program a custom application using less than optimal programming techniques than question preexisting functional specifications, even if those specifications are not logical or consistent. This is particularly true in an outsource environment where the programmers are separate from the actual client site and are often paid by the hour rather than by the number of successful programs that they create.

The authors of Enhancing the Quality of ABAP Development, Albert Krouwels, Ben Meijs, Wouter Heuvelmans, and Ron Sommen, discuss the need for better technical quality in custom ABAP development. Often, faulty programs result from an incomplete requirements gathering phase. Both functional and programming teams need to understand each other to create great programs. Functional teams should make a greater effort to require the technical robustness that an SOA approach to programming can deliver. If they don’t make these requirements explicitly, there may well be no other group that will. Usually this leaves the client exposed to future disasters and mired in a difficult code maintenance quagmire.

On the technical side, ABAP developers should make a real effort to use ABAP Objects because it offers greater flexibility. However, they often choose not to. This may be because OO programming requires programmers to think differently, and they would rather program in the manner in which they are accustomed.

If a project is to benefit from a new approach to custom application design and specification, that approach must be utilized from the start by the functional analysts that are the first on the scene.

ABAP Objects vs. Function Modules

Because most HR functional analysts have heard of ABAP function modules, it’s a good place to start when describing ABAP Objects. HR functional analysts know that a function module serves as a software container that handles a specific business process or service. The software for this business process has been put in a function module instead of an application program so that many different application programs can use and reuse it, while providing constant results to each program. The function module can encapsulate the business process so that it is easily reusable. Function modules that perform similar or related processes and services are grouped together in a function group. The function modules that reside within a function group can share the data variables stored in the global area of the function group.

An ABAP Object can do the same things that a function group does and a whole lot more. The methods within an ABAP Object are analogous to the function modules within a function group. The object’s methods perform similar or related business processes and services and can share data stored in the object’s global attributes. However, the global data areas within an ABAP Object are also visible to the application programs that use them, while the global data areas of function modules are not. Like function modules, many different application programs can use and reuse the business processes and services encapsulated within an ABAP Object to deliver consistent results to each program that uses them. While a function module within an applications program can be called many times during the course of the applications logic and execution, it and its data exist only once within the program’s memory area. An ABAP Object is not limited in this way.

An ABAP Object is included within an application program’s coding using a special data variable called a reference or pointer. This means that you can include an ABAP Object as many times as there are reference variables of that type in the application program. Each one of these reference variables represents a unique instance of the ABAP Object; each with its own set of global data attributes. Therefore, a set of data representing a unique instance of a business process or service can remain in the program’s memory area along with other objects of the same type representing other unique instances of the same business process or service. Why would this be important?

Let’s set up a simple example involving the calculation and comparison of the costs of different benefit plans available to an employee. During enrollment the employee might want to compare the costs of two plans while simultaneously adjusting the different options available within each plan. I’ll set up two reference variables that both are of the ABAP Object type Benefit_Plan. One reference variable is called Plan_A and the other is Plan_B. Since both Plan_A and Plan_B use the same ABAP Object definition they both have the methods of Calculate_Cost and Set_Coverage.

The application program loads each version of the object with the employee’s HR data pertinent to benefits and the various values configured for the benefit plan that it represents. From this point on, the employee is able to interact with Plan_A and Plan_B at the same time by setting different coverage levels for each independently of the other. The employee uses the Set_Coverage method and compares the cost of each plan using the Calculate_Cost method.

To do this with a function module would require first loading the values for one plan into the function module and calculating its cost and then loading the values for the other plan into the function module to get its cost. Using a function module, every time the employee wants to change plan options, the entire set of plan values would need to be reloaded. With two object references, the data for each plan stays resident in memory without the need to reload.

As you can see from my example, function modules and the other standard procedural programming concepts such as simple programs and subroutine pools lack much of the flexibility inherent in ABAP Objects. As the authors of Enhancing the Quality of ABAP Development note, function modules are a technical concept, so they do not immediately correlate directly into objects from real-life business requirements. Therefore, functional and technical teams need to come to an agreement based on the model of reality used rather than focus on technical considerations.

Extend the Idea of Multiple Object References

The feature that allows you to make multiple references to the same object type leads to some interesting ideas about how you can maintain multiple instances or entities of the same object type simultaneously within an application program. Suppose you define an ABAP Object type of Employee. The global data attributes of object type Employee contain pertinent data from Personnel Administration (PA) infotype tables. The methods of object type Employee include one called Set_Salary that encapsulates the business process or service needed to change the salary field on an employee’s infotype 0008.

Because the reference variables used to represent each instance of the Employee object within an application program are of the same type (Employee) you can make them rows in a table. This means that you can have a table of Employee objects. Since a table is simply another type of data variable, you can have a table of Employee objects as a global data attribute of another type of ABAP Object I’ll call Organizational_Unit. Of course it’s possible to have a table of Organizational_Unit objects as well. Imagine then that the Organizational_Unit object has three methods named Calculate_Performance, Calculate_Merit_Increase, and Set_Employees_Salaries. The first method calculates the overall performance of an organizational unit and the second calculates the percentage of salary increase due to the organizational unit’s employees.

Suppose you have an application program that creates a table of selected Organizational_Unit objects. By looping at the rows in its table of Organizational_Unit objects, my example application program can easily request each organizational unit object to calculate its own performance and determine the merit increase percentage for its employees. Then, using the third method, Set_Employees_Salaries, the application program can request each Organizational_Unit object to loop at the rows of its own table of Employee objects and set their salaries using each Employee object’s method Set_Salary. Of course, the Employee object’s method Set_Salary will be in use in a number of other application programs that also work with an employee’s infotype 0008. I will expand upon this idea of ABAP Object reusability in the next section.

Before leaving this section on multiple object references I would like to say a quick, non-technical word about sub- classes and the technical sounding (but really cool) concept of polymorphism. These concepts are not hard to understand and I will use familiar HR terminology to explain them. You have seen how you can use and reuse an Employee object in a variety of ways and applications. However, in reality you have different types of employees. For instance, some employees are also supervisors. Should you then create a different ABAP Object class for supervisors? Of course not. A supervisor is just a special type of employee and shares most if not all of the attributes that a regular employee possesses.

To model a supervisor you simply extend the employee class to include those attributes and functionality that are specific to the supervisory role. To extend an existing class, you create a sub-class of the original class. A sub-class retains all the functionality of the base class but usually has additional data attributes and methods that add special functionality.

One of the most useful benefits of this approach is that within an application program you can still use a basic Employee object reference variable to address the supervisor object. When necessary, you can address the very same application memory location with a different data reference or pointer based on the more specific supervisor class when the extended supervisory role functionality is needed. Hence, the supervisor class can take many forms (i.e., it is polymorphic). One time it can appear as a regular employee and another time it can look like a supervisor. This is true even for the same instance of the supervisor object (memory location) within a single application program.

ABAP Object Reusability and Developing a Services Library

As you saw in the last section, once a business process or service has been encapsulated within an ABAP Object it can and should be used as needed by any application program or other ABAP Object. It is not necessary, and certainly not desirable, to recreate the business process or service again in any other application program or other ABAP Object. There should be only one official, reusable version of the implementation of a particular business process or service. This requires a critical shift of your analysis paradigm.

During a project’s gap analysis phase, many of the end products are often custom ABAP development applications. These custom development applications are usually defined and specified in isolation from other gap analysis exercises and their end products. Typically, during the project’s implementation phase, each of these custom application development end products is assigned independently and in its entirety to an individual ABAP developer. Usually, no real effort is made to match up specific business logic within one custom development application with similar or even identical logic within other custom development applications.

The results of this typical design paradigm, which I have personally witnessed all too often, are a series of custom ABAP programs in which the same process is implemented over and over again from one custom program to another. Either the same program code is copied from one custom application program to another or the same process is implemented independently within each custom application program per its developer’s personal preferences. Often one developer is somewhat more successful in perfecting the same complex business process within his or her program than the other developers given the same task. Ultimately the client is left with an unmanageable hodgepodge of custom applications where supposedly identical business processes sometimes give the same results and sometimes not.

The above paradigm is always a source of implementation problems but is a particularly consistent recipe for disaster when custom development outsource arrangements have been put in place. How can it be expected, why is it even desirable, that a developer in a remote or foreign location be tasked with the program implementation of a set of critical, complex business process and logical operations often specific to a single client? While this has never made any sense, it is increasingly the paradigm adopted in SAP implementation projects. Ostensibly sold as a cost-cutting measure, this approach typically results in massive reprogramming efforts and delayed go-live dates. While it is not reasonable to expect that project managers will not continue to try to save money by using outsource vendors, it is reasonable to expect that it should be done with some realistic understanding of what processes and services can be outsourced successfully and which should be developed locally using industry experienced technical professionals with direct access to the client’s personnel most familiar with the most critical business processes and requirements. A new gap analysis and design paradigm is needed.

This new gap analysis and design paradigm must focus more on identifying unique business processes and less on the description of individual application program development specifications. In keeping with the current enterprise SOA approach to design and development, this new gap analysis process should concentrate on identifying which of the client’s business processes are missing in the standard SAP applications with the idea of tasking the ABAP custom development team to create services to implement those processes. Remember that an SOA approach means identifying individual services or discrete processes rather than entire applications. An application will consist of numerous services, many of which will also be in use by other applications. This additional level of detail means more involvement of the functional team in the custom application design process rather than less.

Each custom development application identified in the gap analysis exercises should be viewed as, and broken down into, a series of specific service requirements instead of being viewed as a self-contained development entity. Initially this requires substantial effort. For instance, a 401(k) post payroll interface to an investment management provider requires many more services than just the one that formats the data to meet the provider’s data exchange interface requirement. Specifically, you need a payroll data retrieval service. Functional analysts familiar with payroll processing will recognize that the payroll data retrieval process is not a simple one that can be left to just any ABAP programmer. Too often this payroll data retrieval process is just a given in many development design specifications, usually with less than perfect results. For more details about this 401(k) example, refer to the “Example of a Custom Application Specification” sidebar.

Instead, a payroll data retrieval service should be specified in detail and the role of specific wage types and the requirements for current period and retro analysis completely defined. Even such prosaic services as report headers and footers need to be clearly defined by functional staff if they do not exist.

As a technical service is specified for each required business process, you should catalogue a brief description of the service in a generally accessible repository. Over time, during the analysis cycle, the specifications for custom development application programs will become easier and easier as it becomes increasingly possible to reuse previously defined services to complete the design specifications for an individual custom application program. More importantly, this same efficiency is realized in the actual development of these custom applications. Instead of reinventing all needed services within each and every custom development application, the developer functions more as the orchestrator of a series of service calls with perhaps some final unique data presentation development requirements.

In the course of writing this article I have consulted with several very experienced HCM functional consultants. One consultant told me that she does something similar when conducting blueprinting session. She starts out with documenting the most basic requirements and their proceeds to those that are more complex knowing that some of the basic processes identified can be reused in the documentation of the more complex business requirements. She also provides interesting insight that once a catalog or repository of services has been compiled, some of the future functional analysis of additional application requirements can be turned over to more junior, less experienced functional personnel, thus providing more efficiency and flexibility in the functional analysis phases of a project.

Technical Implementation of the Services within the Library

Once the functional, management, and technical staff have been liberated from the narrow, dysfunctional paradigm of viewing each custom development application as a separate, self-contained development entity and replaced with the idea of creating services based on custom ABAP Object classes, it will be possible to manage custom development efforts in a highly efficient, cost effective, and, most importantly, quality assurance manner. Firstly, the development of highly critical business processes and services will be the purveyance of the main implementation team with access to critical company resources and assigned to industry experienced technical developers. Secondly, less critical services such as report headers or use of a company’s system resources could be assigned to the company’s own less experienced ABAP developers. Finally, custom application programs which may have standard or even unique data presentation requirements but need only to access critical business processes as predefined services could be successfully outsourced anywhere.

Envision the New Development Paradigm

As a functional analyst, imagine yourself as a distinguished symphony orchestra conductor. To present a successful concert you must simultaneously and precisely direct the services of more than 100 individual musical service providers. While you may have been instrumental in the selection and even the training of many of the musicians under your direction, for the purposes of the concert presentation, only the competent coordination of the delivery of the musical services need concern you. You don’t care how the flutists got to the concert hall this evening nor do you care what brand of strings is used by each of the violinists. All of those things have been predefined or handled by the service providers themselves.

As you have several compositions on this evening’s program that you are going to present to your audience, you will wish to reuse the musical services available to you but in a different order than in the previous piece. You won’t be needing to call the musical service providers to again come in to the concert hall from their homes as they are already there, just as a previously instantiated ABAP Object service already exists and can be reused again and again to provide its services as required.

Tell a Story

As I mentioned previously, I have discussed this design paradigm with a number of seasoned SAP professionals. One experienced technical consultant described his excellent advice to his client’s functional analysts as simply “Tell a story.” Can you determine which story I used to design this bit of coding example (Figure 1)?

Data:
Little_pig_1 type ref to zcl_little_piggy,
Little_pig_2 type ref to zcl_little_piggy,
Little_pig_3 type ref to zcl_little_piggy,
House_1 type ref to zcl_piggy_house,
House_2 type ref to zcl_piggy_house,
House_3 type ref to zcl_piggy_house,
BB_wolf type ref to zcl_big_bad_wolf.
Create object little_pig_1.
Create object little_pig_2.
Create object little_pig_3.
Create object bb_wolf.
Call method little_pig_1->create_house
Exporting
 Materials = ‘STRAW’
Importing
 House = House_1.
Call method little_pig_2->create_house
Exporting
 Materials = ‘STICKS’
Importing
 House = House_2.
Call method little_pig_3- >create_house
Exporting
 Materials = ‘BRICKS’
Importing
 House = House_3.
Call method bb_wolf->huff_n_puff
Exporting
 Piggy = little_pig_1
 House = house_1
Exceptions
 No_collapse = 1.
If sy-subrc = 0.
Call method little_pig_1->escape_to
Exporting 
 Target_house = house_2.
Else.
Call method little_pig_1->start_fireplace
Exporting
 House = house_1.
Call method bb_wolf->climb_down_chimney
Exporting
 Target_house = house_1.
Exit program.
Endif.

The work assignment for the developer of this interface is largely confined to reformatting the data collected by the standard data collection services into the output interface structure file format; the only process unique to this interface. Since data reformatting is a relatively simple procedure, the development work of this 401(k) interface is a likely a candidate for junior or outsourced programming staff. Development of the data collection and file transfer services will be assigned to the appropriate senior on-site technical development and system management staff.

Provider XYZ 401(k) Interface Specification

The purpose of this specification is to define the requirements for the required data interface between the company and 401(k) management provider XYZ.

1. This interface runs as a background process after each payroll run has successfully completed.
   
   
2. The interface includes the following screens, processes, and services:
   
   
   • Data Selection Screen with the following elements
     
     
     • Payroll Area select options
       
       
     • Payroll Period select parameter
       
       
     • Employee Number select options
       
       
     • Regular 401(k) Contribution Wage type select options
       
       
     • Catch up 401(k) Contribution Wage type select options
       
       
     • Loan Repayment Wage type select options
       
       
     • Employer Match Wage type select options
       
       
     • Logical File name for Interface file location
       
       
   • The Employee Data Collection Service retrieves the following current employee data elements: (See the description and specifications for the “Employee Data Collection Service for HR Reporting.”)
     
     
     • Employee Social Security number (SSN)
       
       
     • Employee last name, first name, and middle initial
       
       
     • Employee status
       
       
     • Employee annul salary
       
       
     • Employee officer status
       
       
     • Employee plan enrollment date
       
       
     • Employee adjusted service date
       
       
     • Employee plan eligibility date
       
       
     • Employee birth date
       
       
   • The Employee Payroll Data Collection Service retrieves the following pay period payroll information inclusive of all retro calculations in the selected pay period: (See the description and specifications for the “Employee Payroll Data Collection Service for Payroll Reporting.”)
     
     
     • Gross wages
       
       
     • Regular 401(k) contribution
       
       
     • Catch up 401(k) contribution
       
       
     • Loan repayment amount(s)
       
       
     • Employer 401(k) match contribution
       
       
   • The employee and payroll data collected will be formatted and converted into the interface file structure definition provided by 401(k) management provider XYZ. (See file structure layout and mapping document addendum 1.)
     
     
   • The formatted interface file will be submitted to the Logical File output service to create a transmittable file using archival parameter 1. (See the description and specifications for the logical file output and archival service.)
     
     
   • Any errors encountered by the interface will be written to the batch spool area via the Error Reporting Service using Report Header service option 1E. (See the description and specifications for Error Reporting Service.)
     
     
   • Record counts and amount totals accumulated by the interface will be written to the batch spool area via the Report Statistics Reporting Service using Report Header service option 1R. (See the description and specifications for Report Statistics Reporting Service.)
     
     
   • The output file generated by the interface will be sent to 401(k) management provider XYZ’s information center using the FTP Interface Service using parameter XYZ401k. (See the description and specifications for FTP Interface Transmission Service.