Given reader interest, I would like to share some experiences around the internal architecture of ABAP applications: lessons learnt from applications which were robust in the face of change, and others that were more brittle to change. My idea is to raise a number of issues that should, from my point of view, be answered before a major new ABAP application is started. This might be of special interest for partner companies that start their first ABAP development, or that want to
share and exchange lessons learnt, for example using the comment feature.
Everybody who is responsible for the creation of complex, long-living software applications needs to make a lot of crucial decisions. Some of these decisions are strategic, some are of a more tactical nature, but most of them have some form of influence on the future extensibility and maintainability of the application.
Fortunately, as an architect, we do not have to reinvent the wheel. There are tons of material available, both on the net and in books and magazines. This is true not only for development environments such as Java, but also for ABAP.
Strategic aspects of an application, such as the UI technology used, the way workflows are implemented, master data management, SOA integration etc., are covered in SAP-internal architecture guidelines and the principles of Timeless Software. SAP offers partners recommendations and insights into these subjects in a publication called "SAP Guidelines for Best-Built Applications", which can be found on SDN.
Coming from another angle, the book "Official ABAP Programming Guidelines" describes principles of well-written ABAP programs, such as naming conventions, the use of ABAP Objects, robust programming techniques etc.
These sources answer many crucial questions. Following them, an architect can assure that the right technologies are chosen, the right strategies for application management applied, that the coding itself will be robust etc. So, the architect's job is done, right?
Well, maybe not quite. Between the level of the strategic guidance given in the internal and external guidelines, and the level of well-programmed classes, subroutines, function modules and reports, there is another layer of architectural decisions that can make or break an application from the point of view of maintainability, stability and future readiness.
My intention is to address some of these architectural topics in a series of SDN blogs. In each blog, I will describe an architectural challenge and provide examples of potential solutions. I do not claim to know all the answers to all uestions from different application scenarios; it is not my intention to provide the definite guide to ABAP architecture decisions. However, whatever answer an architect or a team finds to an important issue, if the issue is thought and talked about, and a conscious decision has been made on how to address it, there will be a lot of benefit compared to an application that does not even ask the question before the implementation starts. I am talking from experience here...
So, if you are interested in a list of topics on the "internal workings" of an ABAP application, feel free to comment. If you have ideas for subjects that could be covered, also do so.
