Skip to Content

Mr Eugene Lewis Fordsworthe initially said assumption is the mother of all mistakes. He later said his earlier philosophy that assumption is the mother of all mistakes was flawed, and he recognized that sometimes good comes from assumptions. He said that sometimes when there is not enough information, a person must make assumptions to continue progress. He was later quoted as saying “I am in a bit of a paradox, for I have assumed that there is no good in assuming.”

If there is not enough information but an objective needs to be met quickly, then making an assumption is a good thing. Some would call that situation as “the glass is half-full”.

Recently I worked on a project to “Upgrade, Convert to Unicode and Split Dual Stack” NetWeaver 7.0 BW system from Support Pack Stack 16 to EhP1 SP 07.

I had less than 3.5 months to complete the project. The landscape had Production like Sandbox, Dev, Production like QA and Production system. The DB size was 1.2TB. 

During that 3 months, I made several assumptions. Listed below are a few of notable assumptions:

Assumption 1: Upgrade

I spent a few days reading and downloading materials listed in the Upgrade section of Service Marketplace. I realized-two or three days later-our intended “from-to” support pack level was not treated as Upgrade by SAP. See this screenshot:(From Upgrade Guide SAP NetWeaver 7.0 Application Server ABAP including Enhancement Package 1 Support Release 1)

upgrade or not

Assumption 2: Installation of EhP on an existing system is considered upgrade

See the screenshot below. That screenshot shows a few lines found in SAPehpi log. The log states SAPehpi started in UPGRADE mode. I’m not sure if that is semantically correct. Installation in UPGRADE mode? Confusing. 

EHPI

Assumption 3: SAPup and SAPehpi are not different

When I noticed “This is UNICODE SAPehpi”, I was confused because the BW system to be upgraded was not Unicode. I was trying to find more information in service marketplace on non-unicode version of SAPehpi. I ran into this(See below) comment of note: 1146578. Since I lost a few days already due to assumption (1), I didn’t pay close attention. As a result, I thought I was using correct version of SAPehpi. I missed to see the subtle difference between SAPehpi and SAPup. So I continued with “SAPehpi started in UPGRADE mode”.

Conclusion

The project was technically completed in less than 3.5 months. 

Had I not made assumptions, I believe I wouldn’t have made progress and completed the project in time.

Currently I’m revisiting my notes to share a strong story in TechEd 2011. And it feels like “A cow chewing her cud”. (Courtesy: http://www.youtube.com for the video below).

To report this post you need to login first.

12 Comments

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

  1. Juan Reyes
    Hi Bala,

    It’s common to make assumptions based on previous installations/upgrades thats were experience play a huge role. It’s impossible to read every bit of documentation every time a project get started, specially when 90% is common material in between them. Spending time reading critical technical notes specific to the procedure is well worth it though.

    I found that using a sandbox (if available) prior engaging with the productive landscape in order to iron out issues and get yout timings right is well worth the time.

    Also always give yourself a reasonable buffer during the project plan to deal with any inconvinience that might show up.

    Regards
    Juan

    (0) 
    1. Bala Prabahar Post author
      Hi Tom,

      Yes. It is humanly impossible to read all. I don’t believe there is a simple solution to solve documentation challenges. SAP’s direction to make customers update the documentation doesn’t seem like a right approach. The documentation issues are very complex. May be I’ll write another blog.

      Best regards,
      Bala

      (0) 
      1. Tom Cenens
        Hello Bala

        I agree that giving the customer access to change help documentation isn’t enough. SAP employees should also help form the help documentation. There is so much data available that is not being used. Findings through the forum, customer messages and so on. If those would be combined in the help documentation it would already look totally different.

        I just recently went to a customer who was experiencing performance issues with SAP Netweaver CE using JPA. While SAP knew the solution to make the development perform better you will not find enough documentation on it in the help documentation.

        Kind regards

        Tom

        (0) 
  2. Vijay Vijayasankar
    As SAP learns more from its experiences of moving to the cloud and maintaining apps there, I hope they can use it to make life easier while on-premises apps need an upgrade.

    A good start for now will be for SAP to organize documentation in a way that does not necessiate someone to read a 1000 pages.

    (0) 
    1. Juan Reyes
      Hi Vijay,

      I would love to be able share your optimism but I have a feeling that new technology is going to be documented the same old way.

      Messy documentation is not a SAP invention, any technology that develops as quickly as SAP does tend to lack finesse on how it is put on paper, for example the other day I came across an OPatch that had been updated and renamed 5 times making it almost untraceable documentation wise.

      I think skills/experience will be playing a mayor role as it does these days.

      Regards
      Juan

      (0) 
      1. Bala Prabahar Post author
        Hi Juan,

        Messy documentation is something I can understand for the reason you stated. However what I don’t understand is log file stating “This is UNICODE SAPehpi!”. Not sure why the developer(s) chose to add UNICODE.  Their intention is questionable. SAPehpi or SAPup is just a wrapper program which in turn calls appropriate(UC or NUC) executables(R3load,R3trans etc) to upgrade the system.  UNICODE is unnecessary. The developer(s) actually could’ve added a line or two to help the customers and SAP Global Support: “This is SAPehpi. You can use this for either UNICODE or Non-Unicode System”.

        Interestingly we opened a message when we ran into an issue in QA system. We had already upgraded two other systems (Sandbox and Dev) using UNICODE SAPehpi. First thing SAP support asked us to do was to use SAPehpi NON-UNICODE version. They pointed out the difference between SAPehpi and other executables. We politely asked them to tell us where we can download non-unicode version from. Two days later they told us there was no non-unicode version of SAPehpi. Embarrassing.
        Another thing SAP could do is to organize S/W into 3 categories: Unicode, Non-Unicode and Code-Independent (they follow this scheme for Kernel). These recommendations are not as difficult as fixing the documentation.

        Regards,
        Bala

        (0) 
      2. Vijay Vijayasankar
        While nothing replaces skills and experience, I truly believe SAP owes it to customers and partners to do a better job on this. It will be an innovation that will truly be appreciated by every one connected to SAP.
        (0) 
        1. Bala Prabahar Post author
          Hi Vijay,

          One of the primary reasons for messy documentation is that SAP is not following development standards. Here is an example(I compiled this information after reviewing several pages of documentation from notes and manuals):

          1) If customer upgrades from product level X to level Z, they should use a tool called A (SAPup)
          2) If they upgrade from product level Y to level Z, then they should use a tool called B (SAPehpi).
          3) If they upgrade from product level Y to level Z for product SolMan, then use a tool called C (SAINT).
          4) If they upgrade from product level Y to level Z  for Java Stack, then use a tool called D (JSPM). Remember for dual stack, you can use option (2).

          Even after picking correct tool SAPehpi, both SAP Global Support and customers were confused regarding Unicode/NON-UNICODE version of SAPehpi.

          Regards,
          Bala

          (0) 
    2. Tom Cenens
      Hello Vijay

      I’m if not mistaken SAP now places documentation for new products on the wiki so community members can actually help write the documentation based on their findings.

      SAP Netweaver CE documentation for example is on https://cw.sdn.sap.com/cw/docs/DOC-103745 which can be edited.

      I believe Mark Yolton mentioned this in an interview at SAPPHIRE NOW.

      It doesn’t take away the fact that it would be best that SAP writes proper documentation but we all know not everyone is as strong in writing documentation as someone else. It can be a form of art on it’s own to create very nice documentation.

      But at least it is an interesting option that becomes available and it could help to improve the quality of the documentation.

      Kind regards

      Tom

      (0) 
  3. Kumud Singh
    Hi Bala,
    When I was inducted into first IT company, I was said never ASSUME as it means: it makes on ” *** of U and ME”.
    But gradually I have realized that given the scenarios of ever changing requirements,understandings, findings if we don’t assume one or two aspects, we will just be dilly dallying on the same object for much more time than actually needed.
    When I read the topic of the blog, I assumed it would end up saying don’t assume but it has ended on a positive note. But as always known,
    taking calculated risk is OK.

    With Regards,
    Kumud

    (0) 
    1. Bala Prabahar Post author
      Hi Kumud,
      Thanks for your comments. Interestingly your assumption turned out to be wrong after reading the blog.

      Best regards,
      Bala

      (0) 

Leave a Reply