System Landscape Governance @ TechEd 2010

Dirk Anthony — Fri, 17 Sep 2010 09:20:43 GMT

Concerned about increasing landscape complexity ?
Facing challenges when implementing new innovation within you SAP Business Suite system landscape ?
Uncertain about version dependencies when updating parts of your system landscape ?

If your answer to one of the questions is ‘ yes’, TechEd session ALM109 (Berlin, Las Vegas) might be able to dispel some of your doubts. Just have a look, how system landscape governance by SAP will ease the use of SAP products.

The session outlines SAP's approach and current offerings to reduce complexity in system landscapes covering multiple SAP applications. Learn how SAP is tackling the most important challenges customers face when designing and managing their system landscapes. Understand how landscape governance will help to standardize and automate the management of your system landscape. Furthermore we will provide an update of the SAP System Landscape Governance Board, covering the newest deployment recommendations, how to design system landscapes for certain SAP products.

How to Deploy SAP NetWeaver - Guidance for better System Landscape Designs

Dirk Anthony — Thu, 19 Mar 2009 03:06:24 GMT

Introduction:

SAP NetWeaver supports a high level of flexibility, how to deploy main SAP NetWeaver capabilities within a system landscape. In the past SAP mainly just described the variability of those different deployment options, sometimes at least SAP provided some information about the pros and cons of each option.

What customers so far are missing, is a clear guidance, what might be the best landscape layout for most of typical use cases.

However, what is the best landscape layout ?

Of course this question can not be answered by a simple statement. There are lots of different aspects to be considered like

the organizational setup of a company
the architectural strategy of a customer
the need for governance processes
the expected speed of innovation for used applications
specific security requirements
individual performance & scalability requirements
the needed availability and service level agreements
operational costs
etc.

One specific landscape layout might be the best one for a customer, whereas another customer would prefer a different setup. Nevertheless it should be possible to reduce the high number of technical possible combinations of different landscape setups to a set of alternatives, that fit well to most of the typical use cases.

How can SAP help to find the best landscape layout ?

In my opinion you can not optimize all aspects that have an impact on landscape designs by exactly one landscape layout. All these aspects might be assessed differently by different customers. So it is not about optimizing a landscape layout due to a few aspects, while completely neglecting some others. SAP will not be able to recommend exactly one landscape setup that is the best choice for all customers, and which is optimized for all important aspects.

But SAP should be able to recommend landscape setups, that

are the best trade-off between the most important design aspects,
find the right balance between the antagonists flexibility and simplicity,
are accepted by the majority of the customer base,
fit to SAP’s product strategy and
should not have to be changed every 6 months.

And now I want to explain, how we are going to achieve this (at least we are working on it).

The approach:

From my perspective 3 main factors are essential for having success with such a new approach:

Ease of understanding:
The recommendations should be quickly to consume and easily to find. Providing a first and comprehensive overview is the goal rather than providing a 100 pages document which can only be consumed by the individual topic experts. The information should be published at one central place, instead of distributing it in pieces across different topic areas within SDN.
General adaptability to SAP products (not limited to some specific capabilities):
A common methodology, how to describe recommendations for different SAP products or different building blocks within the products is key. The same methodology should be applicable for the main architectural building blocks like e.g. SAP NetWeaver Portal, SAP NetWeaver Process Integration or SAP ERP ECC Server. Even for smaller units like Adobe Document Services or System Landscape Directory the methodology should work, if these units are relevant for the landscape design.
Consistency:
Guidance requires a certain level of consistency and continuing significance. Recommendations should not be changed every 6 months from one direction to the complete opposite, and they should be consistently aligned within SAP. When changes occur – and of course this can happen – they should be made transparent as soon as possible in order for customers to react on them.

We tried to consider all three factors when developing the following approach:

We created a framework that clearly shows a “rating” of different deployment options by dividing them into three main categories:
- general recommendation,
- reasonable alternative,
- possible exception

The same framework is applied to those building blocks of SAP products, which are the major entities within a landscape design (e.g. Business Warehouse, Application Portal, or Enterprise Services Repository).
Shall those building blocks be implemented centrally or locally in the system landscape ?
Shall they be deployed together with other building blocks in the same technical system or better deployed in a separate system ?
The recommendations based on the framework will help to answer these questions.

In the first phase we will focus on building blocks of SAP NetWeaver 7.0 and 7.1 as part of SAP Business Suite 7 solution landscapes.
Starting mid of 2008 with introducing the framework and providing some first generic recommendations regarding the usage of dual stack systems and SAP NetWeaver for the SAP Business Suite, we now published in addition to this recommendations, how to deploy SAP NetWeaver Portal, Adobe Document Services, SAP NetWeaver Business Warehouse and BEx Web, SAP NetWeaver Process Integration, System Landscape Directory, and Enterprise Services Repository & Services Registry within a system landscape.

All these recommendations are published in the same easy-to-consume format and are using the same kind of categorizations. They are providing a quick overview and are published at one central place within SDN:
http://www.sdn.sap.com/irj/sdn/landscapedesign section Distribution Models

To achieve consistency, we do not just focus on the state of the current available release, but also take SAP’s product strategy for the upcoming releases into account based on the 3 year product roadmaps. Furthermore all recommendations are aligned within SAP across different areas and are approved by the SAP System Landscape Governance Board, a new unit within SAP, that focuses on system landscape related topics and drives landscape governance within SAP across our products.

Example:

To make it more concrete, let us have a short look at an example of the recently published recommendations. So let us talk about deployment recommendations for the SAP NetWeaver Portal. You can find all the details at the link mentioned above.

Especially for portal capabilities it is a very valid architectural question to decide, if you want to setup one central portal, shared by multiple different application backend systems, or if you rather prefer to setup multiple local portal systems, each portal serving one dedicated backend system, and all portal systems somehow connected (federated) with each other.
Another important question is, if the portal capabilities (or to phrase it in other terms, the SAP NetWeaver usage types EP or EP-Core) should be deployed as a separate technical system (SID) or combined together with the application backend system, meaning installed within the SAP Business Suite system (e.g. same SID like the ECC server of an ERP system).

In the past – without any strict guidance – all these variants were technical possible and could be installed. Resulting to the situation that we noticed a high uncertainty at customer side to determine the right setup.

Everything was possible, but does everything also lead to the right setup ?

How can a customer be sure that the chosen portal landscape layout is still aligned with SAP’s strategy two or three years later ?

With the new approach, we now clearly state to avoid any joint deployment of the portal with the SAP Business Suite backend system in the same technical system (same SID). Based on the framework our general recommendation is to target one central application portal as a separate technical system, which can be shared by multiple different SAP Business Suite backend systems to provide e.g. a central role-based and personalized access. In addition you can check whether to deploy WebDynpro Java-based application UIs on that central portal infrastructure, to avoid the setup of further additional local portal systems, which would have to be integrated into the central one.

For certain use cases it might make sense for customers to setup an additional local portal, e.g. customers who want to have a dedicated HR portal, providing the infrastructure for Employee Self Services, and directly connected to one HCM backend system. Such landscape layouts are of course still possible and supported and are rated as a reasonable alternative. It has to be decided by a case by case evaluation, if this setup makes sense for a customer.

So the general idea is to start with the central portal approach and then decide, if an additional local portal for certain applications or Web Dynpro Java-UIs would make sense to achieve a higher independency from the central portal infrastructure.

Let me conclude this example with a short comment on federation scenarios within a multiple portal landscape.

To be honest, SAP’s strategy within that area have been adapted during the last years. We learned from customers that going for a strategy which lead to landscapes of multiple different portal systems, which have to share data and which require complex federation scenarios, do not lead to the best-trade off between flexibility and administration costs. As a consequence we adapted our strategy and based on the new approach of providing better guidance, we are also going to make this change visible immediately. So our current solution (Federated Portal Network – FPN) is still supported and might make sense for very specific use cases. However, we rate it as a possible exception, to make a clear point that we do not recommend to use FPN as the typical default setup within a portal landscape.

By using a central portal approach, other applications and UIs should be integrated via application integration (further details can be found in the portal related sections within SDN).

This example demonstrates that even when strategy changes occur – which of course can happen in order to reflect customer feedback or changed or new market trends - SAP is now providing more transparency for customers to get aware of the new situation as soon as possible.

Since changes for the deployment strategy often also have an impact on the product applications that are dependent on the landscape layout, not all already available & shipped applications might be able to make use of the new recommendations. So they will stick to the new recommendations for future releases, but might have some restrictions for the current available release (which was developed on the former strategy).

On the other hand we do not want to provide only deployment recommendations for upcoming new releases, letting customers run into a wrong direction, when planning their system landscapes for the current available release.

To solve that dilemma, we decided to publish recommendations, starting with the highest current available product version/release (which will be indicated within the individual presentations) to provide guidance as fast as possible and to show the direction SAP is moving to. For most of the use cases the recommendations fit well. Nevertheless – especially if some strategy changes have occurred – this can not be a guarantee for every individual application and possible restrictions have to be checked. The recommendations will make you aware of this as far as possible (e.g. when deploying WebDynpro-Java UIs in the central application portal, the version interoperability of the individual application has to be checked. Starting with SAP NetWeaver 7.0 SPS 13 major improvements have been achieved, so applications like e.g. Employee Self Services only require SPS 13 as a minimum SP stack in the portal system and the clear goal is that any update of the ESS application will not force further SP stack or EhP updates of the SAP NetWeaver Portal runtime. Details can be found in the SAP Notes for these applications).

Summary:

Let me shortly summarize this blog by emphasizing the most important facts:

SAP is going to provide a stronger guidance for landscape planning by publishing clear recommendations, how to deploy SAP NetWeaver within a system landscape.
The recommendations reflect the best trade-off between simplicity and flexibility and consider SAP’s mid-term product strategy.
All recommendations are based on a common framework and are approved by SAP’s System Landscape Governance Board to assure consistency across different SAP products.