Beiträge

The Open Group Architecture Framework (TOGAF): To go... für Daten

TOGAF – To go… für Daten

The Open Group Architecture Framework (TOGAF)

 

In einer Zeit in der es gar nicht neu und hip genug zugehen kann möchte ich an dieser Stelle eine Lanze für ein Framework brechen, dass, bei aller Liebe zur Agilität, seit fast 25 Jahren den Enterprise-Architekten die Möglichkeit gibt Unternehmensstrukturen und daraus resultierende IT-Umsetzungen zu planen, umzusetzen und zu warten: The Open Group Architecture Framework (TOGAF). Wobei der Aspekt der Wartung einer der grössten Herausforderungen bei diesem Unterfangen ist. Das erfordert zum einen eine permanente Überprüfung der Konsistenz des involvierten Unternehmensausschnitts und zum anderen die Disziplin, die zugrunde liegende Dokumentation aktuell zu halten und vor allem so didaktisch aufzubereiten, dass auch jeder andere Leser versteht, was man geschrieben hat.

 

Nach weit mehr als zwei Dekaden Beratung im Qualitäts- und Test-Management lautet mein Credo:

„Alles was ich schreibe, schreibe ich für andere und das muss verständlich und lesbar sein. Dazu zählt auch didaktische Redundanz“.

Vergleicht man dieses Framework mit anderen Frameworks, so wird man feststellen, dass eine nicht unerhebliche Anzahl von Frameworks lediglich die Lieferobjekte aufzählen, die benötigt werden, um verschiedene Aspekte der Unternehmensarchitektur zu beschreiben. Hier sagt TOGAF nicht nur was beschrieben werden sollte, sondern geht mit der Achitecture Development Method einen Schritt weiter und schlägt einen methodischen Ansatz zur Umsetzung vor, der sicherlich entsprechend dem jeweiligen Unternehmen angepasst werden sollte.

 

Gerade in Bezug auf die wachsende Internationalisierung der Projekte ist es wichtig, dass verteilte Teams nicht nur hinsichtlich der technischen Konsistenz von Datenmodellen ein fundiertes Wissen haben, sondern auch die Validität von Daten im Griff haben. Nehmen wir das Beispiel synthetischer Daten. Hier reicht es nicht aus syntaktisch korrekten Daten zu produzieren. Diese Daten müssen auch entsprechend dem jeweils übergeordneten Businessmodell entsprechen.

 

The Open Group Architecture Framework (TOGAF): To go... für Daten

 

Hierbei macht es Sinn ein zentralisiertes Testdaten-Management einzuführen und die Generierung der Daten in Abstimmung mit den jeweiligen Fachbereichen und den technischen Teams so zu koordinieren, dass die Fachbereiche sinnvoll generierte Daten sehen und die technischen Teams ein tieferes Verständnis bezüglich der Verwendung dieser Daten während der Entwicklungsphase bekommen. Synthetische Daten werden heutzutage nicht nur für Regressionstests verwendet, sondern auch von externen Entwicklungsteams, die aus Gründen von regulatorischen Vorgaben keine echten Daten verwenden dürfen.

 

Hat man zum Beispiel Entwicklungsteams im Ausland stellt die Bereitstellung geeigneter Daten eine nicht unerhebliche Herausforderung dar. Die Teams müssen die Business-seitige Verwendung der synthetischen Daten kennen und verstehen. Darüber hinaus muss auch das Verständnis da sein welche Kombinationen von Daten sinnvoll und welche technisch möglich aber aus Sicht der jeweiligen Geschäftsprozess nicht vorkommen oder sich sogar widersprechen.

 

Mit Unterstützung der Applikations- und Business-Architektur gelangt man dann zu einem weiteren Aspekt warum TOGAF ein geeignetes Mittel zur Beschreibung der Unternehmensarchitektur ist: Migration.

 

Migration als Teil eines unternehmensorientierten Wartungsprozesses ist eines der herausforderndsten Unterfangen um Geschäftsprozesse und ihre IT in Teilen oder als Ganzes zu transformieren. The Open Group Architecture Framework (TOGAF) kann dabei helfen Geschäftsprozesse und IT während und nach der Migration konsistent zu halten und unnötigen Ballast in Form von nicht mehr benötigten Tabellen, oder sogar ganze fachliche Subdomains, so herauszutrennen, dass die Migration auf sicherem Fundament steht und die damit verbundene Wartung des Unternehmensmodells stabil beendet wird.

 

Das hier angeschnittene Thema „TOGAF als mögliches Kommunikations- und Verständnismodell für dezentrale Teams“ und als Basis zur Herleitung von synthetischen Daten und Validierungsmodell im Bereich der Migration sind nur einige Beispiel wie man Quick Wins produzieren könnte. Wer mehr zur Anwendung von The Open Group Architecture Framework (TOGAF) wissen möchte sollte unseren Spezialisten Felix Isensee kontaktieren.

 

Kontaktinformationen

 

Consultant: Harald Schmidt
E-Mail: harald.schmidt@spf-consulting.ch

 

Harald Schmidt

 

Consultant: Felix Isensee
E-Mail: felix.isensee@spf-consulting.ch

Felix Isensee

SPF Consulting AG - Insights - Wie man erfolgreich KI-Systeme validiert

Wie validiert man erfolgreich KI-Systeme? Eine Q-Perspektive.

Traditionellerweise werden Software-Systeme nach Abschluss der Entwicklung in die Test- und Abnahmephase überführt, um dort entsprechend ihren Anforderungen verifiziert zu werden. Die Erwartungshaltung ist in jeder Phase der Software-Entwicklung deterministisch und eindeutig.

Diese strikte Erwartungshaltung gilt für Machine Learning (ML)-Systeme nicht. Die Erwartungshaltung gegenüber dem ML-System stellt keinen exakten Wert dar, sondern fordert die Einhaltung eines Wertebereichs. Analytische Systeme zur Mustererkennung arbeiten immer mit einer Wahrscheinlichkeit, die eine Aussage bezüglich der Treffergenauigkeit macht. Dies gilt auch für Prognosesysteme. Der Erfolg von ML-Systemen stützt sich auf die Verwendung von historischen Daten und der damit verbundenen Adaption der Modellparameter des ML-Systems. Die Programmierung solcher Systeme beschränkt sich zumeist auf die Integration von umliegenden Systemen via Schnittstellen. Die Entwicklung wird durch Parametrierung ersetzt und der klassische Software-Entwicklungszyklus durch einen Continuous Adaption / Continuous Integration – Approach:

Select: In der Realität wird in den meisten Fällen auf etablierte Open Source – Bibliotheken, wie zum Beispiel TensorFlow, Scikit-lean, oder Apache Spark zurückgegriffen. Was hier fairerweise nicht unterschätzt werden darf ist die Komplexität der zu verwendeten Schnittstellen und die notwendige Infrastruktur, die für den Einsatz benötigt wird. Anbieter, wie zum Beispiel Microsoft mit Azure bieten hier Komplettlösungen an.

Train: Nach der Selektion eines geeigneten ML-Modells wird dieses unter Laborbedingungen via Trainingsdaten soweit trainiert, dass es den Erwartungshaltungen der Tester genügt. In diesem Qualitätssicherungsschritt, und das ist der Unterscheid zum herkömmlichen Testen, wendet sich der Tester vom klassischen rein deterministischen Ansatz ab und formuliert seine Erwartungshaltung als Ergebnisbereiche, nicht als Ergebniswerte. Die Verifikation tritt in den Hintergrund und die Validierung gewinnt an Bedeutung. Ein deterministisches Verhalten würde an dieser Stelle nicht zielführend sein und ein Indiz für overfitting sein was einem auswendig lernen gleich kommt. Damit hätte das Modell seine gewünschte Flexibilität verloren.

Check: Im nächsten Schritt wird ein Robustness-Test durchgeführt. Hierbei wird ein Validation Set von Eingangsdaten genommen und evaluiert, wie sich das parametrierte ML-System verhält. Der Schwerpunkt liegt auf Ausreisserszenarien: Wie verhält sich die Erkennung von Nummernschildern im Winter, wenn ein Teil des Autonummernschilds vom Schnee bedeckt ist? Gibt es wirklich eine Krise, wenn die Pizza-Lieferanten in der Nähe des Regierungsgebäudes Hochkonjunktur haben? Wie gut kann das ML-System Kauf- oder Verkaufsempfehlungen nach einem Börsen-Crash prognostizieren? Das Ergebnis dieses Tests stellt ein Quality Gate dar und bewertet die Aussagekraft des Systems unter Extrembedingungen.

Integrate: Im dritten Schritt, der Inbetriebnahme in die Produktionsumgebung, wird das ML-System nicht gänzlich den Anwendern überlassen, sondern durch ein geeignetes Monitoring aktiv unterstützt. Das Monitoring sammelt Kombinationen von Eingangsdaten und Ergebnissen die ausserhalb eines akzeptablen Ergebnisbereichs liegen.

Adopt: Die aus dem Monitoring gewonnen Erkenntnissen und den zugrundeliegenden Daten werden von Domain-Spezialisten ausgewertet und gegebenenfalls zur Adaption der ML-Modellparameter verwendet. Die Adaption der Modellparameter geschieht durch direkte Justierung von Schwellenwerten oder einer erneuten Lern-Session (Phase Train).

Die hier vorgestellten Phasen, wobei Train und Adopt als identische Phase mit unterschiedlichen Voraussetzungen angesehen werden kann, entsprechen einem Entwicklungs- und Integrationszyklus (Select, Train, Check, Integrate) und einer Bugfix-Auslieferung (Adopt) im klassischen Sinne. Der Unterschied hierbei ist, dass kein Code, sondern Parameter-Sets des ML-Modells ausgeliefert werden. Aus Sicht der Qualitätssicherung bestimmen Validierungen und Wahrscheinlichkeitsräume die Bedeutung und ersetzen deterministische Erwartungshaltungen.

In einem dynamischen System gibt es keine statische Lösung

In diesem Artikel wurde bewusst auf eigentlich notwendige mathematische Verweise aus der Statistik, der Algebra und natürlich der Wahrscheinlichkeitstheorie verzichtet. Dieses mathematische Fundament ist essentiell, um die Qualität solcher Modelle bewerten zu können. In weiteren Artikeln werde ich näher darauf eingehen.

Kontaktinformationen

Ansprechpartner: Harald Schmidt
E-Mail: harald.schmidt@spf-consulting.ch

Harald Schmidt

Läuft, …dank BCM

In Zeiten von Cyber-Attacken, Lieferengpässen und zunehmendem Verlust von Wissen durch den Weggang von Mitarbeitern entlang der Wertschöpfungskette eines Unternehmens wird das Thema Business Continuity Management, kurz BCM, zu einem immer grösser werdenden Erfolgsfaktor in der Geschäftswelt. In diesen Tagen fehlen Computerteile von zuliefernden Unternehmen genauso wie notwendiges Know-how, um den Status Quo im Wettbewerb zumindest zu halten. Der Ausbau ist ein anderes Thema. Einer meiner grössten Management-Vorbilder sagte einmal “Alles Projektmanagement ist Risikomanagement”. Das ist in diesen unruhigen Zeiten wahrer den je. Das Entgegenwirken von Risiken beschränkt sich nicht mehr nur auf die Bereitstellung eines neuen Servers oder PCs, wenn diese ausfallen. Vielmehr wird die gesamte IT-Organisation und ihre Prozesse, sofern sie mittel- oder unmittelbar an der Wertschöpfung des Unternehmens beteiligt ist, hinsichtlich ihrer Ausfallsicherheit kritisch betrachtet. Das es nicht erst eine Pandemie braucht, um Unternehmen auf dieses Thema zu sensibilisieren, sollte klar sein. Auch ohne Pandemie müssen Unternehmen regelmässig Risikoanalysen und -bewertungen durchführen, um nicht durch eventuell vorhersehbare Krisen überrascht zu werden und dann im schlimmsten Fall den Geschäftsbetrieb einstellen zu müssen oder sogar in Regress genommen zu werden. Wie eingangs erwähnt sind auch Cyber-Attacken und Ransomware nur eines von vielen Risiken, die nach geeigneten Angriffspunkten Ausschau halten.

SPF Consulting AG - Insights -BCM

Die ISO 22301 gibt eine geeignete Hilfestellung in Form eines Frameworks entlang der Wertschöpfungskette eine Ausfallsicherheit zu planen, geeignete Massnahmen zu etablieren, regelmässig zu validieren, zu überwachen und kontinuierlich zu verbessern. Wurden diese Massnahmen definiert und sind integraler Bestandteil des unternehmensweiten Risiko-Managements spricht man von einem Business Continuity Management System, oder kurz BCMS. Nimmt man zum Beispiel die IT-Organisation, so ist der erste Gedanke die Ausfallsicherheit der Systeme. Was auch legitim und sinnvoll ist. Ein zweites Data Center was gespiegelt wird ist hier eine sinnvolle Lösung. Was aber wenn Daten mit krimineller Energie manipuliert oder sogar gelöscht wurden? Dann ist das Konzept der permanenten Spiegelung zu hinterfragen. Das sind aber dann Details die individuell geklärt werden sollten. Die ISO 22301 betrachtet die Themen Planung, Unterstützung, operative Umsetzung, Performance-Messungen und -Verbesserungen. Unterstützt wird diese Norm durch diverse assoziierte Normen, die beim Aufbau eines BCMS unterstützen. Die ISO 22313 gibt eine Hilfestellung wie die ISO 22301 anzusetzen ist. Die ISO 22317 liefert ein Muster wie eine Impact-Analyse durchzuführen ist. Wichtig wäre an dieser Stelle auch noch die ISO 22318 zu erwähnen, die sich mit der Ausfallsicherheit von Lieferketten und deren Zulieferer beschäftigt.

 

SPF Consulting AG - Insights -BCM

Bei allen Normen und Frameworks, die man hier einsetzen kann, steht und fällt es mit der Akzeptanz der involvierten und damit verantwortlichen Mitarbeitern. Die Prozesse zu definieren und später auch regelmässig anhand von simulierten Ausfällen zu validieren steht auf einem anderen Blatt. Deshalb ist unsere Empfehlung anhand langjähriger Erfahrung in diesem Bereich, dass sämtliche Prozesse und Arbeitsanweisungen für den Notfall zu den Dokumenten des BCM-Owners gemacht werden sollten. Der Fachverantwortliche, der für ein System oder eine Lieferverpflichtung zusammen mit seinem Ansprechpartner auf der Supplier-Seite verantwortlich ist, muss sich in diesen Dokumenten wiederfinden. Er muss sogar das Gefühl haben, dass er das geschrieben hat. Nur so wird im Notfall ein maximales Engagement erzielt und die Wahrscheinlichkeit, dass es einen Unterbruch in der Wertschöpfungskette gibt maximal minimiert. Denn auch in Bereich BCM gilt: Diejenigen, die die Notfallpläne definieren, sind selten diejenigen die sie später ausführen müssen. Gegenseitige Akzeptanz und Unterstützung ist somit erfolgsentscheidend.

 

Fragen? Kontaktieren Sie uns!

Ihr Ansprechpartner: Harald Schmidt
E-Mail: harald.schmidt@spf-consulting.ch

Harald Schmidt