Skip to Content
Paradox, redux

After reading Jason Mitchell’s recent blog and discussion “The Paradox of Choice”, I was quickly inspired to write a similar blog for the Systems types in the world (some think we’re probably related to Anakin and get our powers from the Dark Side, but that’s another story…).  That is, as much as there are so many available tools for a developer with SAP NetWeaver that choosing the “right” or “best” one becomes difficult by sheer availability, NetWeaver creates a similar paradox for your landscape with the possible combinations. 

What I am talking about is related to, but goes beyond the DB/OS combinations that can be found in the Product Availability Matrix (SAP Service Marketplace quicklink: /pam).  If you download the latest version Master Guide for SAP NetWeaver 04, you will find a whole section on Minimal System Landscapes.  And, BAM, on page 42 is a diagram of a Minimal System Landscape of Whole SAP NetWeaver ’04 (as of SR-1).  If you tilt your head to the left, you will see that you can install all of NetWeaver on a minimum of two Web AS systems – one for BW, EP, KW and MI and one for XI (XI is alone for technical reasons, but as of SP-12 this restriction has been lifted). 

To copy Jason’s line: how do you choose?

This “paradox” is only going to become more acute as we move more and more to ESA/SOA.  In fact, the whole concept of systems alone could become more blurry, but that, too, is another story.  Suffice to say that right now many, if not all, NetWeaver components can be combined in the same instance, and as we move on, the ability to combine systems can and will become even more prevalent.

Many will say that this is great; finally I can combine systems and get server consolidation.  There are also field colleagues of mine who would vehemently argue against EVER combining systems.  There are many pros and cons of combining and/or separating systems.  Here, I would like to kick off the discussion with a few of the pros and cons of my own. 

One Instance, Two or More?

Sizing. In terms of sizing, SAP recommends an additive sizing. For each component involved in the system stack, a separate sizing is required using the respective sizing procedure. The total size of a server that can accommodate all components is the sum of the individual sizing results. This applies to:

  • SAPS
  • Memory
  • Disk space

To find out if it’s cheaper to house everything in one box and in one instance as opposed to distributing the instances across multiple boxes, a thorough analysis with your hardware partner is necessary.  The relative size of each system is a factor.  It could be that it’s actually cheaper to have two smaller size boxes as opposed to one giant one (whose power could largely be sitting around idle a lot of the time).  Also, look at the option of server consolidation here.  For example, if you move your processes from the stand-alone ITS to the integrated ITS, what do you do with the server you have now freed up and how does that factor into your overall cost/decision?

Software Maintenance.  There are support package dependencies between application components and SAP NetWeaver.  Information on this can be found in the SAP Notes describing component-specific release restrictions.  This can have an effect when you have application components (like mySAP ERP) combined in a single instance with NetWeaver components.

Operating system and database patches must be released and supported for the instance and component they are applied to.  This can be a limiting factor in the consolidated scenario as you must wait for all components to support a patch before it is applied.  For example, if BI and ERP are installed in the same instance, and a database patch is released that fixes an issue in the BI system, the patch must also be supported by ERP before it may be applied.  This is less of an issue if they are separate instances.

Consolidated systems may have to be upgraded together.  If systems are in the same instance, then they will probably have to be upgraded at the same time (as there are no tools yet to un-combine systems, as well – this would be a project solution with each application having differing configuration and data).  This, obviously, has a huge impact on any upgrade project.

Third Party software and tools. Another factor to consider is the cost to purchase and maintain multiple copies of 3rd party software on multiple servers versus a lesser number of servers in consolidated systems. Of course this is obvious for tools that have server licenses. You should consider all manner of 3rd party tools such as OS/DB tools, monitoring tools, scheduling tools, back-up tools, high availability solutions, print solutions, etc

Administration.  Some factors to consider:

  • Backup/restore effort.  When systems are combined in a single instance, they are backed up together.  This is great from an ease of backup standpoint, but is a factor in any restore as both systems are restored together.  On one hand, you do ensure some sort of data consistency (think BI extracts), but you loose some flexibility: you can’t restore to a point in time in just one of the applications and not the other.  The same is true for system copies.
  • Scheduling and impact on system resources.  Running reports, batch jobs, extracts, etc. affects the resources for all the systems combined in the instance. 
  • RFC communication between systems in a single instance may be faster.  Consider your network design.
  • When the systems are combined into a single instance, there are fewer systems to monitor (with more complexity!).
  • Do you have a different application/system/instance/server configuration in production than development or Sandbox? The software logistics tools (i.e. transports) support this from an application perspective!
  • Experience of staff.  Are you and your administrators old, cranky, and long in the tooth when it comes to SAP?  Or did they just find out that Walldorf is in Germany?  This can have a huge impact on the success of combining systems as it is definitely not for the faint of heart.  Also consider company politics (very often overlooked, but a critical success factor).  Combining systems may mean combining groups within the company that previously did not work together.  There will be a power struggle (trust me, I speak from field experience here…).

This is still all quite new; i.e. with the ability to have co-existence of NetWeaver functionalities and applications in one instance.  So much so that SAP is still collecting field experience.  Please write me at if you are considering such a landscape as we are still busy releasing the appropriate SAP Notes to gather feedback and request help from SAP.

A good thing or bad thing?  Like I said, these factors are for discussion; your factors may be different.  And therein lays the paradox again…

To report this post you need to login first.


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

  1. Community User
    Hi Matt,

    Thanks for a nice and elaborate blog. Certainly adds to my knowledge on factors to keep in mind while designing landscapes. It would be great if you could outline the factors that you would consider, pros and cons, when you propose customers on central vs distributed landscapes for core ERP systems. When, in your opinion, should an organization opt for either and what factors to consider?


    1. Matt Kangas Post author
      Hi Shehryar,

      A very good idea.  Perhaps I can make that my next blog subject…

      Readers, any ideas to kick of the discussion?

      Best Regards,

  2. Bernd Eckenfels
    Hello Matt,

    XI and Web Applications make this world even more complicated. For example distributed J2EE Engines for the Adapter Framework for Security Reasons, like I had described in my article:

    Security Considerations for ISDN Communication with XI

    I guess HTTP Load Balancing (XI, Portal) also introduce more complexity.

    Personally I think it is good that SAP can grow in all directions, I sometimes just find it confusing that the product management is trying to blurr the borders between ABAP and JAVA parts. Maybe this impression is wrong, but for sure it confused me some time before I understood about the relationships.


    1. Matt Kangas Post author
      Hi Bernd,

      You say “I sometimes just find it confusing that the product management is trying to blurr the borders between ABAP and JAVA parts”…

      Please explain exactly what you mean.  As a Product Manager part of my job is to make things less confusing, not more.  If our constituents are geting confused, then we need to be doing a better job with our messages.  What is confusing and why? 

      Thanks for your input…it will help us get better information out in the future…

      Best Regards,

  3. Mike Niven
    We just completed an upgrade from 4.6C to ERP 6.0 and now we have been asked to start looking at expanding the environment. Many people have thought that since many of the functions are included in the standard NetWeaver 7.0 platform, we can do this without adding hardware. Of course this might or might not make sense depending upon how many users, how much functionality is added, and how it is going to be used. As a hardware landscape architect it certainly is going to make deciding how many new systems are required an interesting decision. Any suggestions would be helpful. Also, if I learn anything I will certainly post them here.
    1. Matt Kangas Post author
      Hi Mike,

      Sorry for the delay…I was on vacation when you posted this…

      This is an interesting question, but one does not necessarily save on hardware…see what I said above about sizing:

      Sizing. In terms of sizing, SAP recommends an additive sizing. For each component involved in the system stack, a separate sizing is required using the respective sizing procedure. The total size of a server that can accommodate all components is the sum of the individual sizing results. This applies to:

      Disk space

      So, the question in my mind would be, is it cheaper to have one large server, several smaller ones, or something in between?  You should also think about administration of the servers here, too (one or many).  In a nutshell, further analysis required as each installation is unique…

      Best Regards,

  4. Mike Niven
    Matt, thanks for the reply to my original posting. What I see also as a major concern is the double or dual stack question. As part of our purely technical upgrade of our 4.6C to ERP 6.0 and UNICODE, we decided to not install the Java stack. One less thing to worry about. Now that we want to expand the usage and add new functionality, the question becomes do we go back and install the Java stack or do we just have an additional server add keep the two seperate? I know this is probablye one of those “it depends” questions. If you read the article in the last SAPinsider Magazine from Dr. Franz-Josef Fritz, he does state that it can work both ways. I do like the basic design principles that he states in the article about looking at the speed of evolution for each module.
  5. Mike Niven
    Well in between my last post and everything else that has been going on, we have implemented a BI environment and 2 months ago CRM 7.0. What this has done to the environment has basically linked all of the systems at the hip so that system refreshes and system upgrades need to be considered across the landscape. This has caused an explosion in the complexity of the environment and made landscape planning more difficult. This would be a great place to discuss items such as 3 versus 5 system landscapes and the pros and cons of each. Can anyone share their experiences or raise additional questions?



Leave a Reply