Interview mit Heidi Schmidt und Roland Zurawka, den beiden geschäftsführenden Gesellschaftern der PKS Software GmbH

Raus aus dem Teufelskreis

Mittelständler müssen agil sein. Dazu brauchen sie moderne Anwendungssysteme – performant, flexibel anpassbar, leicht mit anderen Anwendungen zu integrieren und einfach zu bedienen. Genauso wichtig ist eine schlagkräftige IT-Mannschaft, die genau dafür sorgt.

  • Heidi Schmidt und Roland Zurawka, geschäftsführende Gesellschafter der PKS Software GmbH

  • Heidi Schmidt, PKS

    Heidi Schmidt: „Bei der Modernisierung gibt es keinen Königsweg, der für alle Unternehmen gleichermaßen zu empfehlen ist. Jede Organisation hat ihre Besonderheiten, sozusagen ihre eigene DNA, die sich insbesondere in der Individualsoftware zeigt.“

  • Roland Zurawka, PKS

    Roland Zurawka: „Die häufig sehr leidenschaftlich geführte Diskussion darüber, welche Programmiersprache denn nun ‚die einzig Richtige‘ ist, ist ziemlicher Quatsch und lenkt nur von den wirklichen Problemen ab!“

Modernisierung klingt zwar simpel, ist aber ein echter Spagat für die IT-Chefs, denn Unternehmen mit Tradition stehen vor der Herausforderung, die Stärken ihrer bewährten Systeme mit innovativen Konzepten und Technologien in Einklang zu bringen. Gleichzeitig stecken ihre IT-Abteilungen mitten im Generations­wechsel – und müssen für den Know-how-Transfer von erfahrenen Experten auf motivierte Nachwuchskräfte sorgen.

Vor diesem Hintergrund ist es kein Wunder, dass die Nachfrage nach Tools und Services für die Anwendungsmodernisierung boomt. Die US-Firma „Research For Markets“ schätzt, dass sich der Weltmarkt für „Application Modernization Services“ von 10,4 Mrd. Dollar im Jahr 2017 bis Ende 2023 auf 25,6 Mrd. Dollar weit mehr als verdoppeln soll.

Die jährliche Wachstumsrate von 16,3 Prozent lockt neben kleinen Spezialunternehmen auch viele bedeutende Hersteller und IT-Dienstleister an, neben IBM und Partner HCL auch Firmen wie Accenture, Atos, Capgemini, Cognizant, DXC, Fujitsu, Microsoft, Tech Mahindra oder TCS. Dabei ist der Markt stark segmentiert – nicht nur regional und nach Branchen – sondern auch nach den verwendeten Programmiersprachen. Neben RPG- und Cobol-Programmen werden auch PL/1-, Assembler- und zunehmend auch Java- und C-Anwendungen modernisiert.

Dies ist ein Artikel aus unserer Print-Ausgabe 1-2/2019. Bestellen Sie ein kostenfreies Probe-Abo.

Dazu kommen Anwendungen in Sprachen der 4. Generation, wie Adabas, Lansa, Synon, Power Builder oder Delphi. Außerdem kann der Modernisierungs-Markt auch aufgeteilt werden in die Segmente Emulation/Bedienoberfläche, Übersetzung/Umwandlung in andere Programmiersprachen, Transformation der Datenhaltung, Extraktion von Geschäftslogik und Migration auf andere Betriebsplattformen.

Laut Research For Markets war das Thema „User Experience“ bzw. Emulation 2017 noch das wichtigste Marktsegment, das etwa 45,43 Prozent des weltweiten Gesamt­volumens ausmachte. Perspektivisch gewinnt die Extraktion von Geschäftsregeln jedoch stark an Bedeutung.

Zum Einsatz kommen dabei heute oft Microservices, die stark an die Ansätze der „Objektorientierten Programmierung“ erinnern, die vor 20 Jahren en vogue waren. IBM-Stichwort: SAA. Ziel war es, wie bei Lego-Spielzeug sozusagen einen Vorrat mit Funktions- und Datenbausteinen bereitzustellen, mit dem sich dann schnell und einfach neue Anwendungen zusammenstecken lassen.Dazu befragten wir Heidi Schmidt und Roland Zurawka, die beiden geschäftsführenden Gesellschafter der PKS Software GmbH.

Frau Schmidt, vor zwei Jahren haben wir uns über das „IBM-i-Paradoxon“ unterhalten. Hat sich seither etwas daran geändert?
Heidi Schmidt: Auf jeden Fall. Das Paradoxon ist zwar noch dasselbe, aber die Umgebungsparameter haben dazu geführt, dass sich IBM-i-Anwender mit ihren individuell entwickelten Anwendungen heute mehr denn je in einem gefährlichen Teufelskreis wiederfinden:
Die Kernsysteme sind seit zwanzig Jahren oder länger im Einsatz und sollten eigentlich schon längst abgelöst sein. Doch viele Vorhaben sind gescheitert, nach wie vor treiben IBM-i-Systeme die geschäftskritischen Prozesse in den Unternehmen. Doch die Verrentung der ehemaligen Knowhow-Träger in Kombination mit dem Bedarf der digitalen Transformation verschärft den Handlungsdruck, erhöht das Betriebsrisiko und wird zur strategischen wie auch operativen Notwendigkeit.

Täuscht mein Eindruck oder hat die „Legacy-Modernisierung“ – einst ein eher unbeliebtes Schmuddelthema – mittlerweile die notwendige „Management-Attention“ gewonnen?
Schmidt: Absolut! Glaubte man bis vor ein paar Jahren auf Management-Ebene noch, dass die IT das Problem schon lösen wird, ist man mittlerweile zur Erkenntnis gekommen, dass das Thema „Legacy-Modernisierung“ nicht nur die Entwicklungsteams, sondern insbesondere auch die Fachbereiche sowie auch die Führungsebene betrifft – und dass nur alle drei genannten Teams gemeinsam die unabdingbare Transformation bewältigen können.

Roland Zurawka: Dies zeigt auch eine ­aktuelle IDG-Studie zum Thema „Legacy-Modernisierung“. Dem zufolge sehen 91,1 Prozent der Firmen die Modernisierung, Migration oder Transformation ihrer Bestandssysteme als Grundvoraussetzung für die digitale Transformation überhaupt. Dabei geht es den Unternehmen primär um die Aspekte Sicherheit und Verbesserung der Geschäftsprozesse.

Schmidt: Jedoch ist man nicht einmal bei jedem vierten Unternehmen, nämlich nur bei 23,4 Prozent, mit den bisherigen Ergebnissen der Bemühungen zufrieden. Mir scheint es so, als ob die letzten 24 Monate bei dem Begriff „Digitale Transformation“ in vielen Unternehmen das Wort „Digital“ im Fokus stand. Man hat aber nun realisiert, dass die „Transformation“, also die Überführung der heutigen Prozesse und der Anwendungen, in denen diese sich manifestieren, nur dann gelingt, wenn man sich mit den heute in Produktion befindlichen Systemen auseinandersetzt und den Transformationsprozess von dort beginnend startet.

Umstieg auf Standardsoftware, Neuentwicklung, Einstellung weiterer Mitarbeiter oder Outsourcing der Pflege oder Managed-Services dafür: Welche Option empfiehlt sich denn für das Management, wenn es eine Überalterung wichtiger Anwendungssysteme feststellt?
Schmidt: Hier gibt es keinen Königsweg, der für alle Unternehmen gleichermaßen zu empfehlen ist. Jede Organisation hat ihre Besonderheiten, sozusagen ihre eigene DNA, die sich insbesondere in der Individualsoftware zeigt. Um seinen eigenen Weg zu finden, ist es empfehlenswert, mit einer Bestandsaufnahme zu starten. Diese hat in der Regel vier Komponenten:
1) Rückbetrachtung zur bisherigen Modernisierungserfahrung (Was wurde schon gemacht? Wo kann auf Erfahrungen im eigenen Hause zurückgegriffen werden? Was lässt sich daraus ableiten für das weitere Vorgehen?)
2) Technische Analysen der Sourcen, Re-Dokumentation des Bestandssystems und Komplexitäts­vermessung. Hier geht es darum, das Wissen über den Ist-Zustand zu materialisieren und Transparenz zu schaffen. Häufig steckt viel Wissen nur in Köpfen ein paar weniger erfahrener Mitarbeiter. Hier gilt es anzusetzen und diese „Kopfmonopole“ aufzulösen, um wirklich zu verstehen, wie „der Laden heute läuft“. Im Rahmen eines Software-Assessments kann man hier z.B. mit dem Code-Analyse-Werkzeug eXplain innerhalb weniger Wochen selbst umfangreiche Systeme so gut verstehen, dass die Grundlage für das weitere Vorgehen, egal in welche Richtung, geschaffen ist. Ein ganz zentraler Aspekt ist hierbei die Identifikation von totem Code: häufig finden wir bis zu 35 Prozent und mehr an Programmbestandteilen, die gar nicht mehr genutzt werden!
3) Neben dem technischen Durchblick sind vor allem die fachliche Strukturierung und eine Transparenz für die heute gelebten Prozesse unabdingbar; insbesondere ist eine enge Zusammenarbeit mit dem Fachbereich notwendig. An dieser Stelle ist es für viele Teams auch neu, dass sich Entwickler und Fachbereichsmitarbeiter auf Augenhöhe begegnen. Auch die fachliche Strukturierung kann toolgestützt mit eXplain erfolgen, sodass technische Implementierung und fachliche Strukturierung „übereinandergelegt“ werden können. Dadurch entstehen Bilder, die sicherstellen, dass Entwickler und Fachbereich sich auch wirklich verstehen und nicht aneinander vorbeireden.
4) Weitere relevante Aspekte betreffen die Entwicklungsprozesse sowie den Skill-Fit im Entwicklerteam. Dabei geht es darum, zu erfassen, wo heute Potentiale liegen – und auch Chancen für das Vorhaben (die vom Management so geliebten Quick-Wins).

Zurawka: Erst wer sich diesen Überblick verschafft hat, kann die relevanten Modernisierungs­ziele für das Vorhaben ableiten. Dabei ist es wichtig, diese an der Unternehmensstrategie abzuleiten, denn daran muss sich alles orientieren. Modernisierung, Migration, Ablösung oder Neuentwicklung der IT sind ja kein Selbstzweck, sondern strategische Vorhaben, die das Unternehmen in seiner Gesamtheit betreffen.
Mancher Kunde möchte gleich loslegen, ohne genau zu wissen, von welchem Ausgangspunkt er startet. Davon raten wir dringend ab. Warum? Dazu verwende ich gern ein kleines Beispiel aus dem Alltag: wenn Sie nach Rom in den Urlaub fahren wollen, ist es für die Reiseplanung (Kosten, Transportmittel, beste Reisezeit, Proviant usw.) absolut unabdingbar zu wissen, von welchem Ort aus Sie starten. Genauso verhält es sich mit der Legacy-Modernisierung: wenn nicht klar ist, wo sich das Unternehmen, die betroffenen Anwendungen sowie die Anwender aktuell genau befinden, ist jede Reiseplanung hinfällig. Das Ziel wird nur über Umwege, mit hohen Abweichungen von der Planung erreicht werden. Dazu jedoch sind die IT-Systeme viel zu kritisch, als dass man einfach mal so drauflos entwickeln kann.

Inwieweit ist die Modernisierung der Legacy-IT ein akutes Thema, das schnell gelöst werden muss? Oder erfolgt die Modernisierung eher mittelfristig? Oder sogar langfristig und strategisch angelegt?
Schmidt
: „Schnell lösen“ ist relativ. Sicherlich kann innerhalb von zwölf Monaten viel erreicht werden – abhängig eben vom Ausgangszustand. Aber das Thema muss in aller Regel schon als Programm aufgesetzt werden, das in mehrere Teilprojekte unterteilt wird und mit der Methodik „Scrum for Legacy“ auch agil umgesetzt werden.

Können aktuelle IT-Trends wie Dev-Ops oder Cloud Computing bei der Modernisierung helfen? Welche Trends sind hier besonders nützlich?
Schmidt
: Im Bereich Dev-Ops komme ich bei der Legacy-Modernisierung ganz automatisch an: die Realität sieht leider oft noch so aus, dass weder die Kommunikation noch die Workflows zwischen „Dev“ und „Ops“ rund laufen. Das ist häufig gar nicht so sehr ein technisches Problem, als vielmehr ein kommunikatives, denn Fachbereich und Entwicklung haben es über Jahre gelernt, eher aneinander vorbeizureden. Für den Fachbereich ist häufig nicht transparent, was die Entwicklung tut; das führt dort zu Unzufriedenheit und Ablehnung. Also startet das Modernisierungsprojekt in der Regel am besten mit der Einführung eines Anforderungsmanagements, das für alle Beteiligten transparent macht, wie mit Störungen sowie mit neuen Anforderungen umgegangen wird und wo diese jeweils im Bearbeitungs- und Realisierungsprozess stehen. Cloud Computing steht unserem Erleben nach noch am Anfang. Klar, viele IBM-i-Anwender lagern aktuell ihre Hardware und den System­betrieb zu Infrastruktur-Partnern aus. Das ist aber noch eher das klassische „Outsourcing“. „Computing“ in der Cloud, im Sinne der Nutzung von Programmen dort, sehen wir bisher selten. Da sind doch die „einfachen“ Herausforderungen, die oben beschrieben sind, häufig noch zu dringlich. Und eine Anwendung einfach nur „as-is“ in die Cloud zu verschieben (was sicher möglich ist), löst die wahren Probleme überhaupt nicht.

Sind altbewährte Programmiersprachen wie wie RPG für solche Modernisierungsansätze überhaupt tauglich – oder müssten die Neuerungen nicht in anderen Sprachen wie Java, C/C++ oder Ruby erfolgen?
Zurawka
: Die häufig sehr leidenschaftlich geführte Diskussion darüber, welche Programmier­sprache denn nun „die einzig Richtige“ ist, ist ziemlicher Quatsch und lenkt nur von den wirklichen Problemen ab. Sowohl FreeRPG als auch Java oder .Net sind valide Programmiersprachen. Als Entwickler muss man in der Lage sein, die richtige Technologie und Sprache zu wählen, die für die jeweilige Anforderung die einfachste und stabilste Lösung verspricht. Dazu muss ich als Entwickler natürlich auch die Vor- und Nachteile, die jede Sprache nun einmal hat, kennen. Das scheitert bei IBM-i-Entwicklern oft daran, dass sie sich 15 oder 20 Jahre ausschließlich mit RPG beschäftigt haben – und dort oft nicht einmal weggekommen sind von RPG III oder IV. Hier sollte also nicht dogmatisch der Teufel mit dem Beelzebub ausgetrieben werden, sondern im Entwicklerteam offen über die passende Programmiersprache diskutiert und problembezogen entschieden werden.
Auch hier lohnt sich eine Moderation und Input von außen, vor allem dann, wenn die Fronten bereits so verhärtet erscheinen, dass ein konstruktiver Dialog kaum noch möglich erscheint.

Microservices sind eine aktuelle Antwort der Software-Ingenieure, wenn es heute um die Modularisierung monolithischer Anwendungssysteme und ihre Einbettung in firmenübergreifende IT-Infrastrukturen geht. Taugt der Ansatz „Microservices“, der Vorteile wie Agilität, Flexibilität und Skalierbarkeit verspricht, auch für die Modernisierung bewährter RPG-Anwendungen?
Zurawka
: Ja, das würde ich schon sagen. Wobei ich gleich ergänze, dass der der Ansatz ja nichts Neues ist: Microservices sind ein Architekturmuster, bei dem komplexe Software aus unabhängigen Prozessen komponiert wird, die über sprachunabhängige Programmierschnittstellen miteinander kommunizieren. Alle Dienste sind weitgehend entkoppelt und erledigen jeweils kleine Aufgaben. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware.
Es ist also ein altes Konzept, das eben bisher oft noch nicht angewandt wurde. Nun geht es erneut darum, sich diesen Prinzipien zu nähern, denn natürlich finden wir in Legacy-Systemen auf IBM i noch viele monolithische Architekturen, die aufgebrochen werden müssen, um dann wieder agil und flexibel weiterzuentwickeln zu können. Denn das ist ja einer der wichtigsten Vorteile, die Unternehmer von ihrer Individualsoftware erwarten: dass die Entwickler rasch und architektonisch sicher Erweiterungen implementieren und das vorhandene System verbessern. Somit ist das also ein absolutes „Muss“ für alle, die ihre Eigenentwicklung fortführen möchten.
Aber auch bei einer Ablösung kommt man darum nicht ganz herum, denn für den Übergangszeitraum werden ja in jedem Fall Alt- und Neu-System parallel betrieben. Auch hierzu ist eine modulare Struktur hilfreich – und muss für den Übergang zumindest rudimentär geschaffen werden.

Sowohl die Entwicklung als auch der Betrieb von Microservice-Architekturen kann sehr schnell sehr komplex werden. Gibt es Tricks und Kniffe, diese Komplexität zu beherrschen?
Schmidt
: „Zaubertricks“ gibt es da eben nicht – nur gute Lösungen am Markt, auch von IBM, die das API-Management unterstützen. Auf jeden Fall bleibt das für die Anwender eine Herausforderung, da es hier ja eigentlich um Wissensmanagement im Unternehmen geht. Das ist bisher für viele oft schon eine große Herausforderung, thematisiert durch das IBM-i-Paradoxon um das Kopfwissen der erfahrenen Entwickler – und das wird nun beim API-Aspekt erneut eine Anforderung.

Moderne Technologien in der Software-Entwicklung, aber auch das gute alte RPG gelten als komplex, etwas obskur und nicht einfach zu erlernen. Wie kann man diese Welten so zusammenbringen, dass ein Projektteam in beiden Welten zu Hause ist und die Modernisierung zuverlässig und effizient vorantreiben kann?
Schmidt
: Es gibt nicht wirklich „gute und schlechte Technologien“ oder „moderne und alte“ – aus unserer Erfahrung heraus hat ja meist jede Technologie, jedes Verfahren und jedes Konzept seine Stärken und Schwächen. Und ein einzelner Entwickler oder Architekt kann sich in aller Regel nur mit einer bestimmten Menge davon beschäftigen und diese beherrschen.
Daher ist es heute unabdingbar, dass Software-Entwicklung in Teams stattfindet – mit Knowhow-Trägern verschiedener Schwerpunkte, die kommunikations- und diskussionsfähig sind. Hier liegt oft noch der Hase im Pfeffer: bei der Kommunikation hapert es nämlich leider oft noch gewaltig. Viele scheitern an den un­bewussten Irrtümern über Kommunikation.

Ist das ein Grund, warum PKS mittlerweile mehr ist als nur ein Tool-Anbieter?
Zurawka
: Absolut! Wir nutzen zum Beispiel das „Limbische Kommunikationsmodell“  in unseren Projekten, mit großem Erfolg. Und deshalb bieten wir inzwischen auch LKM-Kurse an.

Muss PKS nicht auch näher am Kunden sein? Von Ravensburg aus lassen sich doch vermutlich nicht all die kniffligen Probleme beim Kunden remote lösen?
Zurawka
: Da haben Sie absolut recht. Aktuell reisen unsere Mitarbeiter von Ravensburg aus durch die gesamte DACH-Region, um die Kunden vor Ort in kritischen Phasen zu begleiten. Damit wir zukünftig noch näher und schneller vor Ort sein können und auch die Reisezeiten für unsere Mitarbeiter reduzieren können, eröffnen wir in Laufe des Jahres auch eine Geschäftsstelle in Frankfurt.

Herzlichen Dank für das Interview!

Bildquelle: Dieter Kölbl

©2019Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok