{"id":34386,"date":"2023-09-08T08:53:34","date_gmt":"2023-09-08T06:53:34","guid":{"rendered":"https:\/\/www.blue.works\/alm-coffee-party-v-dual-landscape-part-3\/"},"modified":"2026-02-17T13:19:12","modified_gmt":"2026-02-17T12:19:12","slug":"alm-coffee-party-v-dual-landscape-part-3","status":"publish","type":"post","link":"https:\/\/www.blue.works\/en\/alm-coffee-party-v-dual-landscape-part-3\/","title":{"rendered":"ALM Coffee Party V – Dual Landscape Part 3"},"content":{"rendered":"\n

Two landscapes for one productive system<\/h2>\n\n\n\n

As recommended by the FB methodology, the project-driven changes unfold along a 4-system project landscape that includes an additional pre-production system.<\/p>\n\n\n\n

\"\"
Figure 1 Two system landscape – cutover scenario 1<\/figcaption><\/figure>\n\n\n\n

There are various scenarios for the cutover (go-live) of a release from the project landscape to the shared production system, see the list in the FB Configuration Guide, chapter “Cutover Checks and Post Cutover Activities: Configuration – Overview”.<\/p>\n\n\n\n

We opt for “Scenario 1”, as it is called in the FB Configuration Guide, because it fits better with our proposal for the coexistence of major and minor releases.<\/p>\n\n\n\n

Projects<\/h3>\n\n\n\n

One of the major advantages of the turnkey solution Focused Build<\/a> is the fixed structure of the projects with their phases and the predefined quality gates. FB follows the agile project paradigm and organizes the work in the decisive implementation phase in waves<\/em> and sprints<\/em>. If you prefer waterfall projects, simply create only one wave and one sprint per project.<\/p>\n\n\n\n

\"\"
Figure 2 Example of a quarterly project<\/figcaption><\/figure>\n\n\n\n

Pre-Production System<\/h3>\n\n\n\n

The pre-production system is not a second QA system. Its advantage is obvious: the integration and regression tests that take place there are not invalidated by constant new imports. This is because every change forces the tests to be repeated: a new side effect could have crept in as a result of the change.<\/p>\n\n\n\n

In the test phase on the pre-production system, only corrections to errors discovered during testing are permitted. Focused Build offers the specialized “Defect Correction” process type for this purpose.<\/p>\n\n\n\n

Development can continue during the freeze<\/em> of the pre-production system, but it is done for the next release or the next phase cycle.<\/p>\n\n\n\n

In the pre-production system, everything and only that which will actually go live in the next go-live is tested extensively and intensively.<\/p>\n\n\n\n

\"\"
Figure 3 Testing in a 4-system landscape<\/figcaption><\/figure>\n\n\n\n

Maintenance<\/h3>\n\n\n\n

As the FB methodology expects a project plan with many Q-gates, I recommend using the classic ChaRM change documents<\/em> for transports within the maintenance landscape. As long as only corrections and minor adjustments are made to existing processes, three systems should be sufficient in the maintenance landscape.<\/p>\n\n\n\n

With active FB, the use of Request for Changes or IT Requirements is unfortunately not supported in the standard for minor release cycles (FB SP10). If you need the RfC for an approval workflow in the maintenance landscape, you must create “normal” phase cycles instead of minor release cycles1<\/sup>.<\/p>\n\n\n\n

From the lab<\/h2>\n\n\n\n

The dual system landscape with major and minor releases is outlined here on a Solution Manager sandbox system.<\/p>\n\n\n\n

For the sake of brevity, I assume that you are familiar with the SAP documentation for the tools used and the FB-specific IMG.<\/p>\n\n\n\n

The two system landscapes<\/h3>\n\n\n\n

Maintenance landscape<\/h4>\n\n\n\n
\"\"
Figure 4 Maintenance landscape, with the project development system as the retrofit target<\/figcaption><\/figure>\n\n\n\n

Project landscape<\/h4>\n\n\n\n
\"\"
Figure 5 Project landscape<\/figcaption><\/figure>\n\n\n\n
\"\"
Figure 6 Logical component group BL_SOLMAN_LCG with development and maintenance branches<\/figcaption><\/figure>\n\n\n\n

Change Control Landscape<\/h3>\n\n\n\n

We give our demo its own Change Control Landscape (CCL), because release management is based on this. A CCL can only have one release.<\/p>\n\n\n\n

\"\"
Figure 7 Change Control Landscape<\/figcaption><\/figure>\n\n\n\n

Since we want to operate the project landscape with FB, we have to configure the new CCL in Customizing (see below), and when starting the CRM WebUI we have to select the business role “\/SALM\/RLSMNG – Release Manager”.<\/p>\n\n\n\n

\"\"
Figure 8 Release Management Configuration – Task Type<\/figcaption><\/figure>\n\n\n\n
\"\"
Figure 9 and the mapping<\/figcaption><\/figure>\n\n\n\n

Major Releases<\/h3>\n\n\n\n

We go into release planning and plan a whole year in advance. It is more convenient to create only the major releases first, and the minor releases for the major releases afterwards.<\/p>\n\n\n\n

As the minor releases are only possible after the go-live of the previous major release (there is no release 0), we simply set the initial release to the next best date in our demo. If you are already using standard ChaRM, you can dispense with this small start-up aid by operating the maintenance landscape with ChaRM as before until the go-live of Release 1.0 (sounds ChaRMant<\/em>, doesn’t it?).<\/p>\n\n\n\n

The big Project Go-Lives are usually held at the weekend.<\/p>\n\n\n\n

\"\"
Figure 10 Creation of quarterly releases for one year<\/figcaption><\/figure>\n\n\n\n
\"\"
Figure 11 Initial planning, manual adjustment of go-live dates at the beginning of the quarter<\/figcaption><\/figure>\n\n\n\n

We are now adding a release cycle.<\/p>\n\n\n\n

\"\"
Figure 12 Release 1.0 with cycle<\/figcaption><\/figure>\n\n\n\n

The very first time, the task plan for the project landscape is created. All further cycles will share this task list.<\/p>\n\n\n\n

\"\"
Figure 13 The new project task list<\/figcaption><\/figure>\n\n\n\n

Minor Releases<\/h3>\n\n\n\n

Now we mark the release 1.0 and add 14-day minor releases for the maintenance landscape. We choose Thursday for the go-live day. This means that you still have Friday available for any necessary corrections in the event of go-live problems.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Figure 14 A package of minor releases<\/p>\n\n\n\n

We adjust the dates manually. Release 1.6 unfortunately has to be added in a second step, as the application is simply too intelligent when calculating the dates and refuses to create 6 minor releases in one go in one quarter.<\/p>\n\n\n\n

\"\"
Figure 15 Six 14-day minor releases<\/figcaption><\/figure>\n\n\n\n

And this is the task plan for the maintenance landscape:<\/p>\n\n\n\n

\"\"
Figure 16 Maintenance task list<\/figcaption><\/figure>\n\n\n\n

Customizing phase model<\/h3>\n\n\n\n

In order to be able to create Request for Change for the minor releases of the maintenance landscape when the FB is active, the following entries must be added via the view cluster \/TMWFLOW\/VC_PHMD:<\/p>\n\n\n\n

\"\"
Figure 17 Customizing phase model<\/figcaption><\/figure>\n\n\n\n

If you don’t want to miss the next part, you can read it here<\/a>.<\/p>\n\n\n\n

\n\n\n
  1. \u21a9\ufe0e<\/a><\/li><\/ol>","protected":false},"excerpt":{"rendered":"

    As recommended by the FB methodology, the project-driven changes unfold along a 4-system project landscape that includes an additional pre-production system.<\/p>\n","protected":false},"author":16,"featured_media":33579,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"[{\"id\":\"4112bc35-c7b8-4669-bbc3-ce25788b5517\",\"content\":\"\"}]"},"categories":[351],"tags":[352],"class_list":["post-34386","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alm-coffee-party-the-alm-magazine","tag-coffee-party"],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/andrew-karn-auj_oFzaVOw-unsplash-scaled.jpg","_links":{"self":[{"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/posts\/34386","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/comments?post=34386"}],"version-history":[{"count":4,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/posts\/34386\/revisions"}],"predecessor-version":[{"id":45199,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/posts\/34386\/revisions\/45199"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/media\/33579"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/media?parent=34386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/categories?post=34386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/en\/wp-json\/wp\/v2\/tags?post=34386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}