5. November 2019

Agile. Theorie gegen Praxis.

Agiles Projektmanagement oder kurz „agile“ ist in den letzten Jahren sehr populär geworden. Die Vorgehensweise setzt sich immer mehr gegen etablierte, konservative Projektmanagementmodelle wie das sehr prominente „Wasserfallmodell“ („V-Modell“ u.a.) durch.

Der sicherlich bekannteste Vertreter der agilen Projektmanagementmodelle ist „Scrum“, abgeleitet vom gleichnamigen Begriff aus der Welt des Rugbysports (zu deutsch etwa „Gemenge“). Weitere, etwas weniger bekannte, Vertreter sind „Kanban“, „extreme Programming“ u.v.m.

Prinzipien

Die agilen Projektmanagementmodelle bzw. Entwicklungsmodelle sind sich einander sehr ähnlich, denn sie beruhen alle auf den selben agilen Prinzipien. Diese lassen sich knapp durch höhere Flexibilität, mehr Transparenz und schnellere Bereitstellung von Ergebnissen im Entwicklungsprozess zusammenfassen. All dies wird ermöglicht durch bessere Kommunikation. Kommunikation ist der Dreh- und Angelpunkt hierbei. Etwa 50% der Arbeitszeit in Softwareentwicklungsprojekten wird aufgewendet für Kommunikation. Hier steckt das größte Risiko, aber auch das größte Potenzial!

Intuitiv lässt sich die Liste der agilen Prinzipien (siehe auch „agiles Manifest“) sehr gut nachvollziehen und kaum jemand, der einige Jahre Berufserfahrung mit Wasserfall und Co. gesammelt hat, würde diesen widersprechen wollen. Die Vorgaben sind in der Theorie klar formuliert. Doch lassen sich diese „modernen“ Vorgehensmodelle auch ohne weiteres in die Praxis umsetzen? Die Modelle gibt es nicht erst seit gestern, dennoch setzen sie sich in der Praxis mitunter nur sehr langsam durch und dafür gibt es dann auch gute Gründe. Also woran hakt es in der Praxis?

Zunächst sollten alle Teammitglieder und bestenfalls alle Stakeholder, verstanden haben, was agil bedeutet und wie das gewählte agile Modell nun umzusetzen ist. Glücklicherweise sind die Grundstrukturen der agilen Modelle schnell erklärt und festigen sich auch schnell, nach einigen Anwendungen. Dennoch sollte man sich von diesen „einfachen“, teilweise philosophisch klingenden Techniken und Ritualen nicht täuschen lassen: Es ist essentiell diese auch kontinuierlich anzuwenden um nicht in „alte“ Verhaltensmuster aus der Wasserfallzeit zurückzufallen.

Ein Trugschluss ist, dass in der agilen Welt nicht dokumentiert wird. Ein gewisses Maß an Dokumentation ist immer notwendig - wie viel genau, das lehrt die Erfahrung des Teams. Wenn nun die Dokumentation schleichend, von Zyklus zu Zyklus (siehe z.B. Sprints in Scrum) immer weiter zurückgefahren wird, findet man sich irgendwann vor Problemsituationen, in denen man sich die wohldefinierten Dokumente des Wasserfalls zurückwünschen könnte.

Unterstützend wirken bei der Dokumentation und Aufgabenverwaltung Tools wie Tasktracker/ Bugtracker und Wikis. Darüber hinaus gibt es eine Vielzahl an weiteren Tools, die jeden einzelnen Prozessschritt der Projektarbeit unterstützen kann. Die Gefahr liegt hierbei eher darin, sich nicht zu viele neue Tools (mit exotischen Namen) auf einmal vorzunehmen, denn auch die Einarbeitung in ein Tool erfordert die Zeit aller Teammitglieder. Bei aller Tool-Pflege soll am Ende ja schließlich noch Software entwickelt werden. =)

Team und Arbeitsumgebung

Eine der wichtigsten Forderungen von agile lautet „Enable the team!“. Es geht um Rollen & Fähigkeiten, Befugnisse und die Arbeitsumgebung. Das Team muss möglichst autonom handeln können. Dazu müssen alle nötigen Rollen im Team vertreten sein: Entwickler, Tester, Vertreter für die Anforderungen und weitere (in Scrum beispielsweise noch ein Scrum Master zur ständigen Optimierung des agilen Prozesses). Unabhängig von den Rollen sollte das Team alle Fähigkeiten inne haben, die es benötigt um ein Stück Software bis in die Produktion zu bringen. Bestenfalls werden die Fähigkeiten jeweils durch mehr als eine Person abgedeckt, um Belastungsspitzen und Ausfallzeiten zu kompensieren oder um einfach mal eine zweite „Fachkundige Meinung“ einholen zu können.

Das Team sollte auf möglichst wenige Rollen/Fähigkeiten bzw. daran hängende Prozesse von außerhalb angewiesen sein, denn jede Schnittstelle nach „außen“ ist im Zweifelsfall eine Schnittstelle zur nicht-agilen Welt, bei der man direkt mit starren Servicezeiten, Vorlaufzeiten, Dokumenten, Fristen, Unterschriften etc. zu kämpfen hat.

Zuletzt sollten die Rahmenbedingungen für die Kommunikation innerhalb des Teams möglichst gut ausgestaltet sein. Sicherlich können agile Teams auch über den Globus verteilt funktionieren. Aber zunächst unscheinbare Erschwernisse wie fehlende physische Nähe, unterschiedliche Zeitzonen, schlechte Telefonverbindungen und kulturelle Differenzen stellen sich doch meist als großer Nachteil heraus. Im Endeffekt wird die ein oder andere Frage nie gestellt, der ein oder andere Kommentar ignoriert, ein wohlgemeinter Tipp falsch verstanden oder eine Emotion unterdrückt. All das fällt in die Kategorie nonverbale Kommunikation. Laut Wissenschaft beträgt die Wirkung dieser Art von Kommunikation bei einem Gespräch 55% (38% Stimmlage, 7% Inhalt) und eben dieser Teil geht fatalerweise verloren.

Zuletzt ist eine Einbindung des Kunden essentiell. Zwar gibt es oft einen Vertreter des Auftraggebers bzw. für die Anforderungen im Team. Diese Personengruppe muss aber regelmäßig in die Projektarbeit eingebunden werden, da sie letztlich das (End-) Produkt nutzt bzw. abnimmt. Vor allem das Feedback der zukünftigen Nutzer ist unabdingbar. Ein klassisches Phänomen in der Softwareentwicklung ist, dass die Nutzer immer „eigene Wege finden“ wie sie ein Produkt nutzen. Dagegen hilft kein wochenlanger Designprozess sondern schlicht das regelmäßige Einholen von Nutzerfeedback. Die Software wird ja schließlich für die Nutzer entwickelt. Außerdem ist nur ein zufriedener Kunde ein Kunde, der wiederkommt.

Erfahrungsgemäß ist das Problem des fehlenden Kundenfeedbacks bei agilen Pilotprojekten meist auf die mangelnde Bereitschaft des Kunden zurückzuführen, sich regelmäßig mit dem Produkt auseinanderzusetzen. Dies erfordert nämlich während des gesamten Projektverlaufs einen oder mehrere Personen auf Kundenseite, die sich stetig mit der Produktentstehung beschäftigen. Es sollten die Optionen, sowie die Vor- und Nachteile diskutiert werden, um den späteren Nutzen für sich zu maximieren. Agil bedeutet nicht, dass man keine Entscheidungen mehr treffen muss - sie sind lediglich verteilt über die Zeit und nicht gehäuft zu Beginn, wie bei klassischen Vorgehensmodellen.

Schrittweise Einführung

Insgesamt setzen sich agile Modelle langsam aber stetig durch. Oftmals wird "agile" im Unternehmen noch als „agile in a box“ angewandt. Das bedeutet, man fängt eben mal damit an einzelne Pilotprojekte umzustellen. Da die gesamte Umwelt des Projekts aber noch nach dem Wasserfall funktioniert, entstehen ständig Reibungen an den Schnittstellen des Projekts nach außen, z.B. bei Releases. Ein motiviertes Team kann innerhalb seines Projekts noch so vorbildlich agil handeln - wenn das übergeordnete Releasemanagement diesen Wandel nicht mit begleitet, sondern strikte Releasetermine vorgibt, wird Agilität unterdrückt. In gleicher Weise gilt das für Budgets, Staffing und Zeitplanungen.

Ein ganzes Unternehmen auf einen Schlag auf agil umzustellen mag unmöglich sein, aber jede neue Bewegung braucht ihre Zeit um Fahrt aufzunehmen. Mancher Manager könnte zum fatalen Trugschluss gelangen, dass „agil bei uns eben nicht funktioniert“. Hier müssen Kompromisse gefunden werden, denn „agile“ selbst kann eben auch nur schrittweise eingeführt werden.

Jede eingeführte agile Technik, jedes Ritual, jeder agile Prozess hilft dabei!

28. März 2019

Geldwäsche mit Data Mining erkennen

Geldwäsche zielt darauf ab, die Herkunft von illegal erworbenen Geldern zu verschleiern und sie in den legalen Wirtschaftskreislauf einzuschleusen. Banken und Finanzdienstleistungsunternehmen im Allgemeinen sind durch das Geldwäschegesetz dazu verpflichtet, verdächtige Aktivitäten auf ihren Konten zu identifizieren und zu melden. Dazu werden alle Transaktionen auf diesen Konten möglichst automatisiert überwacht. Die hierfür eingesetzten Automatismen verwenden in der Regel statische Regelwerke oder Modelle. Diese erkennen Geldwäschefälle anhand von festgelegten Kriterien (u.a. bestimmte Verhaltensmuster oder Herkunftsländer, die bekanntermaßen auf Geldwäsche hindeuten).

Deutlich höhere Automatisierung

Diese Kriterien werden häufig noch manuell durch menschliche Experten erarbeitet und basieren auf Erfahrungswerten zu bekannten Geldwäschefällen. Eine gängige Methode ist eine manuelle Einteilung von Konten anhand ihrer Metainformationen (wie z.B. das Transaktionsland oder die Geschäftsbranche) in Risikoklassen (z.B. in ein geringes, mittleres oder hohes Risiko). Auf Basis dieser einzelnen Risikoklassen wird dann eine Gesamtbewertung (z.B. eine Klassifizierung als (kein) potenzieller Geldwäschefall) für die betrachteten Transaktionen durchgeführt. Das Geldwäscheverhalten verändert sich allerdings ständig. So passen Geldwäscher ihre Transaktionen ständig an, um eine Entdeckung durch Experten bzw. Automatismen zu vermeiden. Die Erarbeitung der Kriterien zur Geldwäscheerkennung ist daher ein wiederkehrender, oft manueller und sehr mühsamer Prozess.

Eine Alternative zur aufwändigen manuellen Analyse bietet Data Mining. Dieses stellt Werkzeuge (u.a. Verfahren des maschinellen Lernens) zur Verfügung, um Geldwäscheexperten in ihrer Tätigkeit zu unterstützen oder ihnen im Idealfall Arbeiten (fast) vollständig abzunehmen. Die oben genannte Einteilung von Konten (oder anderer Geschäftsobjekte, wie z.B. Kunden oder Länder) kann durch Methoden des Data Minings realisiert werden. Ein einfacher Ansatz hierfür wäre z.B. die Verwendung von (unüberwachten) Clustering-Methoden, die Objekte anhand ihrer Ähnlichkeit in Cluster gruppiert. Diese Gruppierung kann dann als Ausgangspunkt für eine Einteilung in Risikogruppen verwendet werden. Auch die zuvor erwähnte Klassifizierung von Transaktionen als (keine) Geldwäschefälle kann durch überwachte Lernverfahren des Data Minings übernommen und in ihrer Performanz verbessert werden. Diese Aufgabenstellung legt die Verwendung von Klassifikationslernern nahe, die die bekannten Informationen über Geldwäschefälle (d.h. sowohl positive als auch negative Beispiele für Geldwäschetransaktionen inklusive zugehöriger Informationen, wie z.B. Kunden- oder Länderstammdaten) generalisieren, um Klassifikationsmodelle zu erhalten. Mit Hilfe dieser Modelle können anschließend neue Transaktionen automatisch bewertet und ggf. als Geldwäschefall identifiziert werden. Auf diese Weise nimmt Data Mining den Geldwäscheexperten die Arbeit ab, Vorhersagemodelle manuell erstellen zu müssen.

Qualitative Verbesserungen

Zur Einteilung in Risikoklassen und Erstellung von Vorhersagemodellen stehen diverse Verfahren des Data Minings zur Verfügung, die mit ihren unterschiedlichen Eigenschaften auf die gegebenen Anforderungen abgestimmt werden können. Zum Beispiel können mit den entsprechenden Verfahren interpretierbare Klassifikationsmodelle, wie z.B. Entscheidungsbäume oder Regellerner, erstellt werden. Interpretierbare Modelle bzw. deren Entscheidungen können durch menschliche Experten analysiert bzw. verifiziert werden. Im Allgemeinen kann auf diese Weise die Akzeptanz des erstellten Modells bzw. die Bereitschaft dieses produktiv einzusetzen erhöht werden. Weiterhin können die Lernphasen von Data Mining Verfahren (entweder eine Neuerstellung oder im Falle von inkrementellen Lernern eine Aktualisierung des Modells) häufiger stattfinden als dies manuell möglich ist (z.B. täglich oder nach dem Bekanntwerden eines oder mehrerer Geldwäschefälle). Die so erhaltenen neuen oder aktualisierten Modelle können anschließend, ggf. nach einer Prüfung durch menschliche Experten, produktiv eingesetzt werden, um für die aktuellen Geldwäschetrends gewappnet zu sein. Dieser Einsatz von maschinellem Lernen kann somit völlig neue Erkenntnisse generieren. Es werden Zusammenhänge erkannt (sowohl für die Risikogruppierung als auch in den Vorhersagemodellen), die den menschlichen Experten im Vorfeld gar nicht bewußt waren.

Zusammengefasst kann der Einsatz von Data Mining die menschlichen (Geldwäsche-)Experten wesentlich in ihrer Arbeit unterstützen. Erstens werden kostbare menschliche Ressourcen frei für wichtigere und ggf. nicht automatisierbare Tätigkeiten, da Data Mining zeitraubende manuelle Tätigkeiten ggf. mit einer höheren Güte übernehmen kann. Zweitens können die verwendeten Modelle zur Geldwäscheerkennung häufiger neu erstellt oder aktualisiert werden, da dies automatisch ablaufen kann und ggf. nur eine Sichtung der resultierenden Modelle notwendig ist. Drittens können die Modelle auf Grund ihrer alternativen Erstellung auch neue Einblicke in das Geldwäscheverhalten bieten.

27. März 2019

DevOps – Modeerscheinung oder echter Mehrwert

Die IT ist seit jeher ständigen Veränderungen unterworfen. Anforderungen von Kunden und der Wunsch nach schneller Umsetzung und Einführung von neuen „Features“ wachsen von Tag zu Tag. Diese Wünsche der Kunden stehen in einem Gegensatz zu den klassischen Ansätzen der IT, in denen neue Releases teils monate- oder gar jahrelang im Voraus geplant werden. Zum Teil werden damit auch Anforderungen umgesetzt, welche bei Einführung schon wieder veraltet sind. Die IT ihrerseits versucht auf diese Herausforderung mit neuen Entwicklungsmethoden zu reagieren. So wird bereits in vielen Projekten der klassische Ansatz des Wasserfallmodells durch den Ansatz der agilen Softwareentwicklung ersetzt. Ziel dabei ist es, eine Software mit geringem bürokratischen Aufwand schnell und qualitativ hochwertig zu erstellen und stetig weiter zu entwickeln. Diese Vorgehensweise führt allerdings zwangsläufig zur nächsten Herausforderung, diese Software jederzeit fehlerfrei bereitstellen zu können. DevOps (Development & Operations) greift genau diesen Punkt auf und adressiert die Verzahnung zwischen agiler Entwicklung und zeitnaher Bereitstellung der Software.

DevOps - was steckt genau hinter dem Begriff?

Mittlerweile gibt es verschiedene Definitionen, die den Begriff DevOps beschreiben. Gemein ist aber allen das gemeinsame Ziel: Eine schnelle und stabile Bereitstellung von qualitativ hochwertiger Software. Hierzu möchte DevOps für eine effizientere und effektivere Zusammenarbeit der Bereiche „Development“, „IT Operations“ und „Qualitätssicherung“ beitragen. Zum Einsatz kommen dabei die unterschiedlichsten Tools, welche diesen neuen Ansatz unterstützen sollen. Man könnte nun meinen, durch den einfachen Einsatz einiger neuer Tools im Bereich der Codeverwaltung, des Test- und Change-Managements und des Monitorings wäre eine Einführung von DevOps zwangsläufig erfolgreich. Eine solche Interpretation wäre aber bereits der Beginn des Scheiterns einer DevOps – Einführung. Sicherlich haben all diese Werkzeuge ihre Berechtigung, jedoch sollten sie nur als Mittel zum Zweck angesehen werden. Eine Diskussion über eine Einführung sollte sich niemals nur auf den technologischen Teil beschränken. Denn einem Mitarbeiter ist es nur schwer zu erklären, warum sich Technologien, die jahrelang erfolgreich benutzt wurden, nun plötzlich durch einen neuen „unerprobten“ und ähnlich aufwendigen Prozess ersetzt werden, wenn man ihm das Ziel im Ganzen nicht vor Augen führen kann.

Einführung im Unternehmen

Eine erfolgreiche DevOps – Einführung ist folglich gebunden an das Verständnis der Mitarbeiter für den dahinter stehenden Mehrwert. Man könnte gar sagen, es benötigt einen Kulturwandel innerhalb eines Unternehmens. Denn seit jeher stehen die Ziele von Entwicklern und IT Operations in einem Gegensatz. Während Entwickler bestrebt sind durch häufige Releases neue Features möglichst schnell verfügbar zu machen, steht für Operations ein stabiles System im Vordergrund. Neue Funktionen bringen aus Sicht von Operations zunächst nur ein erhöhtes Ausfallrisiko mit sich. Wichtig ist es also diese individuellen Ziele zu einem gemeinsamen Ziel zu koordinieren. Es erfordert Verständnis für einander und echtes Team-Work zwischen Entwicklung und Operations.

Es wird sich zeigen, dass nicht alle Vorteile direkt nach einer DevOps-Einführung zum Tragen kommen. Oftmals benötigen die Teams Zeit sich von alten Gewohnheiten zu lösen und sich an die neuen Prozesse zu gewöhnen. Vermehrt wird man feststellen, dass bei der Einführung nicht alles perfekt läuft und es sowohl gedanklich als auch technologisch Verbesserungspotential gibt. Durch kontinuierliche und schrittweise Verbesserungen lässt sich DevOps aber langfristig zum großen Vorteil im Unternehmen nutzen.

10. September 2018

„Data Warehouse“ ist out. Brauchen wir jetzt einen „Data Lake“?

 

Die technisch gereifte Möglichkeit, Unmengen von Daten im Unternehmen speichern und verarbeiten zu können, hat den Fokus auf das reine Sammeln von Daten verschoben. Auch die Möglichkeit, völlig unterschiedliche Typen von Daten (strukturiert und unstrukturiert) ablegen zu können und die gelebte Praxis, geschäftliche Analysen dieser Daten auf „später“ zu verschieben, hat zu dieser Entwicklung beigetragen. Wir sammeln also auf Teufel komm raus alles, was irgendwie von Nutzen sein könnte, legen es in einem „Data Lake“ ab und hoffen darauf, dass eines Tages daraus ein Mehrwert für das Unternehmen entsteht.

So sehr es wünschenswert ist diese Data Lakes zu etablieren, um potentiell wertvolle Informationen zu sichern, so sehr ist es aber auch notwendig, den Fokus wieder deutlicher auf die Analyse dieser Daten zu lenken. Erst diese Analysen erlauben es, geschäftliche Erkenntnisse für das Unternehmen zu gewinnen und damit Mehrwert zu schaffen. „Big Data“ ist insofern auch nur ein weiteres Buzzword um zu signalisieren, dass wir dies nun auch aus sehr großen, ggf. unstrukturierten und laufend aktualisierten Datenmengen können.

Analyse selbst soll von den vermeintlich überall verfügbaren Data-Science-Fachkräften gemacht werden. Diese tatsächlich sehr raren, hochspezialisierten Daten-Spezialisten sollen in der Lage sein, aus den Unmengen an ungeschliffenen Rohmaterial von Daten wertvolle Erkenntnisse zu schürfen. Sie schaffen das allerdings nur, wenn sie unstrukturierten Daten eine Struktur geben, wenn also die Daten aus ihrer Rohform in eine für intelligente Verarbeitung und Geschäftsanalyse verarbeitbare Form transformiert werden. Das ist ein hochkomplexer und sehr aufwändiger Vorgang, der oftmals mehr Kapazitäten bindet, als die eigentliche Analyse selbst. Wir haben sogar wieder ein Buzzword dafür etabliert: „Schema-on-read“, und viele halten es plötzlich für den Königsweg. Tatsächlich ist es aber nur eine sinnvolle Erweiterung der lange bekannten Architektur, die jetzt als das „klassische“ Data Warehouse bezeichnet wird. Eigentlich hat man nur erkannt, dass es sinnvoll ist, entsprechend ausgebildeten Daten-Spezialisten auch Zugriff auf Rohdaten zu geben. Der vermeintlich alte Ansatz „Schema-on-write“ hat aber unverändert seine Berechtigung und ist, vielmehr noch, im Kern unverzichtbar. Einmal gewonnene Erkenntnisse, geschäftliche Grundstrukturen und Zusammenhänge sollten von allen Anwendern im Unternehmen einfach nutzbar sein. Das erfordert ein Datenmodell, welches diese Zusammenhänge transparent macht. Es ist schlichtweg ineffizient die Schaffung dieser Grundstrukturen immer wieder aufs Neue, und damit hochredundant, jedem Data Scientist oder Analysten als notwendige Datenvorbereitung aufzuerlegen.

Eine effiziente und wirklich Mehrwert schaffende Informationsinfrastruktur berücksichtigt das alles und sieht hinter den Buzzwords Data Lake, Big Data etc. das, was sie sind: Sinnvolle Erweiterungen des „klassischen“ Data Warehouse um neue Arten der Datennutzung und Datenspeicherung, ergänzt um weitere Skalierungseffekte durch neue Arten der Datenverarbeitung. Wenn wir so wollen: Lasst uns das Data Warehouse weiterentwickeln und alles, was Data Lake, Big Data und Co. an neuen Möglichkeiten bringen für eine gesamthaft effiziente Informationsinfrastruktur im Unternehmen nutzen. Man könnte dafür natürlich auch wieder ein neues Buzzword erfinden und dieses Kunstwerk Information Bridge nennen 😉

© 2019 | Information Bridge, Gesellschaft für Informationsanalyse mbH | Impressum