SAP Solution Manager 7.2 - Solution Landscape Design

0. General Information

The picture above shows the fundamental change of the system landscape design in SAP Solution Manager 7.2 compared to SAP Solution Manager 7.1.

In 7.1, the system landscape was modeled in logical components - with one production system per logical component. Then the logical components were used in projects and solutions. We recommended to reuse logical components. But for several reasons, customers create multiple logical components for the same landscape (logical components with the same colour represent this situation) - some logical components contain only parts of the landscape because the customer just would like to have an EWA in a solution.

Projects are created for defining business processes building up the process documentation, other projects are created for Change Request Management to get a system landscape for the task list.

At the end, the customer has many projects which he does not use anymore and also solutions - also many customers have redundant logical components.

1. Solution

1.1 Definition

A solution houses all systems, processes, and Solution Documentation in a customer's business. Technically, a solution is the root of a structure that contains all of those objects.

The granularity of solutions is much coarser in 7.2 than it was in 7.1, because solution size and performance limitations and authorization issues which sometimes forced users to artificially split solutions into smaller chunks in 7.1, no longer apply.

From a process perspective, a solution covers all the company’s business processes.

From a system perspective, a solution covers all productive systems that are connected through interfaces.

As solutions are relatively closed entities, with limited access to functionality outside of themselves, there is typically only one productive solution per company. Even for an international, multi-site company, one solution will generally be sufficient in 7.2.

1.2 Question

Q: Which criterias exist creating several solutions

A: 1. In case SAP Solution Manager manages several system landscapes which do not interact. E.g several customer are handled in SAP Solution Manager so you can create for each customer a solution. Serivice provider are typical customer who need multiple solutions.

2. In case you act as a software vendor, you create a template in solution A and offer it with the export functionality to your consumers who can import it in there solution B,

2. Branch

2.1 Defintion

Branches can be understood as 'version contexts' of a solution. The currently productive solution is documented in the production branch. If you run a development environment in which you are setting up a new product version (which will become set productive in the future), possibly including your own custom developments, you would represent this by a development branch for the systems in the development track. Typical maintenance activities such as implementation of SAP Notes would normally be handled in a separate maintenance branch, not in a development branch. By default a newly created 7.2 solution has a production and a maintenance branch.

Branches are part of every solution and are located as subnodes below a solution.

A solution can have different types of branches but must have the production branch at least. The structure of a newly created solution looks as follows:

production branch (obligatory – will be created automatically during solution creation)
maintenance branch (optional – will be created automatically during solution creation)
other branches (optional), for example operations branch. For the use of an operations branch see below.

The production branch is obligatory and can not be deleted. The maintenance branch can only be a child of the production branch and exists only once in a solution. It also must not have child branches. A branch contains the following properties: name, technical name, change control (not available on the production branch), sites on (not available on the production branch).

The development branch represents an independent version context where you can realize long term changes which are independent from short term changes in the maintenance branch.

As a production branch is the upmost node in the structure of branches, no information about the parent branch is available. The Change Control Management integration provides a close integration between Solution Documentation and Change Request Management (ChaRM). When the Change Management integration is enabled, you have to use always Change Documents for every change in the Solution Documentation content. This integration can be activated per changeable branch. If the Change Management Integration is disabled, you can change the Solution Documentation without control by change documents.

If you activate change control you are only able to maintain the branch content by selecting an existing change document where the changes are tracked. If you enable sites, you are able to separate your system landscape by different locations. The site setting is visible as soon as sites are enabled for the solution (properties tab).

We recommend to use a production branch for all activities concerning production, a maintenance branch for maintenance activities and a development branch for development activities. Maintenance and development branch are independent versions for changes of the solution. The production branch is the productive version of the Solution Documentation, where all productive content is stored. If you need to enhance or to change the Solution Documentation, you have to use create a new branch as a new version of the Solution Documentation.

2.2 Question

3. Logical Component Group

3.1 Definition

Logical component groups are uniquely defined for each solution. It is not possible to assign a logical component group to several solutions. The unique identifier for a logical component group is the logical component group name. The name is unique for the whole system. This name cannot be changed after the creation of a logical component group.

As a rule of thumb, a logical component group encapsulates all systems of a solution that have the same productive system and system type e.g. ABAP or Java, so you create a separate logical component group for each ABAP-based and each non-ABAP based installed system landscape. For example, a solution could contain the logical component groups HR, ERP, CRM, BI, PI, BOBJ, PORTAL.

This rule means e.g. that landscapes with multiple productive ERP systems have to use only one ERP logical component group. Reasons for multiple productive systems can be systems for several regions or plants.

Technically, logical component groups are created within solutions and house the sum of systems that are needed for the operation of a system installation.

The following examples show the possible composition of logical component groups supporting typical system landscapes.

One productive system, one logical component group:

development - test - production
development - several test systems - production
several development systems (e.g. for workbench customizing) - several test systems - production
several development systems (e.g. for current maintenance and next release) - several test systems - production

Multiple productive systems, one logical component group:

several development systems (e.g. for current maintenance and next release) - several test systems - several productive systems (e.g. one productive system for each region). Do not create separate logical component groups for organizational sites e.g. for different countries or plants, but use the site concept which has been created for that purpose.

Multiple productive systems, multiple logical component groups:

Two different landscapes that are based on the same SAP product, e.g. one HR landscape on SAP ERP 6.0 EHP7 and one logistics landscape also on SAP ERP 6.0 EHP7; as on these two landscapes, there are different processes with different productive systems, you need two different logical component groups.

3.2 Question

A: How to model such a landscape

A: We have a landscape with three different installations --> three logical component groups (for each colour one LCG)

Because of dual landscapes (development and maintenance) a development and maintenance branch is required + production branch

The blue LCG is site enabled (site 1 = ERP site2 = FTA)

Development branch requires three system roles - Devleopment (DEV) Test (TST) Regression Test (REG)

Maintenance branch can reuse system roles - Development (DEV) Test (TST)

Production branch - Prodution (PRD)

ChaRM specific system roles are not required in 7.2 -

Result:

4. Site

4.1 Definition

The site concept is relevant for companies that run one SAP product on separate productive systems, e.g. in different branch offices, countries or regions and where those productive systems have a lot in common regarding software logistics and Solution Documentation but are also used to support local features. In a solution, sites can be used to separate the system landscape by different locations.

For each site, productive systems may be supplied through local maintenance and development systems while they can also be connected to a common development system that handles software that is uniform across all locations. Similarly, for Solution Documentation, parts of the documentation can be the same across all sites, supplemented by special documentation written for individual sites.

Technically, the site attribute selects during navigation within the application the relevant managed systems based on logical component group, site and system role where the site determines the appropriate logical component within a logical component group and the system role picks the right logical system. Furthermore, each Solution Documentation element can be linked to one or more site attributes in order to restrict their validity to those sites. An empty attribute value stands for documentation that is universally valid across all productive systems in a logical component group and is called “global”.

Up to SAP Solution Manager 7.2 SP02 a logical component group could only contain a sole productive system, even when business operations on different sites would have suggested the use of several productive systems. Additional productive systems within a logical component group could up to SP02 only be modeled artificially through additional system roles created for that purpose.

Page tree