Efficient management of vendor-built custom SAP developments

[m-skrzyniarz]

There most likely isn’t a large-scale organisation out there that doesn’t seek support from other partner companies, when it comes to building out their SAP solutions. The process of “Here is what we want built, please build it for us” looks radically different in every company I have worked with. Different rules, guidelines, naming conventions, authorisation impracticalities, project team setups, etc. - these are just some of the things that vendors have to adhere to, at least in theory.

Among all the differences, there are aspects that every company that decides to outsource SAP developments should take care of, and this is what I am aiming to cover in this post.

Why should you care about the quality of your custom SAP developments?

I could answer this with one simple sentence “Because you are paying for them”. However, it probably wouldn’t exhaust the question because some managers unfortunately still think that the cost of a custom solution is what’s on the vendor invoices, and others think that the quality of code actually does not matter.

Before we dig into details, let’s arrive at a common definition of “quality of code”:

High-quality code is efficient (performance), readable (bug-fixing), testable (maintenance), documented (handover), uses the right architecture (stability) and is cost-optimised (TCO). On the contrary, low-quality code is the opposite of the above but not necessarily all of the above combined - code that’s readable but completely inefficient is still considered bad.

So, why should you bother?

Because once the solution is signed off, it becomes your problem. Even if the vendor is in a long-term relationship with your company, they’ll not guarantee that if, in 2 years time when something goes wrong with the development, they’ll have the same person looking at it. Which means, that it’ll be treated as a new task and the effort needed to understand and correct it will highly depend on how it’s been built. Similarly, if you want to extend the solution, how it’s built will determine whether you are paying 1x or 10x.

On top of the above comes everybody’s favourite topic - upgrades. Most of the SAP-run businesses have a real problem with software upgrades due to badly written custom code they’ve been accumulating over the years of “SAP is as extensible as you want it to be - go and make it your own!”

How to govern external developments?

It’s difficult to deliver a single recipe for all development needs but here are some factors that you need to consider:

Documentation

When a manager hears the word documentation, they think - business requirement definition. When a developer hears the word documentation, they think “Oh sht, not again…”.*

The reality is - developers don’t like to document their code. Especially when it comes to filling out strange tables, copying and pasting code snippets and listing all the created development objects. Most just find it useless and do it because they are asked to.

But, imagine yourself in the shoes of a developer who is given a bug to fix and the only thing they know about the problematic application/integration/report is the name of the Fiori tile that’s used to access it - nothing else. Now, think of all the steps they need to take to find the underlying classes, extensions, OData services. Now, think of all the steps they need to take to understand each one of these custom code snippets to see what’s happening. Finally, think of the steps they need to take to understand the entire solution. Yeah, there’s a lot.

But if you had access to a database of documents, grouped by tags referring to objects that they describe - your life would become a lot easier - providing the document is well written, of course.

Every company has their own modus operandi and unfortunately, there isn’t a one-size-fits-all. But remember, mandating the use of Functional Design Documents and Technical Design Document will make your life easier, and maintenance and bug-fixing cheaper.

Static code checks

There are various solutions that SAP-run companies use to check the quality of their code. ABAP Test Cockpit, available in the standard delivery of SAP S/4HANA systems is one of them. Its traditional functionality should be well known - forbidden statements, potentially performance-impacting code or even candidates for security breaches are all highlighted either when the developer executes them explicitly, or - if integrated, during transport release.

A concept that’s worth noting here is the cloud-readiness variants that are available and can be turned on. The checks focus on cloud-compatibility, including the use of released APIs which SAP guarantees future upgrade-safety with. By ensuring that these are intact, we also mandate upgrade-safety.

Please note that not all developments will be possible with the above mentioned variants. Therefore, an exemption process must be in place not to impede your progress or worse - overcomplicate it by moving everything to the BTP, for example…

Test automation

ABAP Unit is a rather controversial topic these days - many companies still don’t see the real value in them. I am not going to try to convince you that they make sense. Instead, I’ll just say that if done - they should be integrated into your release process. Only a successful execution and the right unit test coverage should let the TR get released.

For user-facing applications (e.g. Fiori apps), I would also recommend investing in end-to-end testing solution like Tricentis Tosca (not sponsored!) which will simulate user interactions and make sure that the functionality remains as good as in the original test case.

Remember, any test automation will help to speed up the release process and reduce retesting effort after changes or upgrades. Hence, it’s worth investing your time and effort in it, especially for developments that are expected to evolve or take part in critical processes.

Tip: What to prepare before partner onboarding

So, the scope is clarified, the team is built, the project management is ready with their fancy new project board, user stories, epics and what not. The countdown is on!

3, 2, 1, GO…..

…and the vendor says they don’t have enough access, they don’t know how to create a transport, they don’t know how to request a user role, what to name the new development objects or whom to contact in case of issues.

Yes, this happens EVERYWHERE. But you know what’s the worst? YOU are paying for it… Yes, all the time wasted on waiting for transports, authorisations and replies is covered under the project cost.

So, as you can expect, it should be in YOUR best interest to provide a “Welcome pack” for developers starting a project in your company.

What should such a welcome pack consist of? Here are some ideas:

1. Gaining Access to systems - send it in advance!
2. Development and Architecture guidelines - “how we do it at Company X”
3. Document templates and processes - what needs to be filled out and when
4. Authorisation concepts - what to do to adhere to security standards
5. List of stakeholders - who are the people to contact and what roles they play
6. Deployment - How to move transports between environments
7. Testing plan - what are the different test phases, who will participate, how
8. …and more - whatever a developer needs to know to work on your systems and bring an idea all the way to production

Also, please please please - make them concise. Do NOT give the vendor a 200-page document with all of the above and expect them to follow it.

If you don’t know where to start and are preparing for onboarding a new vendor and assigning development tasks to them - let’s have a chat. I might be able to help you.

Idea: categorise developments and apply different regulations

Isn’t mandating all of the above for all developments a bit of an overkill?

you might ask. And you know what? I’ll swim against the current here and say - yes, it is. It definitely is.

This is why I recommend building a governance process based on the criticality and the complexity of the development. Applications that tick some of the following boxes would be considered good candidates for stricter governance rules:

• Involved in critical business processes
• Supporting many end users
• Need for extensibility
• Planned multiple rollouts across the organisation
• Time-critical execution

Whereas for others - e.g., simple apps with 90% standard and 10% custom logic you might want to be a bit more lenient on some aspects.

To govern or not to govern, that is the question

Govern by all means but create a model that caters for the needs of your organisation. Be flexible where you can be (not with security) and govern the hell out of critical developments.