B-Sec 3: Compliance NFRs & Agilität: Agile Reife als Voraussetzung

Die Reife des Unternehmens in Bezug auf Agilität

Hierbei ist klar geworden, dass eine Mindestreife des Unternehmens in Bezug auf Agilität vorhanden sein muss. Um ein auf Agilität und dezentralem Agieren basierendes Konzept zum Leben zu bringen, bedarf es eben einer gewissen stabilen (agilen) Reife. Diese Reife beinhaltet:

Das Leben eines agilen Entwicklungsprozesses mit DoR- und DoD-Definitionen auf den verschiedenen Abstraktionsstufen der Entwicklung. Bei SAFe sind diese Abstraktionsstufen zum Beispiel Portfolio Epic[1], Feature[2] und Story[3].
Das erfolgreiche Aufsetzen von DevOps[4]-Teams mit möglichst automatisierten DevOps-Pipelines in definierten Umgebungen.
Das Etablieren von regressionsfähigen Test-Suites in den verschiedenen Umgebungen (z.B. Entwicklung, Integration, Abnahme, Operations), die ebenfalls in die DevOps-Pipelines integriert sind.
Ein Repository basierendes Versions- und Konfigurations- und Testmanagement für die Bausteine der Entwicklung, um nachvollziehen zu können, welche Validierungen zu den operativ genommenen Software Bausteinen vorhanden sind. Dies ist eigentlich eine Voraussetzung für DevOps.
Ein standardisiertes Repository-Konzept, welches definiert in welchem Repository die dokumentierte Validierung der NFR-Tests festgehalten wird und zur Verfügung steht.

Ist dieser – durchaus anspruchsvolle – Reifezustand im Unternehmen vorhanden, so lösen sich viele der eher schwergewichtigen Upfront-Arbeiten mit der Zeit auf, da sich die übergreifenden und integralen NFR wie bereits erwähnt nur langsam verändern. Ein IAM-Konzept ist im Unternehmen irgendwann ausreichend stabil, die zugehörigen Bausteine einer System-Architektur sind mit der Zeit zum grössten Teil implementiert und unterliegen einem üblichen Maintainance Zyklus. Die Checklisten in den DoR und DoD sollten vorhanden und bekannt sein. Eine regressionsfähige Test-Suite zum Validieren der Teilanforderungen zu den NFR mit den relevanten Integrations- und Abnahmetest sollte über die Zeit ebenfalls vorhanden sein. Somit beschränkt sich die wesentliche Veränderung auf das Delta der jeweiligen Entwicklung im Rahmen weiterer Features.

Allgemeine Aussagen zu «Reife des Unternehmens»

Der hier beschriebene konzeptionelle Ansatz übergreifende und integrale NFR in einem agilen Setup zu erfüllen, setzt ebenso eine gewisse Reife und Selbstdisziplin im Unternehmen voraus. Bestimmte Elemente des Ansatzes sind übergreifend einzuhalten. Diese sind vor allem:

das Verwenden von DoR und DoD
das Verwenden von definierten Repositories in Analyse, Design, Testing und Validierung in der Entwicklung, sowie für die Dokumentation der operativen Systeme
teamübergreifendes Anwenden gleicher Verfahren in Analyse, Design, Testing, Validierung und Dokumentation
Selbstdisziplin aller beteiligten Teams in Entwicklung und Operations

Selbstdisziplin ist ein heikler Punkt, der einer geeigneten Kommunikation und Führung im Unternehmen bedarf. In einem grösseren Unternehmen, welches regulatorischen Rahmenbedingungen unterliegt, müssen sich alle Mitarbeitenden bewusst sein, dass gewisse Verfahren ganzheitlich und einheitlich definiert werden und einzuhalten sind.

Das verstösst nicht gegen den agilen Mindset. Die einzelnen Aufgaben sind nach wie vor dezentral verortet. Wie ein einzelnes Verfahren implementiert wird, zum Beispiel die System-Architektur oder die Test-Suite zur Validierung, ist eine Definition, die zum Beispiel von einer Community of Practice (ausgestattet mit Entscheidungsrecht für gewisse Standards) getroffen werden kann.

Anmerkung: Nach der persönlichen Auffassung des Autors sind Selbstdisziplin, freiwillige Beschränkung auf die zum Erfüllen der Aufgabe notwendigen Mittel und das Streben nach Einfachheit wichtige Eigenschaften von agilen und schlanken (lean) Systemen. Eine Organisation sollte dazu zu einer Haltung kommen. Nehmen wir Einfachheit: Standardisierung ist bestimmt ein Aspekt der Einfachheit unterstützt. Zu wenig Standardisierung verursacht Verschwendung durch Pflege einer nicht benötigten Vielfalt. Zu viel Standardisierung hingegen induziert Steifheit in Systemen, verhindert Flexibilität und erhöht Abhängigkeiten. Es gilt also zu diskutieren welcher Grad an Standardisierung für die einzelnen Bausteine eines soziotechnischen Ökosystems, also eines Unternehmens, geeignet ist.

Ich vermeide bewusst an dieser Stelle den Begriff der «Kultur», obwohl Selbstdisziplin durchaus als kultureller Wert einer agilen Organisation verstanden werden kann, der durch das Führungsverhalten im Unternehmen beeinflusst wird.

Insgesamt ist mit dem hier vorgestellten Ansatz der administrative Overhead für Entwicklungsteams so minimal wie möglich. Die von einem agilen Team einzuhaltenden administrativen Aufgaben für ein zu deployendes Inkrement einer Software beschränkt sich auf das Einhalten gewisser Verfahren gemäss DoR bzw. DoD in Analyse, Design, Test und Validierung. Geht ein Unternehmen konsequent diesen Weg, so entstehen über die Zeit die einzelnen Elemente, welche das Konzept implementieren. Diese Elemente sind zum grössten Teil (automatisierbar) wiederverwendbar. Der zusätzliche Aufwand auf der Seite von Entwicklungsteams ist, wenn automatisiert, vertretbar.

Der Umgang mit verteilter Verantwortung

Ein klassischer Manager, verantwortlich für Security & Compliance, würde an der Stelle eventuell wie folgt argumentieren: «Ich sehe die Verantwortung für die vollständige Erfüllung der NFR bei einer Person!» – schon alleine, um zu wissen, wessen Kopf rollt, wenn doch einmal etwas schief gehen sollte.

Hier greift der Grundgedanke von Agilität. Agilität akzeptiert die Realität, dass eine einzelne Person nicht in der Lage ist das umfassende und notwendige Know-How zu besitzen, um alle Aspekte des vorgestellten Konzeptes ausreichend qualifiziert zu verstehen und zu hinterfragen. Liegt die Gesamtverantwortung bei einer Person, so delegiert diese Person zwangsmässig Tätigkeiten und Verantwortung an weitere Personen oder Organisationseinheiten. Management Overhead und Abstimmungsmassnahmen, etwa über eine Organisationseinheit wie das zentrale CISO, sind dann zwingend notwendig, um alle Fäden zusammenzuhalten.

In einer dezentralen, agilen Organisation ist die Verantwortung verteilt, jedoch mit klarer Zuweisung, welche Rolle, beziehungsweise welches Team welchen Teil der Verantwortung trägt und zusätzlich auch die Durchführung der damit verbundenen Aufgabe. So ist die Verantwortung an der Stelle, an der auch Fähigkeit zur kompetenten Erfüllung der damit verbundenen Aufgabe vorhanden ist.

Abstrakt betrachtet könnte die Verteilung der Verantwortung wie in Abbildung 1 erfolgen. Wie bereits im ersten Blog der Serie erkannt, zerfällt eine Anforderung in Detailanforderungen, die wiederum von unterschiedlichen Teams aufzunehmen und zu erfüllen sind. In einer Implementierung nach dem SAFe Framework existiert bereits eine Struktur, um die Detailanforderungen zu verorten, wie im Folgenden beschrieben.

Abbildung 1: Implementierung der dezentralen Verantwortung im Kontext des SAFe Frameworks

Die NFR selbst werden auf Portfolio Ebene den Epics beziehungsweise den Capabilities zugeordnet. Verantwortlich diese zu erfüllen sind die in Abbildung 1 gelisteten Rollen und Experten. Die Akzeptanzkriterien sind zuvor in Zusammenarbeit mit dem CISO erarbeitet worden.

Ein Detailstufe tiefer sind Anforderungen auf der Ebene der Feature. Eine grosse Anzahl dieser Detailanforderungen sind bereits erfüllt in der Form von Software-Bausteinen oder einer Entwicklungsplattform, die von der System & Software Architektur definiert und implementiert wurden. Nur einige wenige Anforderungen bedingen eine zusätzliche Implementierung. Die Validierung auf dieser Abstraktionsstufe ist ebenfalls zum Grossteil bereits vorhanden, vorausgesetzt es existiert (siehe: agile Reife der Organisation) eine regressionsfähige Testsuite.

Noch eine Detailstufe tiefer kommen die Anforderungen auf Ebene der Programmierung. Erfahrungsgemäss sind dies nur einige wenige. Da auch hier bereits die Akzeptanzkriterien definiert sind, sind die entsprechenden Entwicklerteams auch in der Lage die damit verbundenen Test zur Verifizierung zu implementieren – und so eventuell die regressionsfähige Testsuite zu erweitern.

Die Besonderheit streng regulierter Umgebungen

Eine einschränkende Rahmenbedingung besteht: Eine extern notwendige Zertifizierung oder Abnahme durch offizielle Regulatoren beschränkt die Freiheit zu einem beliebigen Zeitpunkt inkrementell deployen zu können. Ist eine externe Zertifizierung oder Abnahme gefordert, bezieht sich diese auf einen definierten und nachvollziehbaren Scope einer Entwicklung, welcher mit seinen Validierungsergebnissen der offiziellen Stelle zur Abnahme vorgelegt werden muss. Dies bedeutet selbstverständlich eine Wartezeit in der Entwicklung zwischen Erreichen der DoD einer Funktionalität und dem operativen Einsatz. Je nach Aufwand des offiziell einzuhaltenden Verfahrens ist zu überlegen, in welchen Inkrementen eine solche Entwicklung gestaltet wird.

In streng regulierten Umgebungen, wie Medizintechnik oder Aviation bedeutet das eine erhebliche Einschränkung, zumal die durchgängige Transparenz der Nachvollziehbarkeit von den Anforderungen, über Implementierung bis zur Validierung einen erheblichen zusätzlichen Aufwand zur reinen Implementierung verursacht. Zugegeben ist in diesen Umgebungen ein agiles Vorgehen mit schnellen Deployments neuer Versionen eines Produktes oder eines Service nur beschränkt möglich.

[1] Siehe https://www.scaledagileframework.com/epic/

[2] Siehe https://www.scaledagileframework.com/features-and-capabilities/

[3] Siehe https://www.scaledagileframework.com/story/

[4] Erklärung des Begriffs DevOps der Weissenberg Group: https://weissenberg-group.de/was-ist-devops/