In kleinen Schritten zur besseren Entwicklung

Kleine Schritte, große Wirkung: Software Development Governance

Paul Lajer und Erwin Lang

Hinterfragt man in Unternehmen oder Organisationen, wie die Entwicklung von Applikationen bezüglich standardisierten und verbindlichen Vorgaben praktiziert werden, erhält man in vielen Fällen die Antwort, dass der Architekt für die Einführung und Einhaltung von Code Conventions verantwortlich ist. Regelungen, die darüber hinaus die Entwicklung beeinflussen, werden nicht getroffen oder sind nicht existent. Doch gerade dadurch geraten Unternehmen, die die Entwicklung von Applikationen überwiegend an externe Dienstleister vergeben, spätestens bei der Übernahme in den Betrieb in arge Bedrängnis – und tragen eine Mitschuld am Verzögern oder Scheitern von Projekten.

Wenn man nach Gründen für das Scheitern von Projekten sucht, findet man eine große Anzahl von Studien oder Erhebungen zu dieser Thematik. Als Faktoren werden u. a. unqualifizierte Ressourcen bezüglich der eingesetzten Technologie, falsche oder fehlende Anforderungen in der Spezifikation, unklare Ziele oder eine unrealistische Zeitplanung genannt. Projekte können aber auch aufgrund von fehlenden oder missachteten Regeln oder Vorschriften bei der Entwicklung von Applikationen scheitern oder eine Abnahme verzögern. Gerade wenn man als Dienstleister Applikationen im eigenen Haus entwickelt, besitzt man Freiheiten, um sich zu verwirklichen. Spätestens jedoch bei der Auslieferung der Applikation an den Kunden kann es hier ein böses Erwachen geben, das bis zur Verweigerung der Übernahme in den Betrieb führen kann. Die nachfolgenden Punkte beschreiben aus unserer Sicht einen Ausschnitt der Probleme:

  • Eingesetzte Software: Aus Sicht eines Softwareentwicklers ist es u. a. selbstverständlich, die aktuellsten Frameworks, Produkte und APIs und deren Abhängigkeiten zu verwenden. Ein Unternehmen reagiert in der Regel nicht ganz so dynamisch auf die Einführung von neuen Releases oder Produkten, sodass die Applikation auf der bestehenden Kundenumgebung mangels Know-how oder einer inkompatiblen Systemlandschaft nicht betrieben werden kann.
  • Infrastruktur und Architektur: Falsche architektonische Entscheidungen haben eine erhebliche Auswirkung bezüglich Skalierbarkeit oder Erweiterungen.
  • Zugriff auf Interne Systeme: In der Regel werden Applikationen nicht als Standalone-Lösung implementiert, sondern bedienen sich der Informationen unterschiedlicher interner Systeme im Unternehmen. Das stellt Entwicklerteams vor die Herausforderung, wie ein Zugriff auf diese Systeme implementiert werden kann, ohne den internen Zustand oder das Verhalten dieser zu kennen.

Es ist durchaus denkbar, dass die beschriebenen Probleme einem mangelhaften Projektmanagement inklusive mangelnder Kommunikation, falscher Architekturentscheidungen oder übermotivierten Entwicklern anzulasten sind. Trotzdem würde durch einen Einsatz von Vorgaben und Regeln diese Problematik deutlich entschärft werden. Abbildung 1 zeigt hierbei Ansätze einer Lösung, wobei die Prozesse, die zu einer Lösung führen, nicht betrachtet werden.

Abb. 1: Vereinfachter Ansatz einer Software Development Governance
Welche Technologien darf ich benutzen

Im oberen Abschnitt wurde bereits erläutert, dass ein Scheitern von Projekten trotz des Einsatzes der neuesten Technologien eintreten kann. Das trifft auch zu, wenn die Entwicklung auf Basis von veralteten Technologien stattfindet, oder durch einen Einsatz eine Inkompatibilität der Applikation mit der Systemlandschaft des Betreibers hervorgerufen wird. Die einfachste Möglichkeit zur Vermeidung und Unterbindung eines unkontrollierten Einsatzes von Technologien (APIs, Frameworks, Open-Source-Produkten etc.) in Projekten ist schlicht und einfach die Definition und Bekanntgabe der eingesetzten Technologien, die später im Betrieb der Organisation eingesetzt werden dürfen. Was sich jedoch auf dem Papier logisch und leicht darstellen lässt, kann in der Realität schnell komplexe Züge annehmen und Abhängigkeiten aufweisen. Beschreiben wir jedoch zunächst die vom Projektleiter oder Entwickler zu stellenden Anforderungen bezüglich einer Informationsquelle, z. B. einem Dokument mit den dargestellten Ergebnissen der durchgeführten Prüfungen.

Als eine zentrale Anforderung müssen in diesem Ergebnisdokument primär alle Informationen über die freigegebenen Technologien (Whitelist) enthalten sein. Der Entwickler muss hieraus eindeutig und zweifelsfrei erkennen können, welche Frameworks oder APIs in einem Projekt verwendet werden dürfen. Es reicht jedoch nicht aus, das untersuchte Artefakt zu benennen, sondern es muss durch weitere Eigenschaften, z. B. um Informationen über die Releaseversion, angereichert werden. Weiterhin kann das Dokument um Ausschlüsse (Blacklist) ergänzt werden, also um Technologien, die explizit nicht in einem Projekt verwendet werden dürfen, da durch einen Einsatz eventuell Kompatibilitätsprobleme mit anderen Systemen oder Komponenten innerhalb der Organisation und seiner Systemlandschaft entstehen würden. Ergänzt werden kann das Dokument durch weitere Informationen, wie der Benennung von Zeitpunkten, zu denen ein Artefakt seinen Status von White auf Black wechselt, da bereits einer der Nachfolger (z. B. ein neues Release) freigegebenen wurde. Dieser feste Zeitpunkt kann natürlich auch durch überlappende Zeitfenster definiert werden, sodass einem Entwickler die Möglichkeit gegeben wird, bereits ein neues Release zu verwenden, obwohl das alte ebenfalls noch die entsprechende Gültigkeit besitzt.

Anhand der genannten Beispiele kann erkannt werden, wie einfach oder komplex ein solches Dokument aufgebaut werden kann. In Abhängigkeit dazu müssen natürlich die entsprechenden Prozesse entwickelt und implementiert werden, um die benötigten Informationen einzuholen, die das gewünschte Ergebnis widerspiegeln. So muss durch die Organisation definiert werden, zu welchem Zeitpunkt und in welchen wiederkehrenden Abständen neue Releases untersucht werden. Es müssen Aussagen getroffen werden, ob lediglich Major-Releases oder auch Minor-Releases betrachtet werden sollen. Was dabei den Grad der Komplexität steigen lässt, sind die direkten Abhängigkeiten zu anderen Artefakten, die somit in eine Gesamtbetrachtung einbezogen werden müssen. So ergibt es keinen Sinn, das Spring Framework in der Version 3.0 für die Entwicklung freizugeben, wenn nicht entsprechend der dazu kompatible Servlet-Container und damit auch das JDK innerhalb der Whitelist neu aufgenommen oder angepasst werden. Als eine weitere Herausforderung stellt sich der Umgang mit Artefakten dar, die nicht untersucht werden können (alleine die Apache Software Foundation bietet ca. 100 Top-Level-Projekte an, sodass es in einer Organisation unmöglich sein wird, alle auf dem Markt verfügbaren Artefakte abzudecken). Hier müssen die Prozesse um Möglichkeiten erweitert werden, individuelle APIs zu prüfen und diese projektabhängig freizugeben oder entsprechend abzulehnen.

Zusammenfassend kann hier festgestellt werden, dass allein bei der Einführung eines solchen Dokuments erhebliche Aufwände innerhalb einer Organisation entstehen können, die aber wiederrum durch die einfache Skalierbarkeit des erwarteten Ergebnisses (welche Ergebnisse muss diese Liste abdecken und in welcher Genauigkeit) stark reduziert oder entsprechend erhöht werden können.

Geschrieben von
Paul Lajer und Erwin Lang
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.