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.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Volker Wegert
    Christian,

    your article comprises a great explanation of the well-known NIH syndrome. However, I think you should allow some halftones in the black-and-white picture you’re painting. Sometimes you reinvent stuff because whatever is already present is not usable for technical or non-technical reasons (ever used a function module from HR and then ran into an issue where HR was not installed on the customer system?). Sometimes you reinvent stuff because whatever is already present is unsupported, unreliable, undocumented or everything at once. Sometimes you fork off your own copy of existing stuff because it has evolved in a direction that makes it unusable for your purposes and you can’t convice the author to change it. And sometimes you reinvent stuff because you simply don’t know about the existing stuff.

    > Why not use the Code Composer?
    1. Because the entire package is flagged as “SAP INTERNAL USAGE”, at least on my systems.
    2. Because there’s virtually no documentation.
    3. Because there are no obvious examples in that package.

    > Take a look at the SAP Wizard Builder
    Cool stuff, but as soon as you need bigger screens, you’re stuck. Ever tried to put a 15-column ALV grid inside a SBPT_WB-Wizard?

    > To find most of the tools it is worth to take a look at the re-use library in your system.
    It would be really nice if this was the case, but it isn’t. The contents of the reuse library leave much to be desired. And take a look at the examples you chose – where is the Code Composer or the Wizard Builder documented in the reuse library? What about BRF+?

    From my point of view, you’re oversimplifying things a bit. If your customers are happy about paying 120% for extended discussions about their own business and only getting 80% of what they asked for, fine – mine usually aren’t…

      Volker

    (0) 
    1. Christian Lechner Post author
      Hi Volker,

      thanks for your detailed feedback on the blog. I am quite aware of the fact that the statements are a little bit one-sided and also I also know that most of the time you have to make compromises in projects and I can follow all your examples without any doubt. 
      Nevertheless I am convinced that we sometimes do not spend enough energy in trying to find existing solutions that can be re-used. If there are restrictions that make a re-use impossible it is ok to find another solution but if not I can see no reason to search for the tools and if found give them a try.

      > Code Composer: I am aware that it is marked as internal, so you are not in the 100% safe side, but at least better than building that thing yourself. The documentation is an issue: Did you try to get in touch with the corresponding responsible at SAP?

      > Wizard Builder: The Wizard builder has his limits, but up to that point (I guess you agree) the tool is really useful

      > The re-use library can and should be enhanced, but it can be used at least as a starting point. Being aware that there is a re-use layer existing is already one step forward in avoiding the NIH-pattern.

      Concerning the statement of oversimplification I think we have a misunderstanding that I want to clarify: I definitely do not state the goal is to let the customer pay 120% for an 80% solution (perhaps you oversimplify a little bit here :-). My statement, hence is to get the customer what he needs! Nevertheless I often had requirements that seemed to be essential but turned out not to be. So I guess it is sometimes worth to do a little questioning before simply going ahead (or to have a very good requirements engineer).

      BR Christian

      (0) 
  2. Michelle Crapo
    There are so many SAP functions you can use.  “Not invented here”.   Even simple solutions – number ranges, table maintenance generation, maintenance views, change documents, text objects, and more.

    But what you’ve touched on is the 80/20 rule if the SAP solution without development is 80% of what the user wants – why develop anything?  Maybe that 20% is the most important.  Maybe there is a lack of knowledge of SAP solutions.  Again many many reasons.

    SAP used to suggest making clones of their programs and then making the changes in the clones.  Now it is the reverse, make the changes to the code.  Enhancement points, BADI, BAPI – with code around it, user exit – all of these give us greater flexibility.

    Another great transaction is ABAPDOCU.  I by the way see this as a problem of the technical designer.  Hopefully that is the developer.  Sadly, sometimes it is not.  The functional designer has a role in this as well.  They must work together for a great solution.

    BR,

    Michelle

    (0) 

Leave a Reply