{"id":33501,"date":"2023-09-08T08:53:34","date_gmt":"2023-09-08T06:53:34","guid":{"rendered":"https:\/\/www.blue.works\/?p=33501"},"modified":"2026-02-17T13:06:02","modified_gmt":"2026-02-17T12:06:02","slug":"alm-kaffeekraenzchen-v-dual-landscape-teil-3","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/alm-kaffeekraenzchen-v-dual-landscape-teil-3\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen V – Dual Landscape Teil 3"},"content":{"rendered":"\n

Zwei Landschaften f\u00fcr ein Produktivsystem<\/h2>\n\n\n\n

Wie von der FB Methodik empfohlen, entfalten sich die Projekt-gesteuerten \u00c4nderungen entlang einer 4-systemigen Projektlandschaft, die ein zus\u00e4tzliches Pre-Production System enth\u00e4lt.<\/p>\n\n\n\n

\"\"
Abbildung 1 Zwei System-Landschaft \u2013 Cutover Szenario 1<\/figcaption><\/figure>\n\n\n\n

Es gibt verschiedene Szenarien f\u00fcr den Cutover (Go-Live) eines Releases aus der Projektlandschaft in das gemeinsame Produktivsystem, man siehe die Auflistung in der FB Configuration Guide, Kapitel \u201eCutover Checks and Post Cutover Activities: Configuration \u2013 Overview\u201c.<\/p>\n\n\n\n

Wir entscheiden uns f\u00fcr das in der FB Configuration Guide so benannte \u201eSzenario 1\u201c, weil es mit unserem Vorschlag der Koexistenz von Major und Minor Releases besser zusammenpasst.<\/p>\n\n\n\n

Projekte<\/h3>\n\n\n\n

Eines der grossen Vorteile der schl\u00fcsselfertigen L\u00f6sung Focused Build<\/a> ist die fest vorgegebene Strukturierung der Projekte mit ihren Phasen und den vorgegebenen Quality Gates. FB folgt dem agilen Projekt-Paradigma und organisiert die Arbeit in der entscheidenden Realisierungsphase in Waves<\/em> und Sprints<\/em>. Wer Wasserfall-Projekte bevorzugt, legt einfach pro Projekt nur eine Wave und einen Sprint an.<\/p>\n\n\n\n

\"\"
Abbildung 2 Beispiel f\u00fcr ein Quartals-Projekt<\/figcaption><\/figure>\n\n\n\n

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

Das Pre-Production System ist kein zweites QA System. Sein Vorteil liegt auf der Hand: Die dort stattfindenden Integrations- und Regressionstests werden nicht durch st\u00e4ndige neue Importe invalidiert. Denn jede \u00c4nderung erzwingt die Wiederholung der Tests: Durch die \u00c4nderung k\u00f6nnte sich ja ein neuer Seiteneffekt eingeschlichen haben.<\/p>\n\n\n\n

In der Testphase auf dem Pre-Production System sind nur noch Korrekturen der beim Testen entdeckten Fehler erlaubt. Hierzu bietet Focused Build die spezialisierte \u201eDefect Correction\u201c Vorgangsart an.<\/p>\n\n\n\n

Die Entwicklung kann w\u00e4hrend des Freeze<\/em> des Pre-Production System weitergehen, doch sie erfolgt f\u00fcr das n\u00e4chste Release oder den n\u00e4chsten Phasenzyklus.<\/p>\n\n\n\n

Im Pre-Production System wird umfangreich und intensiv all das und nur das getestet, was im n\u00e4chsten Go-Live tats\u00e4chlich produktiv gehen wird.<\/p>\n\n\n\n

\"\"
Abbildung 3 Testen in einer 4-System-Landschaft<\/figcaption><\/figure>\n\n\n\n

Wartung<\/h3>\n\n\n\n

Da die FB Methodik einen Projektplan mit vielen Q-Gates erwartet, empfehle ich f\u00fcr Transporte innerhalb der Wartungslandschaft die Verwendung der klassischen ChaRM Change Documents<\/em>. Solange tats\u00e4chlich nur Korrekturen und kleinere Anpassungen an bestehenden Prozessen hier erfolgen, sollten in der Wartungs-Landschaft drei Systeme reichen.<\/p>\n\n\n\n

Bei aktivem FB wird stand heute (FB SP10) bei Minor Release Zyklen die Verwendung von Request for Changes oder IT Requirements leider nicht im Standard unterst\u00fctzt. Wer in der Wartungslandschaft den RfC f\u00fcr einen Genehmigungsworkflow ben\u00f6tigt, muss statt Minor Release Zyklen \u201enormale\u201c Phasen-Zyklen anlegen1<\/a><\/sup>.<\/p>\n\n\n\n

Aus dem Labor<\/h2>\n\n\n\n

Es sei hier auf einem Solution Manager Sandbox-System die Dual System Landschaft mit Major und Minor Releases skizziert.<\/p>\n\n\n\n

Der K\u00fcrze halber setze ich voraus, dass die SAP Dokumentation der verwendeten Werkzeuge und das FB spezifische IMG bekannt sind.<\/p>\n\n\n\n

Die zwei Systemlandschaften<\/h3>\n\n\n\n

Wartungslandschaft<\/h4>\n\n\n\n
\"\"
Abbildung 4 Wartungslandschaft, mit dem Projekt-Entwicklungssystem als Retrofit Ziel<\/figcaption><\/figure>\n\n\n\n

Projektlandschaft<\/h4>\n\n\n\n
\"\"
Abbildung 5 Projektlandschaft<\/figcaption><\/figure>\n\n\n\n
\"\"
Abbildung 6 Logische Komponentengruppe BL_SOLMAN_LCG mit Development und Maintenance Branches<\/figcaption><\/figure>\n\n\n\n

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

Wir g\u00f6nnen unserer Demo eine eigene Change Control Landscape (CCL), denn das Releasemanagement basiert auf diese. Eine CCL kann nur ein Release haben.<\/p>\n\n\n\n

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

Da wir die Projekt-Landschaft mit FB bedienen m\u00f6chten, m\u00fcssen wir die neue CCL im Customizing konfigurieren (s.u.), und beim Start der CRM WebUI m\u00fcssen wir die Business Rolle \u201e\/SALM\/RLSMNG – Release Manager\u201c ausw\u00e4hlen.<\/p>\n\n\n\n

\"\"
Abbildung 8 Release Management Configuration – Task Type<\/figcaption><\/figure>\n\n\n\n
\"\"
Abbildung 9 und das Mapping<\/figcaption><\/figure>\n\n\n\n

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

Wir gehen in die Release-Planung und planen ein ganzes Jahr im Voraus. Es ist bequemer, zuerst nur die Major Releases anzulegen, und die Minor zu den Major danach.<\/p>\n\n\n\n

Da die Minor Releases nur nach dem Go-Live des vorherigen Major Releases m\u00f6glich sind (es gibt kein Release 0), setzen wir in unserer Demo den initialen Release einfach auf den n\u00e4chstbesten Termin. Wenn man bereits standard ChaRM einsetzt, kann man auf diese kleine Starthilfe verzichten, indem man bis zum Go-Live des Releases 1.0 die Maintenance-Landschaft mit ChaRM bedient wie bisher (klingt ChaRMant<\/em>, nicht wahr?).<\/p>\n\n\n\n

\u00dcblicherweise werden die grossen Projekt-Go-Live am Wochenende durchgef\u00fchrt.<\/p>\n\n\n\n

\"\"
Abbildung 10 Anlage von Quartals-Releases f\u00fcr ein Jahr<\/figcaption><\/figure>\n\n\n\n
\"\"
Abbildung 11 Erste Planung, manuelle Anpassung der Go-Live Termine auf Quartal-Anfang<\/figcaption><\/figure>\n\n\n\n

Wir f\u00fcgen jetzt ein Relase Zyklus hinzu.<\/p>\n\n\n\n

\"\"
Abbildung 12 Release 1.0 mit Zyklus<\/figcaption><\/figure>\n\n\n\n

Beim allerersten Mal wird der Aufgabenplan f\u00fcr die Projektlandschaft angelegt. Alle weiteren Zyklen werden sich diesen Aufgabenplan teilen.<\/p>\n\n\n\n

\"\"
Abbildung 13 Der neue Projekt-Aufgabenplan<\/figcaption><\/figure>\n\n\n\n

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

Jetzt markieren wir das Release 1.0 und f\u00fcgen 14-t\u00e4gige Minor Releases f\u00fcr die Maintenance-Landschaft hinzu. Wir w\u00e4hlen Donnerstag f\u00fcr den Go-Live Tag. So hat man bei eventuellen Go-Live Problemen noch den Freitag f\u00fcr notwendige Korrekturen zur Verf\u00fcgung.<\/p>\n\n\n\n

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

Abbildung 14 Ein Paket von Minor Releases<\/p>\n\n\n\n

Wir passen die Termine manuell an. Release 1.6 muss leider in einem zweiten Schritt hinzugef\u00fcgt werden, da die Anwendung einfach zu intelligent ist bei der Berechnung der Termine und sich weigert, in einem Quartal 6 Minor Releases auf einen Schlag anzulegen.<\/p>\n\n\n\n

\"\"
Abbildung 15 Sechs 14-t\u00e4gige Minor Releases<\/figcaption><\/figure>\n\n\n\n

Und dies ist der Aufgabenplan f\u00fcr die Maintenance-Landscape:<\/p>\n\n\n\n

\"\"
Abbildung 16 Maintenance Aufgabenplan<\/figcaption><\/figure>\n\n\n\n

Customizing Phasenmodel<\/h3>\n\n\n\n

Um bei aktivem FB auch f\u00fcr die Minor Releases der Wartungslandschaft Request for Change anlegen zu k\u00f6nnen, muss man folgende Eintr\u00e4ge \u00fcber den View-Cluster \/TMWFLOW\/VC_PHMD hinzuf\u00fcgen:<\/p>\n\n\n\n

\"\"
Abbildung 17 Customizing Phasenmodell<\/figcaption><\/figure>\n\n\n\n

M\u00f6chten sie den n\u00e4chsten Teil nicht verpassen? dann k\u00f6nnen sie diesen hier <\/a>nachlesen.<\/p>\n\n\n\n

\n\n\n
  1. Hintergrund:
    Bei aktivem FB wird die Release-Vorgangsart S1MR verwendet. S1MR hat das Phasen-Model \u201eS1RL\u201c, und diesem fehlen in der Tabelle \/TMWFLOW\/TPPHMAC Eintr\u00e4ge f\u00fcr den klassischen RfC. M\u00f6chte man trotzdem RfCs f\u00fcr ein Minor Release anlegen, muss man die Eintr\u00e4ge \u201eRFC_CREATE\u201c oder \u201eITR_CREATE\u201c von \u201eRELE\u201c passend f\u00fcr \u201eS1RL\u201c kopieren. Siehe das Beispiel aus Kapitel \u201eCustomizing Phasenmodel\u201c \u00dcbrigens, mit FB SP11 wird Focused Build auch den \u201eRequest To Fulfill\u201c Prozess in der Maintenance Landschaft unterst\u00fctzen.     \u21a9\ufe0e<\/a><\/li><\/ol>","protected":false},"excerpt":{"rendered":"

    Wie von der FB Methodik empfohlen, entfalten sich die Projekt-gesteuerten \u00c4nderungen entlang einer 4-systemigen Projektlandschaft, die ein zus\u00e4tzliches Pre-Production System enth\u00e4lt.<\/p>\n","protected":false},"author":16,"featured_media":33578,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"[{\"content\":\"Hintergrund:
    Bei aktivem FB wird die Release-Vorgangsart S1MR verwendet. S1MR hat das Phasen-Model \u201eS1RL\u201c, und diesem fehlen in der Tabelle \/TMWFLOW\/TPPHMAC Eintr\u00e4ge f\u00fcr den klassischen RfC. M\u00f6chte man trotzdem RfCs f\u00fcr ein Minor Release anlegen, muss man die Eintr\u00e4ge \u201eRFC_CREATE\u201c oder \u201eITR_CREATE\u201c von \u201eRELE\u201c passend f\u00fcr \u201eS1RL\u201c kopieren. Siehe das Beispiel aus Kapitel \u201eCustomizing Phasenmodel\u201c \u00dcbrigens, mit FB SP11 wird Focused Build auch den \u201eRequest To Fulfill\u201c Prozess in der Maintenance Landschaft unterst\u00fctzen.\",\"id\":\"4112bc35-c7b8-4669-bbc3-ce25788b5517\"}]"},"categories":[344],"tags":[336],"class_list":["post-33501","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alm-kaffeekraenzchen-das-alm-magazin","tag-kaffeekraenzchen"],"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\/de\/wp-json\/wp\/v2\/posts\/33501","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/comments?post=33501"}],"version-history":[{"count":22,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33501\/revisions"}],"predecessor-version":[{"id":45175,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33501\/revisions\/45175"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media\/33578"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media?parent=33501"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/categories?post=33501"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/tags?post=33501"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}