Motivation and Goals
Missing guidance and lack of clear recommendations about optimal landscape setups for SAP products belong to the prominent challenges often addressed by customers in the past.
What is the best trade-off between flexibility and simplicity as outlined in this Wiki before ?
How could individual optimization and general standardization be combined ?
It is not that easy to come up with a quick answer, but we developed a way out. Based on a common methodology that could be applied to any kind of SAP product, we are able to provide guidance on typical architectural decisions that have to be taken by customers, when planning and designing a system landscape.
Taking SAP NetWeaver components as an example, the following architectural decisions need to be taken:
1. Decision: Centrally shared vs. local redundant use of components
Providing a certain set of SAP NetWeaver capabilities centrally and shared by multiple application systems is a typical pattern that is seen in system landscapes. The following advantages are related to this strategy:
- Achieve cost reduction by sharing the set of capabilities
- Drive standardization and consolidation by deploying the capabilities centrally rather than locally in multiple application systems
- Combine innovation and stability by providing new or updated functionality centrally that might or might not to be consumed by the multiple local application systems
2. Decision: Jointly vs. separately deployed components
Does it make sense to deploy different components within the same technical system (e.g. SAP NetWeaver Portal and Adobe Document Services) or shall they better be deployed separately (like SAP NetWeaver Business Warehouse and SAP NetWevaer Process Integration).
3. Decision: Integrated vs. separated technology stacks
If a certain application or component requires different technology stacks, it must be decided if those stacks shall be closely or loosely coupled. For ABAP and JAVA stacks we offered in the past the flexibility to decide for all components, if single stacks or the so called dual stack shall be installed. This complete flexibility did not led to the best trade-off, since the originally expected simplicity did not showed up and this setup could not be rated as beneficial for most use cases. As a consequence SAP removed the dual stack as a useful deployment option for their product components. Hence we already recommended since years to avoid new dual stack setups where possible.