Mögliche Hinweise die Du Kandidat:innen zum Herangehen geben kannst:

1. Überlege Dir, was das eigentliche Ziel der Beurteilung im weiteren Kontext des Cases ist

• In diesem Fall besteht das Ziel der Bewertung darin, die wichtigsten Bereiche in der IT-Landschaft zu identifizieren und die Probleme zu priorisieren, die am dringendsten angegangen werden müssen
• Konzentriere Dich auf die wichtigsten Informationen – es reicht aus, die wichtigsten Dimensionen zu erfassen (eine detaillierte Bewertung ist weder erforderlich noch gewünscht)

2. Denke daran, wem die Ergebnisse präsentiert werden sollen, und passe den Kommunikationsstil entsprechend an

• Der CIO ist wahrscheinlich nicht an kleinen Details interessiert, während andere Mitglieder des Top-Managements auf der Kundenseite möglicherweise nicht über ein tiefes technisches Wissen verfügen
• Konzentriere Dich auf die übergreifende Sichtweise und vermittle zunächst die Kernaussagen; vertiefe anschließend ausgewählte Themen (falls erforderlich). Du kannst einen strukturierenden Rahmen nutzen, um eine ganzheitliche Sicht zu vermitteln und gleichzeitig die Analyse zu strukturieren

Exemplarische Lösung (andere Antworten sind möglich)

• Definiere den Rahmen für die Bewertung 
  - Die Zuordnung von IT-Anwendungen auf die Wertschöpfungskette der Branche und die Geschäftsfelder bietet eine ganzheitliche Sicht (teile bei Bedarf Abbildung 1 als Beispiel für die Visualisierung des Mappings)
  - Relevante Dimensionen für die Analyse der Anwendungen könnten sein:
  • "Wichtigkeit" (geschäftskritisch oder nicht) 
  • “Grad” (hoch/mittel/niedrig) der ermittelten Probleme in Bezug auf Stabilität, Skalierbarkeit, hohe TTM (Time-to-Market) 
  • “Art der Anwendung” (z. B. Eigenentwicklung oder Standard-Software)
• Beschreibe den Ansatz, den Du zur Durchführung der Bewertung wählen würdest 
  - Analyse verfügbarer Dokumente (z. B. Anwendungsübersicht/Inventory, Berichte über Incidents zur Ermittlung von Stabilitätsproblemen) 
  - Führung von Interviews mit den wichtigsten Interessengruppen (z. B. CIO, Leiter:in des IT-Betriebs, ausgewählte Business Relationship Manager:in/ Bereichsleiter:in), um die obigen Informationen zu ergänzen
• Definiere die Treiber für die Priorisierung von Deep Dives und Empfehlungen
  - Konzentriere Dich auf geschäftskritische Anwendungen, die besonders schwerwiegende Probleme aufweisen, und behandele den Rest nur im Ausnahmefall

Mögliche Hinweise die Du Kandidat:innen zum Herangehen geben kannst: 

1. Definiere Annahmen, um die Analyse fokussiert anzugehen

• In Anbetracht der begrenzten Informationen (und Zeit), die zur Verfügung stehen, ist es wichtig, im Vorfeld plausible Hypothesen zu definieren, die die Analyse leiten
• Überprüfe diese Hypothesen mit dem Interviewer und passe Deinen Ansatz je nach dem erhaltenen Feedback des Interviewers an

2. Gehe die Schmerzpunkte nacheinander an und sei dabei kohärent

• Beschreibe die technologischen Hebel, mit denen jeder Schmerzpunkt angegangen werden könnte, einen nach dem anderen, und erläutere dabei die Hauptgründe für die Empfehlung

Exemplarische Lösung (andere Antworten sind möglich)

• Schmerzpunkt “Stabilität” 
  o Hypothesen zu den Ursachen
  - Fehlerhafter/schlecht geschriebener eigenentwickelter Code (ggf. aufgrund verschiedener Änderungen im Laufe der Zeit) mit eingeschränkter oder nicht vorhandener Dokumentation 
  - Veraltete/nicht mehr unterstützte Anwendungen 
  - Exzessive Anpassung von Standard-Software 
  o Vorgeschlagener technischer Hebel 
  - Refactoring der Eigenentwicklungen in eine modulare und entkoppelte Architektur: Die Überarbeitung der aktuellen Anwendungen ist zu komplex. Es ist voraussichtlich einfacher, die Anwendungen ganz oder teilweise unter Verwendung neuer Technologien und vor allem mit einem modularen Ansatz (z. B. "Microservices-Architektur") neu zu schreiben; und hierdurch eine einfachere Isolierung von Fehlern zu ermöglichen, sodass die nicht betroffenen Funktionen weiter funktionieren und somit die Gesamtstabilität erhöht wird 
  - Bestehende Eigenentwicklungen durch standardisierte Commercial-of-the-Shelf Anwendungen ersetzen
• Schmerzpunkt „Skalierbarkeit“
  o Hypothesen zu den Ursachen 
  - Grundsätzliche Einschränkungen durch die IT-Architektur (z. B. ein monolithischer Ansatz, der eine Skalierung der gesamten Anwendung erfordert (auch wenn nur einzelne Funktionen von einem steigenden Anfragevolumen betroffen sind), potenzielle Engpässe (z. B. Enterprise Service Bus, Datenbanken)) 
  - Veraltete/"kapazitätsbeschränkte" IT-Infrastruktur 
  o Vorgeschlagener technischer Hebel 
  - Cloud-Lösungen: PaaS (Platform-as-a-Service) Cloud-Lösungen können für neue oder „refactored“ Eigenentwicklungen genutzt werden, um Kapazitätsbeschränkungen der lokalen Infrastruktur zu überwinden. Ebenso können SaaS (Software-as-a-Service) Lösungen für Standard-/nicht differenzierende Funktionalitäten genutzt werden
• Schmerzpunkt “Time-to-Market”
  o Hypothesen zu den Ursachen 
  - Grundsätzliche Einschränkungen durch die IT-Architektur (z. B. ein monolithischer Ansatz, der eine Skalierung der gesamten Anwendung erfordert (auch wenn nur einzelne Funktionen von einem steigenden Anfragevolumen betroffen sind), potenzielle Engpässe (z. B. Enterprise Service Bus, Datenbanken)) 
  - Abhängigkeiten aufgrund der hochgradig integrierten/gekoppelten IT-Anwendungslandschaft (jedes Release neuer Funktionalitäten in einer Anwendung kann Abhängigkeiten zu verschiedenen anderen Anwendungen haben) 
  - Komplexes und manuelles Software-Release-Management 
  o Vorgeschlagener technischer Hebel 
  - Refactoring der Eigenentwicklungen in eine modulare und entkoppelte Architektur: Neben höherer Stabilität ermöglicht die Modularisierung auch eine schnellere Implementierung von Funktionalitäten, da jedes einzelne Modul unabhängig geändert und bereitgestellt werden kann 
  - Bestehende Eigenentwicklungen durch standardisierte Commercial-of-the-Shelf Anwendungen ersetzen 
  - Automatisierung des Software-Entwicklungslebenszyklus (SW development lifecycle automation, SDLC): Neben dem Refactoring führt die Einführung neuer SDLC-Ansätze wie DevOps mit einem starken Fokus auf Automatisierung (z. B. automatisierte Tests, kontinuierliche Bereitstellung usw.) zu schnelleren Release-Zyklen

Mögliche Hinweise die Du Kandidat:innen zum Herangehen geben kannst: 
1. Setze Prioritäten und beginne damit, die wichtigsten Dimensionen zuerst zu beschreiben

• Fühle Dich nicht gedrängt, eine vollständige Liste der Dimensionen zu erstellen, nehme Dir Zeit, die Antwort zu strukturieren
• Fordere Dich selbst heraus, Themen zu identifizieren, die nicht sofort offensichtlich sind

2. Beispiele sind ein guter Weg, um die Konzepte zu untermauern; mache die Beispiele so spezifisch wie möglich

• Berücksichtige den Case-/Kundenkontext, wenn Du Beispiele geben willst; z. B. könnte ERP in vielen Fällen ein gutes Beispiel für eine geschäftskritische Anwendung sein, aber nicht, wenn der Kunde eine Versicherung ist

Exemplarische Lösung (andere Antworten sind möglich) 

• Refactoring zu Microservices (modulare & entkoppelte Architektur) 
  - Relevanz für das Business und dessen spezifische Anforderungen: Der Aufwand für eine interne Neu-Implementierung ist für geschäftskritische, differenzierende Funktionalitäten sinnvoll 
  - Erwartete Häufigkeit von Änderungen: Anwendungen, bei denen eine hohe Änderungshäufigkeit und entsprechende Releases neuer Funktionen zu erwarten sind (z. B. Aufgrund von geschäftlicher Priorität oder rechtlichen/regulatorischen Anforderungen), profitieren am meisten von der verkürzten Einführungszeit 
  - Heterogene Skalierbarkeitsanforderungen: Das Refactoring von Anwendungen mit hohen Skalierbarkeitsanforderungen für ausgewählte Funktionalitäten, ermöglicht eine hohe Effizienz bei der Skalierung dieser Module (anstatt der gesamten monolithischen Anwendung)
• Einführung von Cloud-Lösungen 
  - Nutzungsverhalten („Usage Pattern“): Anwendungen mit dynamischen Nutzungsmustern (d. h. Lastspitzen/-täler im Vergleich zu einer gleichbleibenden Last) profitieren am meisten von der elastischen Skalierbarkeit, die durch Cloud-Lösungen ermöglicht wird (z. B. anwendbar auf PaaS-Lösungen in Kombination mit einer neuen Microservice Implementierung) 
  - Technologische Kompatibilität: Einige Technologien (z. B. Cobol, z/OS) eignen sich kaum für Cloud-Migrationen (obwohl dies im Falle einer SaaS-Einführung transparent wäre) 
  - Empfindlichkeit bezüglich Latenz: Anwendungen, die sehr "latenzempfindlich" sind, könnten durch die zusätzliche Latenz, die durch Cloud-Optionen im Vergleich zu On-Premise-Lösungen entsteht, negativ beeinflusst werden