Daraus ergaben sich Aufgaben, wie die Analyse der Altsysteme und die Frage nach deren “Aufbruch“. Was wird in die Cloud kommuniziert und wie sieht eine DMZ innerhalb der Cloud aus, um die Security zu ermöglichen, die die Daten fordern. Wie wird der Durchstich von On-Premise zur Cloud aufgebaut? Mit welchen Services von AWS arbeiten wir, um diesen Durchstich zu ermöglichen?
Für uns ergaben sich konkrete Artefakte, die aus den Architektur- und Inventurworkshops entstanden sind, wie die Soll vs. Ist-Architektur und eine mächtige Inventurliste mit Daten wie Formatbestimmungen pro System, Payload pro Transaktion, Transaktionsraten, Komplexitätsgrad der Schnittstellen, Wiederverwendbarkeit der Templates (Format-Templates), Kommunikation von System A zu System B erfolgt über Schnittstelle X, uvm. Daraus ließ sich ablesen welche Schnittstellen ähnlich aufgebaut sind und damit eine Standardisierung zulassen (Wiederverwendbarkeit der Komponenten), welche wiederum sind individuelle Schnittstellen, lassen sich also gar nicht verallgemeinern und müssen/ oder sollen nicht mehr angebunden werden.

Ein Resultat aus dieser Vorarbeit war die Erkenntnis, welche Fachbereiche wir mit einbeziehen müssen, da diese vom Integrationsprozess insbesondere betroffen waren und mit welcher Auswahl an Systemen wir beginnen sollten um den größten “Bang for the Bug“ zu kriegen.

Klar war, wenn wir beweisen konnten dass wir eine schnelle und vor allem sichere Integrationen mit den ausgewählten Systemen hinkriegen, hätte es eine Signalwirkung auf andere Fachbereiche des Konzerns, um den internen Widerstand zur digitalen Transformation ein Stückchen weiter zu überwinden.