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.
SAP products like SAP Business Suite or SAP NetWeaver support a high level of flexibility for different deployment options with respect to the mentioned architectural decisions. However, the optimal landscape layout is mostly a trade-off between flexibility and simplicity as pointed out before. Dependent on the specific situation and the kind of capabilities that should be deployed, we are going to provide clear recommendations, how to deploy certain SAP products or major product components within your solution landscape.
Categorization of deployment options will provide a quick and easy overview of typical landscape setups, based on main customer needs, in line with SAP's product strategy and considering the targeted guiding principles of the reference landscape. The definition and usage of a consistent methodology for deployment recommendations helps to provide a comprehensive overview across different SAP products.
Here you will find a lot of more details about the approach.
Available system landscape deployment recommendations
Further recommendations based on this methodology and approved by the SAP System Landscape Governance Board will be provided on a case by case decision, when requested by the SAP product owner of the individual SAP product. Upcoming new recommendations will be announced and published here.