Hi Daisuke
From your last comment it looks like it's still not clear for you how these elements are related to eachother. So I'll give it a go to try and explain.
It's a bit complicated if you have to look at this without going back to the basics I would think.
Let's go back to the basics of SAP Solution Manager 7.2 as this concept was new to the product.
To start, let's only consider the maintenance and the production branch to explain the principals first. Let's also leave out Focused Build for the time being. I'll come back to other branches afterwards and also Focused Build.
Let's start from a four system landscape - DEV - QAS - PRE - PRD then from a technical point of view, the DEV (development), QAS (quality assurance) and PRE (pre-production) system would belong to the maintenance branch. Meaning, the processes running there are not considered to be productive, those systems are used for maintaining the production environment. Prepping changes and testing changes so they can end up in production in the end. The DEV, QAS and PRE systems can contain processes that are different from the production environment - you can say the "to-be" processes state.
The PRD system belongs to the production branch. That is where your company runs their processes on, productively. The "as-is" processes state.
When we look at solution documentation, the above is what the branches are used for. The maintenance branch gives you the opportunity to remodel processes according to the "to-be" processes state. You adapt your process model according to the developments/tests done on the maintenance systems (DEV, QAS and PRE) which in the end have to go to production (PRD).
When we look at Change Management (CHARM) they are also using these branches. For one, to know when to move the changes in the solution documentation from the maintenance branch to the production branch (upon import into production) but also from a technical point of view. The systems that are assigned to these branches, is what the change management processes will "see" in terms of the potential landscapes against which it can be configured. It is a prerequisite to have the systems assigned to the right branch (via transaction SOLADM). SAP Solution Manager reads those branches out and when you would create a cycle in CHARM, it then checks the technical prerequisites such as transport routes from DEV to QAS to PRE to PRD and RFC destinations defined in SAP Solution Manager.
If you only have a maintenance and a production branch in a SAP Solution Manager system and you would define a new "release", you would only get the option to create it against the maintenance branch because you start developments in non-productive SAP systems. The creation will then check the assignment of systems against the branches and show you the available options/systems for which you can generate a cycle given the technical prerequisites are met. So even if you would not use Solution Documentation (outside of Focused Build scenario) as part of Change Management, you would still need to maintain the branches and system assignments to be able to use Change Management.
I hope that is clear so far.
Additional branches then, the development branch (still not considering Focused Build):
An additional branch that can exist is the development branch. This is usually (or normally) used in situations where a customer has a so called "dual landscape".
So you have the systems we used earlier: DEV- QAS- PRE (maintenance branch) and PRD (production branch) and now we are going to assume the customer wants to do new very large implementation projects on this landscape - introducing lots of changes.
For this purpose customers sometimes (mainly large customers) build up a second system landscape in parallel (a copy of the previously used landscape).
Lets call these systems VED - SAQ - ERP. The number of systems can vary here but the principal is that on these systems where we consider VED as development, SAQ as quality assurance and ERP as pre-production, we want to implement our large projects and those developments/configuration has to end up in the landscape of DEV - QAS - PRE - PRD.
So these systems VED - SAQ - ERP can have a different "state" compared to DEV - QAS - PRE in terms of business processes.
This is why we call this branch the "development branch" and why those new systems would be assigned to this branch.
Other branches:
You see in the screenshots in previous comments and perhaps your own system that other branches can exist. These each have their own purpose. You can create additional branches for specific use-cases. For business process monitoring for example, an operations branch can be created to which the productive system is assigned.
Branches can be branched off a parent branch so you have a hierarchical relationship in essence.
You can have an import branch in which you import best practice content from SAP - it contains a structure of folders / scenarios / processes from which you might want to copy content into your own branch afterwards.
The design branch can be used for example to copy content from the import branch and to play around with in a sandbox.
The idea is always the same - you define a branch because of the different "reality" of the processes in a given system or system landscape.
Focused Build
Now, when we come back to Focused Build, it is important to know that is was initially build to support S/4 HANA implementation projects. Thus it was designed/created to do large implementation projects and not to perform maintenance. In the meantime it has become possible to use Focused Build for maintenance but that's not what it was initially designed for.
If you now look at the picture that Dolores shares on the branches used in Focused Build you will see that Focused Build scenario is using the development branch because of the above reason (it's an implementation project, you are not doing maintenance).
The fact that both exist in your system - the maintenance and development branch can be confusing when you look at documentation that discussed this branch in relation to CHARM. The maintenance and production branch are existing by default in any given SAP Solution Manager 7.2 system.
So what Focused Build looks at in terms of branches is the import - design - development and production branch. Again, behind it, it is important to have the right systems assigned to those branches for the technical link to those systems (Transport Management System, RFC destinations etc) to enable Focused Build to create transport requests and move transport requests to the right systems.
The proposed system landscape by SAP for Focused Build is a sandbox system for the import/design branch (sandbox is assigned to both import and design branch), a development branch which contains DEV - QAS - PRE and a production branch which contains PRD.
The maintenance branch isn't really used if you are only using Focused Build for your S/4 HANA implementation project.
In your screenshot of the branches you can see that the maintenance and development branch have different "systems" (in form of system / client) assigned to them to simulate a dual landscape which I explained earlier. This typically exists when an initial implementation project is done and you want to start new, large implementation proejcts against the existing landscape and thus you want to have a separate landscape for implementation projects versus doing maintenance.
cusersi020554desktopbranches.png(74.0
kB)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.