Die DevOps-Philosophie in der SAP-Welt

Wie lassen sich Organisationsstrukturen im SAP-Umfeld für DevOps befähigen? Welche Herausforderungen ergeben sich? Mit dieser Fragestellung befasst sich Tom Schneider im zweiten Teil der Blog-Reihe zum Thema DevOps für SAP.

Falls Sie den ersten Artikel zu diesem Thema verpasst haben, diesen finden Sie hier.

Höhere Wertschöpfung durch IT als Ziel

DevOps ermöglichen eine höhere Wertschöpfung der Unternehmens-lT durch einen schnelleren Entwicklungsprozess. Qualitativ höherwertige Eigenentwicklungen und automatisierte Releaseprozesse führen auf diese Weise auch in SAP on premise zu einer höheren Betriebssicherheit der bestehenden Systemlandschaft.

Die Automatisierung bestehender Unternehmensprozesse in SAP ist abhängig von der Organisationsstruktur des jeweiligen Unternehmens. Diese Struktur muss nun für die agilen Prozesse und schnelleren Prozesslaufzeiten von DevOps befähigt werden.

Herausforderung: Zusammenspiel zwischen Kultur, Menschen und Technologie

In klassisch aufgestellten SAP-Betriebsorganisationen sind neben technischen Voraussetzungen eine Reihe nicht-technischer Spezifika zu beachten. Um in der Vergangenheit das Risiko eines Produktionsstillstands durch Eigenentwicklungen zu minimieren, wurde Flexibilität im SAP-Entwicklungsprozess durch starre Releasezyklen mit langen Testzeiträumen gehemmt. Releasezyklen von mehreren Monaten sind so zur Normalität geworden. Die große Mehrzahl an SAP-Kunden betreibt derzeit mehrere, voneinander getrennt agierende Entwicklungs- und Betriebsteams. Entwickler schreiben ihren ABAP- oder Java-Quellcode auf dem dafür vorgesehenen Entwicklungssystem und gegenüberstehende SAP Basis-Teams kümmern sich um einen möglichst störungsfreien Systembetrieb der Produktivumgebung. Jede Eigenentwicklung, die in das produktive System transportiert wird, stellt für die SAP Basis in erster Linie ein Betriebsrisiko dar. Analog ist jede Anforderung aus der SAP Basis für Entwickler eine ungeplante Verzögerung. Leider ist dies Alltag und geht zu Lasten des Kunden. Neue Geschäftsanforderungen werden nicht in akzeptabler Zeit umgesetzt und stauen sich in der Development Pipeline. Die so entstandenen „Mammut-Releases“ erhöhen das Risiko von Systemausfällen. Geht die Produktivsetzung dieser großen Upgrades schief, zieht dies kritische Produktionsausfälle nach sich. Zudem fehlt den ausführenden Mitarbeitern bei wenigen Produktivsetzungen oft schlicht die Routine für diesen Prozess. Dadurch leidet die Arbeitsqualität bei allen Beteiligten, Entwicklern und Administratoren, sowie bei Kunden, die auf neue Funktionalitäten warten.

IT-Abteilungen stehen also vor der Herausforderung, mit begrenzten Ressourcen zunehmend komplexere SAP-Landschaften immer schneller an sich stetig verändernde Anforderungen anzupassen. Dies ist ein Spagat, den nur ein grundlegender Methodenwechsel möglich macht.

Eigenverantwortung und Kollaboration

Zum Kern der DevOps-Philosophie gehört auf sozialer Ebene, talentierte und eigenverantwortliche IT-Mitarbeiter zu fördern und ihnen mehr Hoheit in ihren Fachbereichen zu gewähren. Als Basis dient eine gemeinsame Vision des ganzen Teams, ein übergeordnetes Ziel, das regelmäßig besprochen und stetig verfeinert wird. Sogenanntes “Swarming“, also frühes Einbeziehen von möglichst vielen fähigen Mitarbeitern zur schnellen Lösung eines schwierigen technischen Problems, führt im Regelfall zu einer frühen Problemlösung bei noch niedriger Eskalationsstufe. Wird das Problem im konventionellen Betriebsmodus nicht gelöst, steigt der Eskalationsdruck, und letztendlich arbeitet auch hier das ganze Team an der Lösung. Die Lieferung verzögert sich und die Frustration bei Kunden und im Team ist hoch. Hier hilft eine Anpassung der eigenen Arbeitsweise an die sich schnell und stetig ändernden Anforderungen.

Als erstes gemeinsames Ziel kann ein agiles SAP formuliert werden.

Sinnvolle Entscheidungsfindung

Genehmigungsprozesse dürfen nicht hemmen und Entscheidungen müssen fachlich getroffen werden. So sollten im Rahmen von DevOps für SAP nur fachlich wirklich notwendige Genehmigungsschritte in Prozessen beibehalten werden. Alle anderen Genehmigungen können mithilfe intelligenter, automatisierter Prozesse durch Tools abgebildet werden. Flache Hierarchien bedeuten in diesem Sinne auch eine Rückkehr zu fachbasierten Entscheidungen. Denn mit der Wegnahme von rein verwaltenden Prozessschritten tritt die fachliche Umsetzung der Arbeit — etwa Coding, Testing und Administration — wieder in den Vordergrund. Zudem sind Entscheidungen im Sinne des gesamten Unternehmens zu treffen, nicht nur im Sinne einzelner Abteilungen. Dies kann durch ein punktuelles, themenbezogenes Zusammenziehen der notwendigen Experten aus den jeweiligen Fachgebieten realisiert werden.

Das zweite gemeinsame Ziel stellen automatisierte Genehmigungs- und Testverfahren dar.

Interdisziplinäre Teams

Wer Genehmigungsprozesse abbaut, muss an deren Stelle neue Mechanismen zum Abfangen von erwartbaren Problemen setzen. So sollten beispielsweise Administratoren, Qualitätssicherung, Information Security und anfordernder Fachbereich bereits im frühen Entwicklungsprozess mitarbeiten, sodass rückwärtsgewandte, aufwändigere Prüfungen im Nachhinein vermieden werden. Auf diese Weise können agile Ansätze, wie DevOps für SAP, Silos im Unternehmen reduzieren. Sie fördern eine neue, offene und zielorientierte Unternehmenskultur. Das Hauptaugenmerk bei der Einführung einer agilen SAP-Betriebsorganisation liegt somit auf den handelnden Personen, danach erst auf Tools und Plattformen. Eine DevOps-Einführung soll in diesem Rahmen SAP- und Non-SAP-Teile des Unternehmens wieder harmonisieren. Wenn im Folgenden von interdisziplinären Teams gesprochen wird, beinhalten diese je ein Mitglied aus Entwicklung (Dev), Basis-Administration (Basis), Quality Assurance (QA), Information Security (InfoSec) sowie anfordern- dem Fachbereich (Kunde).

Das dritte gemeinsame Ziel ist die Etablierung von themen- und rollenübergreifenden Teams.

Freuen Sie sich jetzt schon auf den dritten Teil der Blog Artikelreihe mit dem Thema „Übertragung des DevOps-Frameworks auf SAP“.

 

Autor: Tom Schneider, Technischer Architekt

Kontakt: Tom.Schneider@realtech.com

Comments

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *