Für Unternehmen rückt ein neues Aufgabenfeld mehr und mehr ins Rampenlicht: Compliance, die Einhaltung von gesetzlichen und anderen zwingenden Richtlinien. Weltweit werden unter diesem Schlagwort Anforderungen diskutiert, die durch zahlreiche Gesetze und Standards an das Risiko-Management eines Unternehmens gestellt werden; GDPdU, GoBS, SOX, Basel II, Chargenrückverfolgung und Außenwirtschaftsgesetz §34 seien hier exemplarisch genannt. Unternehmensweites Risiko-Management umfasst immer auch das IT-Risiko-Management und somit steht das Thema Compliance weit oben auf der IT-Agenda in allen Unternehmen. Denn: verstößt „die IT“ gegen gesetzliche Auflagen, kann das für die Verantwortlichen strafrechtliche Konsequenzen haben. Zum Beispiel sieht das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) eine persönliche Haftung des Vorstandes oder der Geschäftsführung vor, wenn keine Vorsorge oder Frühwarnung im Rahmen des unternehmensweiten Risikomanagements betrieben wurde. Somit wird deutlich: Compliance ist Chefsache – und die Software-Entwicklungsabteilung stellt als „Produktionsstätte“ der im Unternehmen genutzten Anwendungen eine zentrale Rolle dar.

Bisher wird fast ausschließlich darüber geklagt, wie sich die vielen Vorgaben bewältigen lassen und was es die Unternehmen kosten werde. Die Einsicht, dass Compliance jedoch auch eine Chance bietet, bestimmte Probleme in der IT und wesentliche auch in der Software-Entwicklung fundiert zu lösen und so die eigene Wettbewerbsfähigkeit zu steigern, fehlt noch weitgehend. Unternehmen, die für künftige Regulierungsanforderungen gerüstet sind, also über eindeutig definierte Prozesse mit hohem Automatisierungsgrad, Transparenz in der Software-Entwicklung und moderne IT-Architekturen verfügen, sind einfach auch leistungsfähiger.

Somit lassen sich heute zwei zentrale Anforderungen für den Bereich der Software-Entwicklung ableiten:
(1) Die Transparenz des Entwicklungsprozesses und der Applikationen muss erhöht werden, um schnell neue Anforderungen umsetzen zu können. Das ist die Grundlage, um den zahlreichen rechtlichen Auflagen heute stand zu halten und auch in Zukunft agil entgegentreten zu können.
(2) Die Kosten sollen gesenkt und bereits getätigte Investitionen geschützt werden (Return on Asset). Das ist unabdingbar, um eine solide Ausgangsbasis für den künftigen Erfolg, weiteres Wachstum und eine Erhöhung der Profitabilität eines Unternehmens zu schaffen.

Die zentrale Herausforderung ist dabei die Flexibilität, die entwickelten Anwendungen schnell an neue Reglementarien anzupassen. Das funktioniert nur auf Grundlage von Systemen und Prozessen, die diese Flexibilität unterstützen. Daraus lassen sich folgende Anforderungen an das Lifecycle-Management in der Software-Entwicklung ableiten:

1. Die Rollen und Verantwortlichkeiten entlang des gesamten Entwicklungsprozesses – vom Coding über das Testen bis hin zur Freigabe an die Produktion – müssen klar definiert und jedem Entwickler bekannt sein. Dadurch werden immer wiederkehrende und zeitraubende Konflikte über Zuständigkeiten, versehentlich überschriebene Programmsequenzen und ungetestet in den Produktivbetrieb gelangte Versionsstände von vornherein vermieden und alle Änderungen am Source-Code nachvollziehbar gemacht. Als Ergebnis erhält man ein dokumentiertes Änderungswesen und ein verbessertes Zusammenarbeiten der Mitarbeiter.
2. Ein zentrales, tagesaktuelles Repository als Referenz über den gesamten Source-Code (auch über alle Plattformen hinweg) ist nötig, um effizient entwickeln zu können. In vielen Unternehmen verbringen die Programmierer bis zu zwei Drittel Ihrer Zeit damit, schon implementierten Code zu verstehen, bevor sie neue Funktionalität schreiben können. Dies liegt daran, dass es kein aktuelles Referenzsystem gibt und vor jeder neuen Zeile Code viel händischer Aufwand betrieben wird, um mögliche Auswirkungen abschätzen zu können.
3. Ein Sicherheitskonzept, das den Zugriff auf die Objekte klar definiert und somit vor fehlerhaften oder ungewollten Änderungen schützt, ist ebenfalls empfehlenswert. Es sollte möglich sein, den Transfer von Objekten zwischen den verschiedenen Systemen an bestimmte Personen zu binden. Hier kann ein Tool helfen, in dem das Sicherheitskonzept festgeschrieben und von dem es automatisch auch kontrolliert umgesetzt wird.
4. „Rollback“-Funktionalitäten sollten implementiert werden, um bei fehlerhaften Programmständen schnell, einfach und sicher auf die vorherige Version zurückgehen zu können.
5. Dokumentationen sind ein zentrales Element, um Compliance-gerecht zu arbeiten: Änderungen am Source-Code müssen dokumentiert sein – ebenso wie es Verfahrensanweisungen geben muss, in denen die Funktionalität und Bedienung der Software niedergeschrieben sind. Da die wenigsten Entwickler mit Leidenschaft Dokumentationen erstellen und das Nachhalten von Änderungen häufig im Tagesgeschäft in Vergessenheit gerät, ist es zu überdenken, ob hier mit gezielter Werkzeug-Unterstützung automatisiert und standardisiert ein gutes Ergebnis erzielt werden kann.
6. Automatisierte Tests vereinfachen die Arbeit des QA-Teams und führen durch eine höhere Auslieferungsqualität zu verbesserter Anwenderzufriedenheit. Eine „Record-and-Play“-Funktionalität kann zusätzlich schon beim Erstellen von Testfällen helfen. Wenn dann noch Möglichkeiten bestehen, Massendaten zu generieren oder aus dem Produktivsystem zu extrahieren, sind Mehrwerte für die Mitarbeiter unmittelbar ersichtlich. Der Datenschutz muss dabei natürlich durch Verschlüsselung sichergestellt sein.
7. Abgerundet werden kann ein Software-Lifecyle-System noch durch die Integration in ein Helpdesk-Tool. Dadurch können Fehlerbehebungen und Funktionserweiterungen unmittelbar mit Störungsmeldungen verknüpft werden.

Auch wenn der Einsatz eines Application Lifecycle Tools keine direkte Anforderung von SOX, Basel II oder GDPdU ist, machen sie es in der Praxis quasi unumgänglich, solche Werkzeuge zu nutzen. Nur damit sind Entwicklungsteams überhaupt in der Lage, den heutigen und zukünftigen Reglementarien gerecht werden zu können. Ob es gleich eine ganze Tool-Suite sein muss oder ob es nur darum geht, punktuell mit Werkzeugen den Entwicklungsprozess zu unterstützen, kann pauschal sicherlich nicht gesagt werden.
PKS – der Technologieberater für iSeries-Nutzer – stellt Entwicklungsabteilungen daher optimal auf Teamgröße und Anwendungskomplexität zugeschnittene Werkzeuge bereit. Dafür wird die Expertise aus fast 20 Jahren Projekterfahrung und Entwicklungskooperationen mit namhaften Software-Häusern genutzt. Compliance und Software-Entwicklung – zwei Welten, die voneinander profitieren!

Fachautorin: Heidi Schmidt