Modular Design and OOP – How bad do you want it?

This blog is a bit different from the more technical ones because it is essentially describes a “what if” scenario, which I don’t think will ever be implemented. Regardless, I believe the idea is interesting enough to “put to paper” and discuss.

It comes in the sequence of all the blog posts surrounding Unit Testing, including my own, where we discuss modular design as a requirement for unit tests, and good code in general. We also come to the conclusion that most people don’t do it, and it’s hard to force change. Force is the key idea, what if you, as a SAP manager, really wanted to force your team to do it?

My crazy pitch? Make some of your developers use a Developer Edition without SAP_APPL or any other functional modules. Read along if you’re intrigued.

A pratical example

This week I’ve been analysing some developments around EWM and Fiori (for warehouse operations) and was faced with three situations:

• Not being able to take advantage of a Fiori suite for warehouse operations designed for WM (not EWM) when the business processes are the same;
• Seing a Gateway service that directly calls a EWM Function module;
• Not being able to access the Fiori instance because it was not connected to the corporate VPN. I had to create tests on my local “Docked” ABAP AS and Cloud Platform Web IDE. (Thanks a lot Nabi Zamani ).

I looked at the existing code and in general it is good code (especially on the Fiori side) but there was no focus on reusability as the Fiori/Gateway was completely hardwired to EWM. If I ever wanted to use this with normal WM I would have to rewrite everything,

Gateway and modular design

I know Gateway gives you some model generation tools where you can use ABAP dictionary structures and function modules do create entities and entity sets. Don’t. Don’t use them if you want to have the slightest chance of having a modular design.

• Your data model will be tied to the specific module, including data elements;
• The model is designed around how that particular module works, instead of the business requirements.
• It kills modular design as what should be your repository layer (API calls) is tied to the frontend.

Call me old fashioned but I like to write my own OData services code, and it helps in the shift to OData v4 (and trust me you’ll want to shift to V4 when SAPUI5 is completely compatible).

So what happens when you have a Developer Edition without SAP_APPL or EWM? You can’t use the Function Modules or the Data Elements (Win!). I used “Strings” and general objects like collections and hash maps, so nothing is tied to a particular functional module like EWM.

Repository Layer as Plugins and Unit Tests

The second impact of having no EWM on my machine, is that I can’t create the repository layer. No databases to call, no EWM BAPIs. So what does this force me to do? Use an Interface to abstract all my API/DB calls and create a mock class so I can run the code.

This mock class needs to create test data of course, which I can reuse for my unit tests. By forcing myself to have a separated class for all the DB/API code, I made the code testable.

In this model, you can think of the repository layer as a plugin. As I abstracted the business logic on the interface level, I can then write a repository class for EWM and another for WM (this plugin can only be developed in an instance with EWM/WM).

Tie this to ABAPGit, where you have a repository for the generic app, and others for the plugins, and you have a highly scalable development landscape.

Fiori, Cloud Platform and MockServer

On the Fiori (frontend) front this means you’ll easily separate what is your business model from EWM which will speed up your process. You can even have a Fiori/Gateway guy doing your business logic, and more traditional ABAPers creating the plugins. Even if you want to use the backend server, you have test data supplied by your mock.

Fiori/Gateway teams can interact faster with the business users using SAP Web IDE mocking server to quickly iterate without the constant need for a EWM (insert other module) consultant.

In terms of Cloud Platform, do I think it is critical? I’m on the fence on that one. On one hand it does speed up the process, and if you are using Cloud Platform Portals the integration with the Fiori Launchpad is great. If you’re not using Portals, SAP Web IDE will nevertheless speed up the process because of the Gateway automatic mocking and metadata synching (this is important for quick iteration).

The downside

Of course this has downsides (which is why nobody actually does it). I can think of several:

• Keeping your developer machines updated;
• Still no HANA on the developer ABAP AS;
• Having a large enough team to split your developers into two groups;
• Having a budget that makes it worth the modularisation.
• Changing developer mindset.
• You can do all this with code guidelines and code review and force this without all the extra work.

The last one is the most important. Most companies have ridiculous coding guidelines like the one that forces you to use ZCL_ to name a class when it’s redundant, but have no guidelines in place for actual coding practices. It’s a lot simpler then going through all this trouble just to have modular code.

As a last comment, one that my Development Lead may read, the EWM “plugin” still needs to be written by “someone”. 🙂 Truly modular design at work.