The Paradox of Choice for the Sys Admin…
After reading Jason Mitchells 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 were probably related to Anakin and get our powers from the Dark Side, but thats 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 Jasons 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:
- Disk space
To find out if its 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 its 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 cant 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 firstname.lastname@example.org 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