B-Sec 4: Compliance NFRs & Agilität: Veranschaulichung an einem fiktiven Beispiel

Das in diesem Blog vorgestellte fiktive Beispiel veranschaulicht die konkrete Umsetzung des Konzeptes „Umgang mit Compliance relevanten NFRs in Scaled Agile Environments», welches die vorangegangenen drei Blogs der Serie vorgestellt haben.

Nehmen wir ein Unternehmen, welches den Kunden über die Seite www.MyUnternehmen.com einen persönlichen Self-Service Bereich anbietet. Das Unternehmen möchte im Ausbau von www.MyUnternehmen.com dem Kunden als weiteres Feature Gesundheitsdaten bereitstellen, welche vertraulich sind. GDPR finden somit zwingend für diese Kundendaten Anwendung.

Das Unternehmen hat die folgende Reife erreicht und verfügt vor dem Start der Entwicklung des Features über die folgenden Elemente, zum Teil aus bereits früher durchgeführten Aktivitäten:

• Der Entwicklungsprozess des Unternehmens basiert auf dem Scaled Agile Framework SAFe, d.h. ein Produktfeature wird im Rahmen eines sogenannten Portfolio Epic realisiert. Aus Management Sicht ist ein Portfolio Epic ein administratives Gefäss für ein Umsetzungsvorhaben zur Steuerung des Portfolios, dessen Outcome dem Kunden einen Wert liefert.
• Das Cyber & Information Security Office (CISO) verfügt über eine komplette Liste der relevanten, übergreifend, integral und ganzheitlich zu erfüllenden NFR im Kontext des Unternehmens.
• Zu jedem einzelnen NFR der Liste existieren die Detailanforderungen und deren Akzeptanzkriterien, die von den verschiedenen Organisationseinheiten beziehungsweise in der Entwicklung zu erfüllen sind.
• Es existiert ein Fragebogen zur Risiko Klassifizierung von Portfolio Epics. Die Risiko Klassifizierung, durchgeführt als Zusammenarbeit von CISO mit dem Verantwortlichen für das Portfolio Epic (dem Epic Owner), ergibt die Liste der übergreifend, integral und ganzheitlich zu erfüllenden NFR für ein konkretes Portfolio Epic.
• In Zusammenarbeit von CISO und Human Ressource ist ein Rollen und Rechte Konzept aufgebaut worden, das IAM (Identity & Access Mgmt) Konzept. Dieses regelt, welche Zugriffsrechte eine Person in einer definierten Rolle auf Daten und Applikationen im Unternehmen besitzt.
• In Zusammenarbeit von CISO und Software Architecture sind in den letzten zwei Jahren Software Komponenten entwickelt worden für Querschnittsthemen wie Access Management, Grundsätze der Datenhaltung in Cloud Umgebungen, Verschlüsselung von Daten, Schnittstellen Technologien. Diese Komponenten erfüllen ein Set der Detailanforderungen und Akzeptanzkriterien zu den NFR und sind von den Entwicklungsteams in der Entwicklung zu verwenden.
• Die Softwareentwicklung setzt die Atlassian Tools Jira und Confluence ein.

Das Erfüllen der übergreifenden und integralen NFR für das Portfolio Epic könnte ablaufen, wie im Folgenden beschrieben. Dabei ist dies nur eine mögliche Form den konzeptionellen Ansatz zu implementieren.

Abbildung in den Atlassian Tools Confluence und Jira

Erzeugt das Unternehmen ein neues Portfolio Epic, so wird im Jira System der Firma ein Ticket eröffnet, welches das Portfolio Epic repräsentiert. Das Ticket wird zusammen mit weiteren Portfolio Epics in einem Jira-Kanban geführt als das Lean Portfolio des Unternehmens.

Aus dem Ticket des Portfolio Epic zeigt ein Link auf eine Confluence Page, welche den Lean Business Case[1] des Epic repräsentiert

(siehe Abbildung 1). Confluence ist ein wiki System, welches eng mit Jira integriert ist. Der Lean Business Case nimmt Grunddaten des Portfolio Epic auf wie Hypothese und Scope, Priorität in der Entwicklung, erwarteter Wert nach Realisierung, etc.

Bei Erzeugen des Portfolio Epic «Bereitstellen und Verwalten der Gesundheitsdaten im Kundenbereich» führt das CISO zusammen mit dem BO (=Business Owner, er trägt die fachliche Gesamtverantwortung für den Kundenbereich) und dem EO (=Epic Owner, er trägt die Umsetzungsverantwortung für das Feature einschliesslich Wirkungskontrolle beim Kunden) die Risikobewertung durch. Das Ergebnis ist der im Kontext des Epic relevante Subset der NFR.

Dieses Subset der NFR wird einschliesslich sämtlicher davon abgeleiteter Detailanforderungen und deren Akzeptanzkriterien in einer eigenen Confluence Page dokumentiert, welche direkt unterhalb des Lean Business Case abgelegt wird (siehe Abbildung 1). Diese Confluence Page besitzt eine besondere Bedeutung, insoweit in dieser im Laufe der Entwicklung nach und nach die Validierung der Detailanforderungen dokumentiert wird – und somit letztlich das vollständige Erfüllen der NFR.

Nun haben wir die Voraussetzungen für den Start einer Entwicklung geschaffen, in deren Rahmen die Detailanforderungen zu erfüllen sind.

Gemäss SAFe erfolgt die Dekomposition eines Portfolio Epic in mehreren Stufen. Diese drei Stufen sind wie folgt:

• Das Portfolio Epic: Es beschreibt einen fachlichen oder technischen Scope, welcher dem Kunden einen Wert liefert. Für eine exakte Definition, was ein Portfolio Epic ist, wird hier an die Dokumentation des Scaled Agile Framework (www.scaledagileframework.com) verwiesen.
• Ein Feature: Eine grössere Teilfunktionalität des Portfolio Epic. Um diese zu realisieren, bedarf es gemäss SAFe mehrerer agiler Entwicklungsteam, die kooperativ zusammenarbeiten. SAFe nennt eine Anzahl von Entwicklungsteams, die fachlich eng kooperieren agile Release Train (ART).
• Eine Story: Eine Teilfunktionalität eines Feature, die von einem einzelnen Team realisiert wird.

In unserem Beispiel wird das Portfolio Epic in eine Anzahl an Features zerlegt, ein einzelnes Feature wiederum in eine Anzahl an Stories. Ein ART realisiert ein Feature, ein Team eine Story. Arbeitet ein Unternehmen nach einem anderen skalierenden agilen Framework als nach SAFe, zum Beispiel angelehnt am LeSS, so findet sich eine ähnliche Form der Dekomposition von Fachlichkeit auf definierte Abstraktionsstufen.

Die Implementierung des Konzepts zur Behandlung der NFR nutzt diese Dekomposition wie folgt. Eine Detailanforderung eines NFR wird einem Abstraktionslevel der Dekomposition Epic, Feature bzw. Story zugewiesen. Zum Beispiel:

• Die NFR selbst gelten auf dem obersten Abstraktionslevel des Portfolio Epics. Wir nennen diesen Level willkürlich «Level 1».
• Ein Subset an Detailanforderungen der NFR findet Anwendung auf Feature Ebene. Wir nennen diesen Level willkürlich «Level 2»..
• Ein weiteres Subset an Detailanforderungen der NFR findet Anwendung auf Story Ebene dem «Level 3».
• Jede Detailanforderung eines Level 1 NFR ist eindeutig entweder einem Level 2 oder 3 zugewiesen. Damit ist gesichert, dass ein Level 1 NFR komplett und vollständig abgedeckt ist.

Da Akzeptanzkriterien für die NFR auf Level 1 und ebenfalls für sämtliche abgeleiteten Detailanforderung auf den Leveln 2 und 3 definiert sind, ist auch definiert, welche Validierungen durchzuführen sind und welche Validierungen für einen Audit fähigen Nachweis einer Dokumentation bedürfen.

Die Dekomposition eines Portfolio Epic durchzuführen, ist die Aufgabe der agilen Organisation im ART. In der Arbeit mit dem Tool Jira wird ein Feature ebenfalls als ein Ticket repräsentiert, welches dem Ticket des Portfolio Epic untergeordnet wird. Ein Feature zerfällt wiederum in Stories, welche in Jira als Ticket repräsentiert sind. So entsteht ein hierarchischer Baum aus Tickets (siehe Abbildung 1).

Für das Beispiel des Portfolio Epic «Bereitstellen und Verwalten der Gesundheitsdaten im Kundenbereich» erzeugt ein ART etwa das Feature «Als autorisierter Benutzer von MyUnternehmen.com möchte ich meine Pharma Historie einsehen und verwalten können, so dass ich diese bei zukünftigen Verschreibungen konsultieren und prüfen kann.».

Agile good practices im Umgang mit allgemeingültigen NFR

Nun kommt eine in der agilen Welt oft angewendete good practice zum Umgang mit Qualitätsanforderungen[2] (NFR) zur Anwendung. Arbeitet ein agiles Team mit einem physischen Backlog zum Beispiel auf einem Pinboard, so schreibt es allgemein geltende Qualitätsanforderungen wie Usability, Performance oder Regulatorien auf ein Flip und hängt dieses neben das Backlog. In der Definition of Done (DoD) einer Story steht, dass die Qualitätsanforderungen auf dem Flip zu beachten und zu verifizieren sind. So ist das Team angehalten mit dem Abschluss jeder einzelnen Story einen Blick auf das Flip zu werfen und die im Kontext der Story geltenden Qualitätsanforderungen zu verifizieren.

Diese good practice übertragen wir in die digitale Welt wie folgt: In dem Moment, in dem das Feature erzeugt wird, wird gleichzeitig ein NFR-Ticket erzeugt und mit dem Feature Ticket verlinkt. In dem NFR-Ticket werden sämtliche Detailanforderungen der Level 2 und 3, sowie deren Akzeptanzkriterien abgelegt. Mit Jira kann dieser Schritt das NFR-Ticket zu erstellen automatisiert werden, ebenso das Ablegen der Detailanforderungen der Level 2 und 3, sowie deren Akzeptanzkriterien in diesem Ticket. Das NFR-Ticket in Jira übernimmt die Aufgabe des physischen Flips. Es listet alle Detailanforderungen zu den Level 1 NFR des Epic, die für das Feature und alle Stories unter dem Feature zu beachten und zu erfüllen sind.

Das NFR-Ticket erfüllt zusätzlich den Zweck der Dokumentation. Das Erfüllen spezifischer Detailanforderungen verlangt aus regulatorischen Gründen einen Nachweis der Prüfung, also eine Dokumentation, dass die Anforderung erfüllt und verifiziert wurde. Dieser Nachweis kann der Verweis auf einen durchgeführten Test sein oder ein Artefakt wie zum Beispiel ein Zonen Konzept für eine Infrastruktur.

Ein solcher Nachweis wird in dem NFR-Ticket dokumentiert (siehe Tabelle 1). Verlangt das Verifizieren einer Detailanforderung eine Dokumentation, so erfolgt diese in dem NFR-Ticket bei der entsprechenden Detailanforderung. Dies kann zum Beispiel über einen entsprechenden Link auf einen durchgeführten Test oder ein erstelltes Artefakt wie ein Dokument erfolgen.

Angewendet auf das Beispiel stehen etwa im NFR-Ticket unter anderem

• die Level 2 Detailanforderung zu einem GDPR NFR: «Rollen und Rechte müssen in einem übergreifenden Identity & Access Management Konzept definiert sein» mit den Akzeptanzkriterien: «Das IAM Konzept ist erstellt; Das IAM Konzept ist von HR und Security Office genehmigt»
• die Level 3 Detailanforderung zu einem GDPR NFR: «Zugriffe auf persönliche Daten erfolgen ausschliesslich mit der Identität des Owners der persönlichen Daten» mit dem Akzeptanzkriterium: «Die korrekte Implementierung der Autorisierung des Zugriffs auf persönliche Daten gemäss IAM Konzept ist zu verifizieren und zu dokumentieren».

In der Dekomposition des Portolio Epic «Bereitstellen und Verwalten der Gesundheitsdaten im Kundenbereich» erzeugt ein ART das Feature «Als autorisierter Benutzer von MyUnternehmen.com möchte ich meine Pharma Historie einsehen und verwalten können, so dass ich diese bei zukünftigen Verschreibungen konsultieren und prüfen kann».

In dem Moment, in dem das Feature erzeugt wird, wird das NFR-Ticket erzeugt und mit dem Feature Ticket verlinkt. Das Entwicklungsteam «Arkansas» in dem ART erzeugt zu dem Feature nun die Story «Als autorisierter Benutzer von MyUnternehmen.com möchte ich meine Pharma Historie aus sämtlichen verfügbaren Quellen chronologisch aufbereitet und nach zu definierenden Kriterien gefiltert und sortiert angezeigt bekommen». Die Story wird mit dem Feature als «parent» verlinkt (siehe: Abbildung 2).

Erstellen einer regulatorisch geforderten Dokumentation der Validierung

In der Umsetzung der Story durch das Team dient das NFR-Ticket zum einen als Checkliste, welche Detailanforderungen zu erfüllen sind, zum anderen dient es der Dokumentation des Nachweises, dass die Anforderungen erfüllt sind. In der DoD eines jeden Teams steht, dass die Anforderungen in dem NFR-Ticket zu erfüllen sind und, wenn gefordert, der Nachweis der Erfüllung in dem Ticket zu dokumentieren ist. Ist ein Feature von den Teams vollständig realisiert, so ist in dem NFR-Ticket der geforderte Nachweis der Verifikation der NFR Detailanforderungen dokumentiert.

Der ART und das Team in dem ART werden nun wir folgt and die Implementierung des Feature und der Story herangehen:

• In dem ART werden sich die Teams einig, welches Team für das Erfüllen der Level 2 Detailanforderung «Rollen und Rechte müssen in einem übergreifenden Identity & Access Management Konzept definiert sein» verantwortlich ist. Das Team SicherIstSicher nimmt die Verantwortung und erstellt sich dazu die Story «Um die Sicherheit des Zugriffs auf persönliche Daten in der App MyUnternehmen.com zu sichern, ist für unser Unternehmen ein IAM Konzept für sämtliche Zugriffe auf Daten in der MyUnternehmen.com App zu erstellen; Akzeptanzkriterium: Das IAM Konzept ist von HR und CISO genehmigt».
• Das Team SicherIstSicher erstellt nun zusammen mit HR und CISO das IAM Konzept. Das Ergebnis ist ein Dokument. Das Akzeptanzkriterium ist gesichert, in dem in dem Kopf des Dokuments vermerkt ist, welche Personen in welcher Rolle aus HR und CISO das Dokument genehmigt haben.
• In dem NFR-Ticket des Feature wird bei der Detailanforderung «Rollen und Rechte müssen in einem übergreifenden Identity & Access Management Konzept definiert sein» der Link auf das Dokument hinterlegt. Dieser Link dient im Audit als Nachweis der Erfüllung dieser Anforderung.

Dieses Verfahren unterstützt auch eine inkrementelle Entwicklung nach einem DevOps Ansatz. Die im NFR-Ticket hinterlegte Checkliste zusammen mit der DoD sichern, dass sowohl eine einzelne Story, wie auch ein Feature compliant zu den NFR Anforderungen realisiert wird.

Auf Ebene des Portfolio Epic ist der Nachweis erbracht, dass alle NFR erfüllt sind, wenn sämtliche Features des Portfolio Epic abgeschlossen sind und in den NFR-Tickets der Features die Verifikation der Detailanforderungen bestätigt und dokumentiert ist. Das Erfüllen sämtlicher Detailanforderungen erfüllt somit auch die NFR des Portfolio Epic. Ideal werden dazu sämtliche NFR-Tickets in der Confluence Page der NFR auf Portfolio Ebene referenziert.

Der formale Nachweis der Erfüllung der NFR, zum Beispiel für eine Audit Organisation, ist vorhanden mittels der Confluence Page plus der Dokumentation der Verifizierung der Detailanforderungen in den NFR-Tickets der Features. Eine Audit Organisation ist so in der Lage nachzuprüfen, ob die NFR auf Eben des Portfolio Epic und die entsprechenden Detailanforderung auf Ebene der Features und Stories erfüllt und geprüft wurde.

Dieser Schritt kann auch mit den Mitteln von Jira und Confluence automatisiert werden, in dem aus den entsprechenden NFR-Tickets und der Confluence Page ein PDF Dokument erstellt wird, das als Nachweis in einem entsprechenden Repository abgelegt wird. Die Automatisierung kann noch weiter voran getrieben werden in der Form, dass bei jedem Release einer Deployment Unit der entsprechende Audit Report generiert und verlinkt mit dem versionierten Release in einem Repository abgelegt wird. Dieser Automatisierung könnte zum Beispiel Teil einer DevOps Build Pipeline sein, welche nicht alleine die Software umfasst, sondern zusätzlich die einem Release einer Software zugeordneten Dokumentation.

Anhang: Auszug aus dem Jira NFR-Tickets

Zusammenfassung

Die Blog Serie hat einen konzeptionellen Ansatz vorgestellt, wie in einem skaliert agilem Entwicklungssystem mit übergreifenden, regulatorischen Anforderungen umgegangen werden kann, die einem Audit oder einer Zertifizierung unterliegen.

Dieser Ansatz und beispielhafte Form einer Implementierung ist geeignet für Umgebungen und Industrien, bei denen das einzuhaltende Mass der Regulierung einen gewissen Grad nicht überschreitet. Dies sind zum Beispiel Handel, Versicherungen oder grosse Bereiche in Banken und Transport, ebenso für funktionale Bereiche wie Verwaltung oder Accounting. Nach Einschätzung des Autors ist dies die überwiegende Mehrheit der Entwicklung an Produkten und Services.

Nicht geeignet ist der Ansatz in strikt regulierten Umgebungen wie die Medizintechnik, Aviatik, in denen nicht nur das Produkt nachweisbar und nachvollziehbar validiert sein muss, sondern auch der Herstellungsprozess. Nach Einschätzung des Autors sind hier agile Ansätze einsetzbar, eine inkrementelle Vorgehensweise in schnellen Iterationen ist aufgrund des Aufwandes für Dokumentation und Zertifizierung nicht möglich.

Der Ansatz verlangt als Voraussetzung (siehe Blog 3) eine gewisse agile Reife der Organisation. Er baut auf agilen und modernen Methoden wie dezentrale Verantwortung, DevOps und Testautomatisierung auf. Unternehmen, die in diese agile Reife investieren, profitieren genau mit der Möglichkeit höherwertige Fähigkeiten auf dieser Reife aufzubauen, wie eben der Umgang mit übergreifenden, regulatorischen und nachweispflichtigen Qualitätsanforderungen.

Deutlich ist herauszuheben, dass die erfolgreiche Implementierung dieses dezentralen Ansatzes einer weiteren Dimension bedarf. Damit das Zusammenspiel der dezentralen Organisationsbereiche im Sinne des grossen Ganzen erfolgreich funktioniert, bedarf es eines übergreifenden Verständnisses, es bedarf einer kollektiven Selbstdisziplin, einem Streben nach dem richtigen Mass an Einfachheit und Standardisierung. Eine entsprechende Haltung bei den Mitarbeitenden im Unternehmen entstehen zu lassen ist klar eine Führungsaufgabe. Hier ist nach Auffassung des Autors noch Potential vorhanden.

Cyber Security und Compliance sind mittlerweile als wichtige und dringend zu adressierende Themen in den meisten Geschäftsleitungen angekommen. Typisch ist ein GL-Mitglied verantwortlich diese Themen in den Griff zu bekommen. Noch nicht überall angekommen ist leider, dass Investition in modernes Arbeiten – ich vermeide ganz bewusst die Begriffe «agil» und «lean» an der Stelle – mit aktuellen Technologien in einem dezentralen Ansatz mehr bedarf als eine technische Cloud Transformation oder eine Microservice Architektur. Es bedarf auch einer Veränderung des Verhaltens, der Haltung aller Mitarbeitenden zu den oben genannten Werten. Diese Transformation ist ebenso wichtig, wenn in Unternehmen in Zukunft erfolgreich sein will.

Nun bin ich als Autor etwas vom eigentlichen Thema der Blog Serie abgeschweift. Ich bitte um Entschuldigung. Ich hoffe die Blog Serie konnte Ihnen als Leser:in ein paar Denkanstösse und Impulse mitgeben. Gerne stehe ich auch für einen Erfahrungsaustausch zur Verfügung. Melden Sie sich einfach bei mir. Meine Kontaktdaten finden Sie in LinkedIn oder einfach mittels Dr. Google.

[1] SAFe Template für einen Lean Business Case: https://www.scaledagileframework.com/wp-content/uploads/delightful-downloads/2020/06/Lean-Business-Case-V7.docx

[2] Siehe Artikel «Non-functional Requirements Documentation in Agile Software Development: Challenges and Solution Proposal», Woubshet Behutiye, Pertti Karhapää, Q-Rapids project, which has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement N° 732253.