The “not invented here” syndrome is a well known anti-pattern in software development. It describes the fact that a developer usually is keener on developing a solution on his own than looking for an already existing solution and using it. Another symptom is that the developer knows about the solution, but neglects it because it is not “good enough” (as it was not invented by him/her). In the best case the syndrome causes more costs in the unnecessary development of a software component, in the worst but more usual case the costs summed up over the complete software life cycle are increased (not to talk about the negative impacts on the architecture and the solution landscape).
Taking a closer look at the syndrome two variants can be observed:
- Variant 1: The developer/architect “neglects” tools that can be used to support the development of a solution
- Variant 2: The developer/architect “neglects” a complete component that can be re-used in the final solution.
I observed both variants in the product development as well as in customer development projects, so from my experience both sides of the software development can improve their habits and especially in the SAP universe both variants can very often be avoided.
Let us take a look at the variant 1. Usually when introducing standard software at customer site (in my case FS-PM) you will come to a requirement that is not (yet) covered by the module itself. The only way to fulfill the requirement is, hence, to enhance the product or even to create a new (sub-) component (hopefully in accordance with the overall architecture). This is already some work to do, i. e. fulfilling the business requirement, so why bothering beside that with the creation of the tools to develop the solution? You would not re-invent a hammer or a drill machine when you have some repairs to do, wouldn’t you? So why doing so, when you develop software? The SAP stack offers a lot of tools to support you when implementing your solution, so use them. Big promise … here are several examples:
- You decided to build an ABAP code generator. You need code templates and a parser for them. Why not use the Code Composer (package SCCMP, main class CL_CMP_COMPOSER)?
- You need a wizard (= guided procedure) in ABAP to support the data entry for the code generator mentioned above. Take a look at the SAP Wizard Builder (transaction SBPT_WIZARD_BUILDER)
- You have to solve some financial mathematics stuff. Ever had a dive into the FIMA package in your system? Perhaps the solution is waiting there.
As you can already guess from those examples that there are a lot of tools available which help you in your development. To find most of the tools it is worth to take a look at the re-use library in your system (transaction SE83). Sometimes also “unusual” usage of the SAP tools might help you, e. g. the usage of filter-BAdIs as class factories (see this SDN article)
Variant 2 is even worse than variant 1. While variant 1 usually has a low to medium impact on your system with respect to maintainability and the options for future enhancements (which is already bad enough), variant 2 deeply harms the architecture. To avoid misunderstandings we are talking here about the creation a complete component that is build from scratch without any need. What do I mean with that? For sure nobody would try to rebuild the collection and disbursement module FS-CD. Yes here I am also quite optimistic that this will not happen, but when it comes to loan processing my optimism already largely decreases.
Another example I came across is business rule management. Here I know several cases where some sophisticated customizing and rules-engine like algorithms have been implemented (and those cases are not restricted to implementations on customer site but also in standard modules). What was the consequence of that? You have to make sure that the framework, i. e. the rules processing works as well as the business content is correct. To make a long story short: there was no success story behind those attempts. Here the Business Rule Framework pluswith its mighty expressions surly would have been a fitting solution and would have helped to concentrate on the important topic namely developing the business content.
At this point I can already hear some developers gasp and hear them say “but this solution does not fit my needs 100%”. Yes … maybe. But has there to be a 100% match of the requirement or are there also some use-cases tackled that are not really needed to fulfill the business needs? If there is a gap perhaps you/ the business department can use that to streamline their business and get rid of some unnecessary “waste” in their process (here the word “muda” in the context of the Toyota production principle comes to my mind). So before throwing away a rock-solid 80% solution, clearly identify the gaps and discuss if they are really gaps or just very very nice-to-haves e. g. that the business situation that is covered only happens very rarely and there is a manual workaround for that issue, too. This should be acceptable when comparing the costs of a very complex solution for a situation that will happen only once a century.
Especially in the huge universe of existing SAP applications it is always worth a closer look if there might be a fitting solution. The re-use library mentioned above is also useful starting point for this variant, too.
What is the bottom line: Usually it is already quite hard work to fulfill the businessrequirements, so we should avoid unnecessary work wherever possible and stick to established solutions available in the SAP stack. Even if the solution is not 100% fitting you should give it a try keeping the 80-20 law in mind. From my understanding this is one corner-stone on the way to a “SAP Guidelines for Best-Built Applications” in accordance with the Timeless Software: Part 1.