Business Models (BM) Diagrams

[iftah_peretz]

Most of the times we are told as ABAPers that we are handling the "what" side rather then "how to" side of things.

However, this old fashion concept has long left the domains of the IT world, nowadays the process, in our case, at most times, the business process is a major part in a well, full functional and  precise ABAP based solution.

The integration of the solutions and of the concepts around each problem that arises in the organization may differ from one to the other and is a subject to different factors, such as the type of industry , scale of the firm, experience within etc. Keeping that in mind it will still be a reasonable assumption to divide the process of solving a problem to the people the analyze the process and say the "how" and to those who carry out the technical part of it which, in turn, determine the "what", even if the situation is that the same person is doing that, still the hats he wears are alter.

In my mind, the core of those two parts of the whole should come down to the business process at hand, a not easy task, and at times tiring, in a system that is said to have more lines of code then any other existing operating system (SAP is not an operating system, or is it?).

Business process are a field that is rapidly growing and is the main focus of major CS departments around the world, creating the notation(such as UML, ERD, BPMN - see links for more on the latter), analyzing the Business Process (for completeness, safeness, soundness and so on), translating process from one system to the other (using Process mining for example) and between notations - that are now becoming the blue prints for every business (process) based decision.

The only question is how do we start? as an Implementor we are bound to research the documentation, consult with wiser more "ripe" and with history of similar projects, try and fail  numerous times(and the list goes on) until we can seat down and break the problem into its smaller parts that will eventually be solved in a manner that best fits the organization.

As a programmer  you have to grasp the process at hand and the concurrent/joined ones that will be affected from the required change, test for various cases (normal, end points and ridiculous extremes. that are bound to happen), strive for a cleaner code and logics, relate to similar algorithms and match the expected runtime and space(and the list goes on) until you can start to think on the  debugging the code at hand.

As I have to wear both hats, due to life constrains, slowly sinking in the sheer magnitude of the issue and that to us all - creatures of the IT world - Business models are the key for SAP standard.

I will end this with some small,simple, poorly written, code to help both of the parties to have a basic concept of what is going on:

REPORT  ZBM_DIAGRAM.

DATA OREF TYPE REF TO CX_ROOT.
TRY.
TYPES:
BEGIN OF BMT_MODEL,
PARENT_TYP       LIKE DF40D-PARENT_TYP,
PARENT_OBJ       LIKE DF40D-PARENT_OBJ,
AS4LOCAL         LIKE DF40D-AS4LOCAL,
MODEL_TYP        LIKE DF40D-MODEL_TYP,
END OF BMT_MODEL.
DATA MODEL TYPE  BMT_MODEL OCCURS 0 WITH HEADER LINE.
DATA MODELS TYPE  BMT_MODEL OCCURS 0.
"An example BM
SELECT PARENT_TYP PARENT_OBJ AS4LOCAL MODEL_TYP UP TO 1 ROWS
    FROM DF40D INTO MODEL.
APPEND MODEL TO MODELS.
ENDSELECT.
IF MODELS IS NOT INITIAL.
CALL FUNCTION 'BM_DIAGRAMS_SHOW'
   EXPORTING
     MODELS        = MODELS .
ENDIF.
CATCH CX_ROOT INTO OREF.
   MESSAGE 'Back to the drawing board' TYPE 'E'.
ENDTRY.

BPMN wiki

http://www.bpmb.de/index.php/BPMNPoster