Software am Stand der Technik

In den letzten Blogposts wurden die Vor- und Nachteile einer Microservice-Architektur  herausgearbeitet und einander gegenübergestellt . Dabei hat sich herausgestellt, dass vielen der Vorteile auch nicht zu vernachlässigende Nachteile gegenüberstehen. Dieser Blogpost soll nun klären, unter welchen Voraussetzungen eine Microservice-Architektur Stand der Technik ist. D.h. (zumindest im Vergleich zu einer modulithischen Architektur) effektiver (also nur so die Ziele erreichend) oder zumindest effizienter (also die Ziele produktiver erreichend) ist: Skalierung:  Microservices sind effektiver, wenn eine vertikale Skalierung (mehr CPUs, Arbeitsspeicher, Netzwerkbandbreite, ...) nicht ausreicht, um die Anforderungen an die Gesamtsoftware zu stemmen 1 und  es Teile gibt, die sich nicht (horizontal) skalieren lassen und  sich durch eine "Auslagerung" dieser Teile in Microservices das Gesamtsystem realisieren lässt. Ansonsten aber sind sie finanziell und organisatorisc...

Microservices haben weitaus mehr Nach- als Vorteile. Aber nicht die Anzahl, sondern deren Auswirkungen auf das jeweilige Projekt sind relevant. Man muss also für jedes einzelne Projekt neu bestimmen, ob die Auswirkungen der Vorteile die der Nachteile übertreffen. Nur wenn diese Verhältnismäßigkeit positiv und besser ist, als bei alternativen Architekturen, gilt eine Microservice-Architektur als fortschrittlicher und somit Stand der Technik. Die (objektive und nachvollziehbare) Bestimmung, ob eine Microservice-Architektur für ein bestimmtes Projekt geeignet ist, ist aufwändig. Es lassen sich aber einige der Vorteile den Nachteilen gegenüberstellen, wodurch sich für einen Großteil aller Projekte eine allgemeine Aussage ableiten lässt. Eine meist einfach zu machende Einordnung einer Software bezüglich der im Folgenden genannten Vor- und Nachteile bzw. im folgenden Blogpost aufgezählten Merkmale sollte reichen, um sicherzustellen, dass eine Microservice-Architektur für die jeweilige Sof...

Microservices haben zwar jede Menge Vorteile, aber auch viele Nachteile. Nur wenn die Vorteile die Nachteile überwiegen, macht der Einsatz einer Microservice-Architektur Sinn. Nur wenn die Verhältnismäßigkeit zwischen Vor- und Nachteilen besser ist als bei alternativen Architekturen, gilt eine Microservice-Architektur als fortschrittlicher. Dies ist aber Voraussetzung für den Stand der Technik, und dieser üblicherweise Vertragsbestandteil oder gewöhnlich vorausgesetzte Eigenschaft. Eine Microservice-Architektur ist somit nur dann vertragskonform, wenn sich ihre Fortschrittlichkeit für das jeweilige Projekt nachweisen lässt. Im letzten Blogpost wurde dargelegt, dass Microservice-Architekturen generell zwei der drei Bedingungen für den Stand der Technik erfüllen. Diesmal geht es darum zu prüfen, welche Vor- und Nachteile eine Microservice-Architektur gegenüber einem Modulithen 1  - der typischen Alternative zu einer Microservice-Architektur - haben. Dazu lässt sich viel z.B. im I...

Noch vor wenigen Jahren waren Microservices in aller Munde.  Microservice-Architekturen versprechen jede Menge Vorteile: Verteil- und skalierbarer, verfügbarer, wartbarer, paralleler entwickelbar, schneller und öfter ausrollbar, ... sollten sie sein. Doch stimmt das auch tatsächlich und macht das Microservice-Architekturen zum Stand der Technik? Zweifelsohne kann man Software mit einer Microservice-Architektur umsetzen. Es gibt schon seit vielen Jahren erfolgreich mit einer Microservice-Architektur umgesetzte Projekte. Vorreiter war Netflix 2009, inzwischen hat Netflix tausende Microservices die teilweise hunderte Male täglich ausgerollt werden. → Damit ist die Funktionstüchtigkeit von Microservice-Architekturen als erprobt und erwiesen anzusehen - eine der Bedingungen für die Erfüllung des Standes der Technik . Die zweite Bedingung für die Erfüllung des Standes der Technik ist, ob das geprüfte Verfahren (also eine Microservice-Architektur) auf wissenschaftlichen Erkenntnis...

Pair Programming ist eine Arbeitstechnik der agilen Softwareentwicklung die in den 1990er Jahren mit Extreme Programming eingeführt wurde und bereits seit den 2000er Jahren breite Verwendung findet. Ist Pair Programming somit am Stand der Technik? Darf bzw. muss man es überall einsetzen? Ist es vielleicht schon längst durch modernere Arbeitstechniken wie Mob Programming überholt? Um diese Fragen korrekt beantworten zu können, muss man nicht nur wissen, was Pair Programming genau ist und welche Alternativen es dazu gibt, was die Klausel "Stand der Technik" bedeutet und welche Verpflichtungen sich daraus ableiten . Man muss (gegebenenfalls sogar vor Gericht haltbar) nachweisen können, warum die Antworten nur so und nicht anders lauten können. Hier der diesbezügliche Nachweis basierend auf dem bereits früher vorgestellten gerichtlich haltbaren Prüfschema : Beruht Pair Programming auf wissenschaftlichen Erkenntnissen? Ist die Funktionstüchtigkeit von Pair Programming ...

Software muss (wie alle Produkte und Dienstleistungen) dem Stand der Technik bzw. zumindest den anerkannten Regeln der Technik entsprechen. Das wird oft vertraglich festgelegt und auch von den Softwareentwicklern meist behauptet. Doch wie kann man das auch belegen? Stand der Technik, (allgemein anerkannte) Regeln der Technik und Stand der Wissenschaft (und Forschung) sind juristische Technikklauseln , die in verschiedenen Rechtsgebieten Verwendung finden. Zur exakten Wortwahl und deren juristische Interpretation siehe Technikstandards . Aber wie kann man nachvollziehbar und auch vor Gericht haltbar nachweisen bzw. prüfen, ob ein Produkt bzw. eine Dienstleistung dem geforderten Standard entspricht? 1 Geprüft werden muss jedes Verhalten auf technischem Gebiet (also jede Technik, jedes Tool, jede Technologie) ob es dem folgenden Schema entspricht. Sobald auch nur ein Punkt nicht eingehalten ist, so gilt dieses Verfahren und somit das gesamte Produkt bzw. die Dienstleistung als nicht de...

Viele Verträge enthalten einen Passus, der beschreibt an welchen Technikstandard sich das zu liefernde Produkt bzw. die Dienstleistung zu halten hat. Hier wird bei Softwareverträgen oft auf den Stand der Technik , die Regeln der Technik oder Normen verwiesen. Das alleine reicht jedoch bei weitem nicht , da weder der Stand der Technik, noch die Regeln der Technik, noch IT Normen gut genug definiert sind, um deren Einhaltung unzweifelhaft festzustellen. Aber es ist zumindest ein grober Hinweis darauf, was diesbezüglich geschuldet wird. Doch wie unterscheiden sich diese Technikstandards überhaupt? Stand der Technik und Regeln der Technik sind juristische Technikklauseln , die in verschiedenen Rechtsgebieten Verwendung finden (z.B. für Gewährleistung oder Schadenersatz). Es wird zwischen folgenden 3 Stufen unterschieden: 1 Regeln der Technik - " technische Regeln, die aus Wissenschaft oder Erfahrung auf technischem Gebiet gewonnene Grundsätze enthalten und deren Richtigke...

In der Informatik gibt es wie in anderen Bereichen auch Normen: Weniger länderspezifische DIN oder ÖNORMen, aber insbesondere viele internationalen ISO/IEC/IEEE Normen für die unterschiedlichsten Bereiche der Informatik. Diese Normen beschreiben alle Prozesse rund um Software - von der ersten Idee bis zur Ablöse einer Software. Muss man sich als Softwarehersteller an diese Normen halten? IT Normen sind extrem teuer. Es gibt nicht nur ca. 100 Software betreffende Normen, sie sind auch teils recht umfangreich und um ein Vielfaches teurer als Fachliteratur (oft mehrere Euro pro Seite). Viele davon werden mehr oder weniger regelmäßig (ca. alle 10 Jahre) zum Teil mit drastischen Änderungen erneuert oder durch eine neuere Norm abgelöst. Es ist nicht verwunderlich, dass sich die meisten in der Informatik tätigen Unternehmen scheuen, die mehreren 10.000 € aufzuwenden, um die Normen zu kaufen. Und die Unternehmen, die bereit sind, das Geld dafür aufzuwenden, finden nur selten Mitarbeite...

Wenn der Einsatz von Künstlicher Intelligenz (KI) legal ist, dann sollte er auch dem Stand der Technik entsprechen. Nur weil eine Technologie neu (wobei KI eigentlich eine schon uralte Technologie ist) und in aller Munde ist, heißt das ja nicht, dass sie auch dem Stand der Technik entspricht. Und entspricht der Einsatz von KI nicht dem Stand der Technik, so ist er auch in vielen Fällen nicht legal . Damit Software dem Stand der Technik entspricht muss sie den 4 Grundsätzen des Standes der Technik entsprechen. Die Frage ist also: Entspricht der Einsatz von KI 1) dem Entwicklungsstand, ist er 2) fortschrittlich und 3) bewährt und darüber hinaus auch 4) zielgerichtet? Wenn die KI auf aktuellen Technologien beruht - also beispielsweise Frameworks für neuronale Netze oder maschinelles Lernen verwendet - entspricht der Einsatz der KI zweifelsohne dem Entwicklungsstand und gilt als fortschrittlich, solange aktuelle Versionen der Frameworks eingesetzt werden. In den meisten Projekten wer...

Software hat sehr oft technische Schulden, in vielen Fällen eine ganze Menge davon. Vor der Abnahme bzw. Einsatz der Software sollten diese alle behoben werden, ansonsten drohen finanzielle und juristische Probleme.  Steht man aber noch nicht unmittelbar vor der Abnahme/Einsatz der Software, so gibt es eine Möglichkeit, um technische Schulden ohne nennenswerte Aufwände abzubauen. Die Lösung dafür nenne ich "Limbotanzen mit Softwarequalität": Die Basis dafür sind Quality-Gates  - Prüfungen der Software die, wenn sie nicht erfolgreich bestanden werden, zwingend zu einer unmittelbaren Beseitigung der gefundenen Mängel führen. Idealerweise werden diese Prüfungen automatisiert und verhindern auch technisch, dass vor Beseitigung der Mängel weitergearbeitet werden kann. Beispielsweise sind Pull-Requests derartige Quality-Gates, wenn 1) sichergestellt wird, dass Code nur mittels Pull-Request in den Hauptbranch gelangen kann und 2) bei diesen Pull-Requests z.B. automatisiert auch die...

Bei Verfehlungen des Standes der Technik ist eine nachträgliche Verbesserung potentiell extrem aufwändig:  Es reicht meist nicht aus, sich ein, zwei Sprints oder Monate mit dem Aufräumen der Dinge zu befassen, die man in den Monaten oder Jahren davor eingebaut hat. Mängel in Softwarearchitektur, -Design oder auch bei den Tests können oft weder zeitnah noch ohne unerwünschte Nebeneffekte behoben werden. Zur Abschätzung von Aufwand und Durchlaufzeit der Verbesserung hilft eine Bestandsaufnahme und Gliederung der Mängel. Eine Bestandsaufnahme der Mängel hinsichtlich des Standes der Technik sollte spätestens mit der Abnahmeprüfung erstellt worden sein, ansonsten muss man davon ausgehen, dass die Software diesbezüglich nicht geprüft wurde und ihr Einsatz grob fahrlässig wäre.  Eine Gliederung der Mängelbehebungen sollte hinsichtlich ihres Aufwandes und dem damit verbundenen Risiko gemacht weden. Jede Veränderung an einer Software trägt ja das Risiko mit sich, dass die Softwa...

Software muss hinsichtlich der Entsprechung des Standes der Technik geprüft werden . Ansonsten kann nicht gesagt werden, dass die Software den Anforderungen entspricht , was zur Verweigerung der Abnahme und (auch bei nur intern verwendeter Software) rechtliche Konsequenzen  führt. Spätestens zum Zeitpunkt der Abnahme bzw. vor In-Betriebnahme sollte eine derartige Prüfung durchgeführt werden.  Da der Stand der Technik zu den „Beschaffenheiten, die … üblich und vom Käufer erwartbar sind“ ( §434 BGB ) bzw. „gewöhnlich vorausgesetzten Eigenschaften“ ( § 922 ABGB ) gehört, kann der Auftraggeber zwar auch noch nach der Abnahme diesbezüglich Verbesserung verlangen, aber das wird für beide Seiten deutlich teurer: Sobald die Software eingesetzt wird, führen einerseits diesbezügliche Mängel potentiell zu Schäden, andererseits ist eine Behebung der Mängel dann potentiell deutlich teurer (weil beispielsweise Produktivdaten korrigiert werden müssen. Wie aber stellt man bei A...

Bereits im Rahmen der Entwicklung einer Software werden oft Verletzungen des Standes der Technik eingebaut. Kaum ein Entwicklungsteam kann von sich behaupten, dass die Software an allen Stellen dem Stand der Technik entspricht. Allzuoft erkennt man bereits während der Entwicklung Mängel, findet aber keine Zeit sie auszubauen. Dasselbe gilt für die Wartung - bereits bestehende Mängel werden nicht ausgebaut und neue Mängel kommen durch Wartungsarbeiten bzw. verabsäumte Anpassungen der Software an den geänderten Stand der Technik hinzu. Die Frage lautet also: Wie kann man während der Softwareentwicklung verhindern, dass Mängel hinsichtlich des Standes der Technik eingebaut werden bzw. dass verabsäumt wird, diese auszubauen? Alle Menschen machen Fehler, das gilt selbstverständlich auch für gute Softwareentwickler. Aber unterschiedliche Softwareentwickler machen unerschiedliche Fehler, darum ist die Wahrscheinlichkeit, dass ein Fehler (oder ein Mangel hinsichtlich des Standes der Tech...

Bei Software ist der Stand der Technik weder allgemein definiert oder bekannt , noch wird er üblicherweise eingehalten . Spätere Streitereien bzw. der Einsatz einer nicht dem Stand der Technik entsprechenden Software mit all den juristischen Problemen für Auftraggeber und Auftragnehmer, sind vorprogrammiert. Man tut also gut daran, bereits bei der Vertragsgestaltung bzw. Ausschreibung den Stand der Technik zu berücksichtigen. Dieser Blog enthält viele Posts, die vertraglich zu berücksichtigende Punkte enthalten  - siehe  Label Vertragsgestaltung . Diese sollten idealerweise alle berücksichtigt werden, um den Stand der Technik sicherzustellen und spätere Streitereien zu vermeiden. Einige davon lassen sich trivial durch einzelne Sätze in den Verträgen festhalten, andere aber wiederum benötigen tiefergehendes technisches Wissen. Die Vertragsgestaltung einzig den Juristen zu überlassen ist daher nicht zielführend. Üblicherweise findet man in Softwareverträgen und -ausschreibung...

Im B2B Bereich kann Haftung wegen leichter Fahrlässigkeit ausgeschlossen werden (siehe  §309-310 BGB  bzw.  OGH RS0016582 ). Die Gewährleistung kann bei B2B maximal auf 1 Jahr verkürzt werden und auch hier kommt es auf den Grad der Fahrlässigkeit an. Aus diesem Grund findet man auch in vielen Softwareverträgen den Ausschluss der Haftungs- und Gewährleistungsansprüche bei leichter Fahrlässigkeit. Es stellt sich daher die Frage: "Sind Verfehlungen des Standes der Technik leicht oder grob fahrlässig?" Grobe Fahrlässigkeit ist gesetzlich nicht exakt von leichter Fahrlässigkeit abgegrenzt.  Darunter wird im Allgemeinen folgendes verstanden: Ein Handeln, bei dem die erforderliche Sorgfalt in einem ungewöhnlich hohen Maße verletzt worden ist. Ein Verhalten, das einem ordentlichen Menschen in derselben Situation keinesfalls unterlaufen würde. 1 Wird bei Verfehlungen des Standes der Technik also die erforderliche Sorgfalt in einem ungewöhnlich hohen Mape verletzt? Unterlau...

Software ist zum Abnahmezeitpunkt erfahrungsgemäß oft nicht am Stand der Technik .  Entspricht ein Produkt bzw. eine Dienstleistung zum Abnahmezeitpunk (~ "Zeitpunkt des Gefahrenübergangs") nicht dem Stand der Technik, so handelt es sich um einen Mangel. Gemäß Gewährleistungsrecht ( § 437ff BGB  bzw.  § 932 ABGB ) kann der Käufer nun Austausch oder Verbesserung verlangen und wenn diese Maßnahmen nicht zielführend oder unzumutbar ist, vom Vertrag zurücktreten bzw. bei geringfügigen Mängeln eine Preisminderung verlangen. Dazu muss aber zunächst einmal die Abnahme verweigert werden. Mit der Abnahme würde der Auftraggeber nämlich bestätigen, dass der Auftragnehmer seinen Leistungspflichten nachgekommen sei. Nur bei geringfügigen Mängeln (z.B. teilweise Verfehlung der Einhaltung von Naming-Conventions, Einsatz von Libraries mit veralteten aber noch gewarteten Versionen) fehlt die rechtliche Grundlage, um die Abnahme zu verweigern. Die Mängel müssen aber dennoch im Rahme...