Bei GitHub handelt es sich um eine Online-Plattform, die eine effektive Zusammenarbeit an gemeinsamen Projekten ermöglicht. Am häufigsten wird sie Ihnen im Zusammenhang mit Open-Source-Software begegnen. GitHub eignet sich aber nicht nur für die gemeinsame Arbeit an öffentlich einsehbarem Code, sondern auch für nicht-öffentlichen Code in Unternehmen oder anderen Organisationen. Wer welchen Zugriff erhält, lässt sich genauestens kontrollieren.

Herzstück von GitHub ist eine Versionsverwaltungs-Software namens Git, die vom Linux-Erfinder Linus Torvalds entwickelt wurde. Sie ermöglicht es, jede noch so kleine Änderung an einem Projekt ressourcenschonend nachvollziehbar zu machen. Git speichert nämlich nur die Unterschiede zwischen verschiedenen Dateiversionen, nicht die Versionen selbst.

Git bietet einige nützliche Funktionen, die GitHub nochmal erweitert. Bei der Arbeit mit dem Tool werden Ihnen Begriffe wie "Commits", "Pull Requests" und "Merges" begegnen, deren genaue Bedeutung wir Ihnen im Folgenden erläutern.

Erste Schritte mit GitHub

So erstellen Sie einen GitHub-Account

Bevor Sie mit GitHub loslegen können, benötigen Sie einen Account. Öffnen Sie dazu einfach die GitHub-Website (https://github.com/) und tippen Sie in das mit "Email address" beschriftete Eingabefeld die E-Mail-Adresse ein, die Sie zukünftig für Ihren GitHub-Zugang nutzen möchten. Klicken Sie anschließend auf die daneben stehende Schaltfläche mit der Beschriftung "Sign up for GitHub".

Sie werden nun zum Prozess für die Account-Erstellung weitergeleitet. Legen Sie ein sicheres Passwort und einen aussagekräftigen Benutzernamen fest. Beachten Sie dabei, dass dieser Benutzername allen Projektbeteiligten angezeigt wird.

Folgen Sie anschließend dem auf GitHub beschriebenen Prozess.

So treten Sie dem webfactory-Repository bei

Sie erhalten von uns eine Einladung zu Ihrem webfactory-Repository.

Ein Repository (zu Deutsch "Aufbewahrungsort") beinhaltet alle mit Ihrem Projekt verbundenen Dateien und deren unterschiedliche Versionen. Es ist somit Dreh- und Angelpunkt für unsere Zusammenarbeit.

Öffnen Sie die Einladungs-Mail und klicken Sie auf die Schaltfläche "View invitation". Sie haben nun die Möglichkeit, die Einladung anzunehmen oder abzulehnen. Erst wenn Sie die Einladung angenommen haben, können wir mit Ihnen auf GitHub zusammenarbeiten.

Wir schützen alle Repositorys mittels 2-Faktor-Authentisierung (2FA), um die Vertraulichkeit der Projektdateien zu gewährleisten. Daher muss jeder Nutzer mit Zugriff auf das Repository ebenfalls die 2-Faktor-Authentisierung für seinen GitHub-Account aktivieren. Bitte sprechen Sie uns an, falls Sie dabei Hilfe benötigen sollten.

Wenn Sie das Repository öffnen, wird Ihnen zunächst der Reiter "Code" und damit die Verzeichnisstruktur des Projekts angezeigt. Klicken Sie sich gerne durch die einzelnen Verzeichnisse, wenn Sie neugierig sind. Ein Tipp: Neben dem Verzeichnisnamen sehen Sie, welches die letzte Änderung innerhalb dieses Verzeichnisses war und wann sie erfolgt ist. Das ist häufig ein guter Hinweis darauf, wo die interessantesten Stellen im Quellcode sind.

Der Code-Tab: Die Übersichtsseite Ihres Projekts

Ist in der Symbolleiste oben links der Reiter Code hervorgehoben, befinden Sie sich auf der Übersichtsseite des Repository. Hier finden Sie die Verzeichnisstruktur des Quellcodes Ihres Projekts. Direkt über den Verzeichnissen wird Ihnen die letzte Änderung (Commit) angezeigt und wer diese vorgenommen hat. Rechts finden Sie zudem die Gesamtzahl der bisher vorgenommenen Commits, gekennzeichnet durch ein Uhr-Symbol. Klick Sie darauf, um eine Historie der Änderungen einzusehen.

Weiter unten auf der Seite wird Ihnen die README.md des Projekts angezeigt. Dabei handelt es sich um eine einfache Textdatei, in der wir wichtige Basisinformationen über das System, Ansprechpartner und Links zur Dokumentation sammeln.

Sollten Sie einmal nach einer bestimmten Information im Projekt suchen, aber nicht wissen, wo diese zu finden ist, können Sie die Suchleiste am oberen Seitenrand verwenden.

Benachrichtigungen: So steuern Sie, welche E-Mails Ihnen GitHub schickt

Während der Projekarbeit ist im Repository eine Menge los. Wenn Sie für jedes Vorkommnis eine Benachrichtigung von GitHub erhalten, werden Sie wahrscheinlich schnell den Überblick verlieren. Daher empfehlen wir Ihnen, die Benachrichtigungseinstellungen an Ihre Bedürfnisse anzupassen.

Öffnen Sie dafür Ihr Repository und klicken Sie auf die mit einem Augen-Symbol versehene Schaltfläche mit der Beschriftung "Watch". Am besten setzen Sie in dem sich nun öffnenden Drop-down-Menü ein Häkchen bei "Participating and @mentions", sofern die Option nicht ohnehin schon vorausgewählt ist. Sie erhalten dann nur Benachrichtigungen von Kommunikationsfäden, in die Sie sich selbst einbringen, und wenn Sie jemand mit Ihrem Benutzernamen direkt erwähnt.

Alternativ können Sie auch selbst festlegen, über was Sie zukünftig benachrichtigt werden sollen. Klicken Sie dafür im erwähnten Drop-down-Menü auf "Custom" und setzen Sie die entsprechenden Häkchen.

Natürlich kann es trotzdem vorkommen, dass Ihnen die Menge der Benachrichtigungen zwischenzeitlich zu viel wird. Um das zu vermeiden, können Sie die Benachrichtigungen für einzelne Issues und Pull Requests (beide Begriffe erläutern wir weiter unten im Text) ausschalten. Klicken Sie hierzu in der rechten Seitenleiste auf die Schaltfläche mit der Beschriftung "Unsubscribe" und einem durchgestrichenen Glocken-Symbol.

Wenn Sie tiefer in das Thema Benachrichtigungseinstellungen einsteigen möchten, empfehlen wir Ihnen das entsprechende Kapitel in der GitHub-Dokumentation.

Was ist ein Issue?

Ein wichtiger Begriff bei der Zusammenarbeit auf GitHub ist das Issue. Bei Open-Source-Projekten wird diese Funktion beispielsweise genutzt, um auf Fehler in der Software hinzuweisen.

Wir verwenden Issues in unseren Projekten vor allem für die Erstellung von Arbeitsaufträgen. Eröffnen Sie ein Issue, wenn Sie Verständnisfragen haben, Korrekturbedarf erkennen oder eigene Ideen beisteuern möchten. Wir versuchen im Rahmen unseres Suppports schnellstmöglich darauf zu reagieren.

Wir bevorzugen es, den Austausch über E-Mail möglichst durch die Verwendung von Issues zu ersetzen, denn dadurch wird die Kommunikation für alle Beteiligten nachvollziehbarer. Hängen Sie daher gerne relevante Screenshots oder PDF-, Word- oder Excel-Dateien an Ihre Issues an. Klicken Sie dazu bei der Erstellung in der Symbolleiste des Texteingabefelds auf das Büroklammer-Symbol ("Attach files") oder ziehen Sie die Dateien einfach in das Kommentarfeld. Die rechte Spalte neben der Issue-Maske (Assignees, Labels, Projects, Milestones, Development) können Sie beim Erstellen eines Issues einfach ignorieren. Sie ist vor allem für das Projektmanagement relevant.

Um die Kommunikation kurz und bündig zu halten, verzichten Sie am besten auf Grußformeln und Signaturen. Sie können das @-Zeichen dazu verwenden, einzelne Beteiligte direkt anzusprechen. Sobald Sie das Zeichen eintippen, erscheint eine Liste mit möglichen Ansprechpartnern. Praktisch, wenn Ihnen die Schreibweise eines Benutzernamens entfallen ist.

Übrigens können Sie auf Benachrichtigungen auch per Mail reagieren. Das hat den Vorteil, dass Sie dafür nicht von Ihrer E-Mail-Software zu GitHub wechseln müssen. Beachten Sie dabei allerdings, dass die komplette Mail als Kommentar im Issue landet. Am besten schreiben Sie daher auch in diesem Fall ohne Grußformeln und löschen alles außer Ihrer eigentlichen Nachricht aus dem E-Mail-Text – sonst wird es im Issue mitunter unübersichtlich. Eine wichtige Einschränkung beim Antworten per Mail: Bilder und Anhänge aus E-Mails kommen leider nicht in GitHub an.

Was ist ein Pull Request?

Ein weiterer wichtiger Begriff im Zusammenhang mit GitHub ist der Pull Request. Damit schlagen Entwickler Änderungen am Code vor, um sie untereinander zu besprechen. Je nach Schwierigkeit und Umfang der Aufgabe können ein oder mehrere weitere Entwickler prüfen, ob die Änderungen verständlich, inhaltlich korrekt, vollständig und der Aufgabe angemessen sind. Die Änderungen treten erst dann in Kraft, wenn der Pull Request akzeptiert und mit dem Produktions-Code zusammengeführt wird. Diesen Vorgang nennt man Merge.

Auch Sie können gerne Pull Requests nutzen, um Änderungen vorzuschlagen. Manche unserer Kunden haben damit Tippfehler korrigiert und Übersetzungen gepflegt – und ein technisch besonders versierter Kunde hat darüber auch schon Änderungen am Programmcode vorgenommen.

Wir sehen uns auf GitHub!

Im ersten Moment kann der Funktionsumfang von GitHub einschüchternd wirken. Doch die Einarbeitung in das Tool lohnt sich, denn die gemeinsame Projektarbeit wird dadurch für alle Beteiligten effizienter und nachvollziehbarer.

Wir hoffen, dass Ihnen dieser Artikel bei den ersten Schritten mit GitHub geholfen hat. Sollten sich bei Ihnen weitere Fragen ergeben haben, schreiben Sie uns eine E-Mail. Wir helfen Ihnen gerne weiter.

Wir entwickeln seit 1997 Webanwendungen für unsere Kunden, deren Hauptziel es häufig ist, bestehende Prozesse zu vereinfachen und den Arbeitsaufwand für alle Beteiligten zu minimieren. Im Folgenden möchten wir Ihnen fünf Beispiele vorstellen, die unseren Kunden richtig viel Arbeit abgenommen haben.

Beispiel 1: Youthpass – PDF-Zertifikate für Erasmus+

Wer sich in einem durch Erasmus+ Jugend oder das Europäische Solidaritätskorps geförderten Projekt engagiert, kann sich dafür seit 2007 ein digitales Teilnahmezertifikat ausstellen lassen. Ermöglicht wird das durch eine Webanwendung, die wir für unseren Kunden JUGEND für Europa entwickelt haben.

Dank dieser Anwendung können die Verantwortlichen der über ganz Europa verstreuten Projekte eigenständig die für die Zertifikate benötigten Daten erfassen und die offiziellen Zertifikate erstellen und ausdrucken. Ohne die Webanwendung hätten die Informationen erst von einer zentralen Stelle gesammelt werden müssen, um anschließend Zertifikate zu erstellen und mühsam an die Teilnehmer zu versenden. Das hätte den Prozess erheblich verlangsamt.

Die Webanwendung bringt weitere Vorteile mit sich:

• Teilnehmerlisten lassen sich in Form von Excel-Dateien importieren.
• Ein integriertes Nachrichtensystem erleichtert die Kommunikation mit den Projektteilnehmern.
• Die Anwendung generiert automatisch barrierefreie PDF-Zertifikate auf Basis der im System hinterlegten Daten und stellt sie den Teilnehmern zum Download bereit.
• Die Nationalagenturen des Jugendprogramms pflegen die Übersetzungen der in 28 Sprachen verfügbaren Zertifikate selbstständig über die Webanwendung.

Seit Einführung unserer Lösung konnten die über 30.000 involvierten Organisationen bereits mehr als 1,5 Millionen Zertifikate für über 90.000 Projekte ausstellen.

Mehr zur Youthpass-Webanwendung

Beispiel 2: OBELIS – Online-Berichterstattung für Ladeinfrastruktur

Die NOW GmbH koordiniert die wissenschaftliche Begleitung der Förderrichtlinie Ladeinfrastruktur, mit der der Ausbau von Ladestationen für Elektrofahrzeuge in Deutschland vorangetrieben werden soll. Wer die Mittel in Anspruch nimmt, übermittelt im Gegenzug Stamm- und Betriebsdaten der geförderten Ladestationen zwecks wissenschaftlicher Auswertung an die NOW GmbH.

Bevor wir mit der Entwicklung einer Webanwendung beauftragt wurden, stellten die Ladestationbetreiber ihre Daten in Form von Excel-Tabellen zur Verfügung. Das beeinträchtigte die Datenqualität und damit die Belastbarkeit der Auswertung erheblich.

Gemeinsam mit der NOW GmbH und ausgewählten Zuwendungsempfängern entwickelten wir daher OBELIS ("Online-Berichterstattung Ladeinfrastruktur"). Diese Webanwendung bietet folgende Vorteile:

• Zuwendungsempfänger können ihre Stammdaten direkt im Browser eintragen.
• Sie können die Betriebsdaten mehrerer Ladenstationen gleichzeitig melden.
• Sie erhalten eine Meldebestätigung im PDF-Format zur Einreichung bei der Bewilligungsbehörde.
• Die Anwendung ermöglicht das Importieren von Betriebsdaten als Excel-Datei und erleichtert die Normalisierung der Daten über einen Wizard.

OBELIS ist seit Frühjahr 2019 im Einsatz und hilft der NOW GmbH dabei, wissenschaftlich belastbare Prognosen für den zukünftigen Bedarf an öffentlicher Ladeinfrastruktur zu erstellen.

Mehr zur OBELIS-Webanwendung

Beispiel 3: Deutsch-Südafrikanischer Reisedienst – Visuelle Aufbereitung von Reiseverläufen

Der Deutsch-Südafrikanische Reisedienst (DSAR) vermittelt seit über 50 Jahren Reisen nach Namibia, Südafrika und Botswana.

Im Sommer 2018 halfen wir dem Bonner Unternehmen dabei, seine Website konzeptuell zu überarbeiten und mit nützlichen neuen Funktionen auszustatten. Das Highlight bildet der interaktive Reiseverlauf: Während Besucher in diesem herunterscrollen, werden ihnen für jeden Reisetag auf der linken Seite die Sehenswürdigkeiten und auf der rechten Informationen zur Unterkunft angezeigt. Dank der horizontal darüber verlaufenden Zeitleiste wissen sie stets, an welchem Punkt der Reise sie sich gerade befinden. All diese Informationen werden automatisch aus dem internen Verwaltungssystem des Anbieters importiert: Jeder einzelne der mehreren Tausend im Verwaltungssystem erfassten Reiseverläufe kann mit einem Kurzbefehl in jeden beliebigen Text auf der Website eingebunden werden, ohne Copy-Paste und ohne Gestaltungsaufwand.

Das bietet die neue DSAR-Website ihren Besuchern:

• Übersichtliches Design mit klarer Kommunikation der verfügbaren Reiseziele und -formate
• Möglichkeit zum Speichern von Tourvorschlägen ohne Anlegen eines Nutzerprofils
• Interaktive Visualisierung der Reiserouten mit weiterführenden Informationen zu den Reisestationen und Unterkünften

Seit September 2021 können Website-Besucher sich von einem digitalen Beratungs-Tool zudem Reiseverläufe vorschlagen lassen, die zu ihren persönlichen Vorlieben passen.

Mehr zur neuen DSAR-Website

Beispiel 4: Krankenkassen.de – Digitale Wechselanträge mit Online-Unterschrift

Krankenkassen.de ist ein unabhängiges Informationsportal der Berliner Agentur Euro-Informationen, auf dem sie die Leistungen von über 70 gesetzlichen Krankenkassen vergleicht und in Form von verbraucherfreundlichen Texten journalistisch aufarbeitet.

Wir betreuen die Website bereits seit 2002 und statteten sie im Sommer 2015 mit einem responsiven Design inklusive mobiloptimierter Darstellung aus. Kurz darauf folgte die Einführung einer Vergleichsfunktion für Krankenkassenleistungen und -zusatzbeiträge.

Seit 2018 können die Nutzer von Krankenkassen.de außerdem von einem digitalen Wechselservice Gebrauch machen, der über folgende Funktionen verfügt:

• Automatische Übertragung von Eingaben aus Web-Formularen in PDF-Aufnahmeanträge für Krankenkassen
• Seit 2020 Möglichkeit der elektronischen Unterschrift und der direkten Übermittlung von Wechselanträgen an Krankenkassen via API-Anbindung

2022 ermöglichten wir es Krankenkassen.de zudem, vollständig auf Cookies und Tracking durch Werbepartner zu verzichten. Damit kann die Website ohne Cookie-Consent betrieben werden.

Mehr zum Informationsportal Krankenkassen.de

Beispiel 5: Gemeinsamer Bundesausschuss – Online-Bestellsystem für Druckerzeugnisse

Der Gemeinsame Bundesausschuss (G-BA) ist im deutschen Gesundheitswesen das höchste Gremium der Selbstverwaltung. Zu von ihm beschlossenen Richtlinien stellt er Informationsmaterial als Druckerzeugnisse zur Verfügung, die berechtigte Organisationen (etwa Krankenhäuser) kostenfrei bestellen können.

Der G-BA arbeitet mit verschiedenen Druckereien zusammen, die für die Herstellung, Lagerung und den Versand der Unterlagen verantwortlich sind. Der Aufwand, der mit der Koordination von Bestellungen einherging, war daher früher sehr hoch.

Mit unserer Webanwendung haben wir die Prozesse wesentlich vereinfacht und stark automatisiert. Nun ist sofort ersichtlich, welche Materialien verfügbar sind, sodass umgehend eine Bestellung mit der benötigten Stückzahl aufgegeben werden kann. Das System verteilt die Bestellungen automatisch auf die einzelnen Druckereien. Diese erhalten eine E-Mail mit Einzelheiten zu den angeforderten Druckerzeugnissen und können über einen Link den Versand bestätigen und Teillieferungen anzeigen.

Der neue Prozesse bringt zahlreiche Verbesserungen mit sich:

• Die Lagerbestände bei den einzelnen Druckereien sind jederzeit einsehbar.
• Die integrierte Berichtsfunktion liefert Daten zu Bestellmengen der einzelnen Druckerzeugnisse, wie sich diese im Laufe der Zeit entwickelt haben, an welche Organisationen sie ausgeliefert wurden und welche Druckereien für die Herstellung verantwortlich waren.
• Alle Abläufe wurden in einem System vereint, sodass die Integration mit den Bestandsmanagementsystemen der Druckereien entfällt.
• Durch Benachrichtigungen beim Unterschreiten von anpassbaren Schwellenwerten lassen sich Ausschreibungen für Nachdrucke rechtzeitig planen.

Die Einführung der Webanwendung reduzierte den mit der Bestellung von Druckerzeugnissen verbundenen Aufwand für den G-BA und die Druckereien erheblich.

Mehr Informationen zur Webanwendung des G-BA

Sprechen Sie uns an

Haben Sie diese Beispiele zum Nachdenken angeregt, welche Ihrer Arbeitsprozesse Sie durch eine Webanwendung vereinfachen könnten, um die digitale Transformation in Ihrer Organisation voranzubringen? Dann sprechen Sie uns gerne an. Gemeinsam mit Ihnen analysieren wir, an welchen Stellen Optimierungspotenzial besteht. Anschließend erarbeiten wir ein Konzept, mit dem wir dieses verwirklichen.

Sie sind an weiteren Beispielen für Webanwendungen interessiert? Dann empfehlen wir Ihnen unseren Blog-Post "Praxisbeispiele: Fünf Webanwendungen aus unserem Hause".

Barrierefreiheit sollte nicht nur als Verpflichtung, sondern vor allem als Chance begriffen werden.

1. Vielfalt und Inklusion

In einer Gesellschaft, die Vielfalt und Inklusion schätzt, sollte der digitale Raum keine Ausnahme bilden. Barrierefreie Websites ermöglichen es Menschen mit unterschiedlichen Fähigkeiten und Einschränkungen, ohne Hürden am digitalen Leben teilzunehmen. In Deutschland wird die Förderung der Vielfalt als Grundwert angesehen, und barrierefreie Websites sind ein Schlüssel dazu.

2. Gesetzliche Vorgaben

Die Gesetzgebung in Deutschland verpflichtet Unternehmen und öffentliche Einrichtungen dazu, barrierefreie Angebote im Internet bereitzustellen. Die UN-Behindertenrechtskonvention, die von Deutschland ratifiziert wurde, und das deutsche Behindertengleichstellungsgesetz (BGG) setzen klare Maßstäbe für die Barrierefreiheit im digitalen Raum. Das Nichteinhalten dieser Vorschriften kann nicht nur rechtliche Konsequenzen nach sich ziehen, sondern auch das Image eines Unternehmens erheblich beeinträchtigen.

3. Demografischer Wandel

Der demografische Wandel verändert die Altersstruktur der Bevölkerung. Mit einer älter werdenden Gesellschaft steigt auch die Anzahl der Menschen mit altersbedingten Einschränkungen. Es profitieren daher nicht nur Menschen mit angeborenen Behinderungen von Barrierefreiheit, sondern alle, die im Alter vermehrt auf einen einfachen Zugang zu Informationen und Dienstleistungen angewiesen sind.

4. Wirtschaftlicher Nutzen und Kundenbindung

Unternehmen, die sich aktiv für Barrierefreiheit einsetzen, schaffen ein positives Image als sozial verantwortliche Organisationen. Das bindet nicht nur bestehende Kunden, sondern kann auch neue Kunden anziehen, die bewusst nach Unternehmen suchen, die ihre ethischen Werte teilen. Wichtig ist auch, die wachsende Zielgruppe älterer Menschen nicht aus den Augen zu verlieren.

Barrierefreiheit kann als Differenzierungsmerkmal und positives Alleinstellungsmerkmal dienen und wird zu einer strategischen Entscheidung für Unternehmen.

Fazit

Barrierefreie Websites und Webanwendungen sind mehr als nur ein Trend – sie sind eine Antwort auf die Forderungen nach Vielfalt, gesellschaftlicher Verantwortung und demografischem Wandel. Unternehmen und Institutionen, die diese Bedeutung erkennen, gestalten nicht nur eine inklusive digitale Welt, sondern sichern auch ihre eigene Zukunft.

Es ist an der Zeit, eine digitale Welt zu schaffen, die für uns alle zugänglich ist und von der wir alle gleichermaßen profitieren können.

Wo geht die Reise hin?

Zum Auftakt ging es darum, die Chancen und Herausforderungen des digitalen Wandels zu benennen und aufzuzeigen, welche Entwicklungen möglich sein könnten.

Prof. Holger Simon, Geschäftsführer der veranstaltenden Pausanio GmbH, definierte das „Web 3.0“ als Nachfolger des „Mitmach-Web2.0“. Das Web 3.0 bringe Virtual Reality, „Semantik“ und Künstliche Intelligenz, die mit rasanter Geschwindigkeit beginne, Inhalte zu „verstehen“. Digitalisierung schaffe Mehrwert durch die schnelle, sofortige Kommunikation, die mit Papier nicht möglich sei. Sie ermögliche Kollaboration, bei der wir miteinander und zusammen arbeiten könnten, ohne physisch beisammen zu sein. Und dadurch, dass Computer und Software zukünftig Komplexität so reduzieren könnten, dass Probleme für Menschen verständlich würden.

Andree Haack, Dezernent für Stadtentwicklung, Wirtschaft, Digitales und Regionales der Stadt Köln, sah die große Herausforderung in der Digitalisierung der Verwaltung darin, dass oft „linear“ gedacht und nur das digitalisiert werde, was bereits analog vorhanden sei. Es sei aber viel wichtiger, „warum überhaupt?“ zu fragen und die Veränderungen „disruptiv“ anzugehen, also vollständig neue Wege einzuschlagen.

Dr. Annette Doms, Beraterin für „Web3“, sah mit der von Apple angekündigten VR/MR-Brille „Vision Pro“ das „Metaverse“ an der Schwelle des Durchbruchs. Die Zukunft werde digitale Orte und digitale Communities hervorbringen, in denen sich parallele Gesellschafts- und Wirtschaftsstrukturen entwickeln könnten. Blockchain und NFTs würden die Möglichkeit bringen, dort „digitalen Besitz“ zu erwerben. Eine Herausforderung werde es sein, die Interoperabilität zwischen den verschiedenen „Metaversen“ zu schaffen.

Dr. Felicia Sternfeld, Direktorin des Europäischen Hansemuseums in Lübeck, setzte dem fünf Thesen zur Bedeutung von Museen entgegen. Museen hätten die „Aura der Originale“, die einen Wert an sich darstelle und digital nicht ersetzt werden könne. Insofern müsse es darum gehen, weiter vor Ort zu erleben, aber ergänzend digital zu vernetzen, zu erweitern und den Austausch zu ermöglichen. Museen seien als hoch vertrauenswürdig angesehen und damit ein unerlässlicher Anker für Gesellschaften. In einer „digitalen Kakophonie“ und der oft unklaren Herkunft von Inhalten und Information würden Museen weiter eine verlässiche Quelle für geprüfte, authentische, kuratierte Information bleiben.

Digital Literacy

Im Gegensatz dazu war der nachfolgende Vortrag von Dr. Christian Gries, Leiter der digitalen Museumspraxis und IT im Landesmuseum Stuttgart, konkreter und bodenständig. Digital Literacy, die allgemeine Digitalkompetenz, habe sich in den letzten 20 Jahren deutlich entwickelt. Aber auch heute beherrschten nur etwa 50% der Gesellschaft sicher digitale Basiskompetenzen wie die Kommunikation per E-Mail oder einfachen Rechercheaufgaben. Nur etwa ein Drittel habe ein tieferes Verständnis digitaler Funktionsweisen oder beherrsche komplexere digitale Aufgaben eines Fachgebiets.

Mitarbeitende in Museen und Kultureinrichtungen seien ein Spiegel der Gesellschaft und insofern müsse man davon ausgehen, dass die Kompetenzen dort ähnlich verteilt seien. Das Landesmuseum Württemberg habe es sich daher in der Mitarbeiterentwicklung zur Aufgabe gemacht, auch digitale Kompetenzen auszubauen. Auf Basis des Digital Competence Framework for Citizens (DigComp) der EU hat es eine „Landkarte“ der „Digital Literacy“ entwickelt. Das „digitale Museum“ an sich ist nur einer von sechs Aspekten. Daneben stehen grundlegende Fragen wie allgemeine Medienkompetenz, Kompetenzen zur Kommunikation und kollaborativem Arbeiten oder der kompetente Umgang mit Informations- und Kommunikationstechnik. In diesen Themenfeldern werden Mitarbeitenden des Museums Angebote zur Weiterbildung, Schulung und individuellen Beratung gemacht.

Dr. Gries lobte die in einigen Bundesländer explizit geschaffenen Stellen für „Resilienz-Dispatcher*innen“ oder "Digitalmanager*innen", die es erstmalig ermöglichen würden, digitale Kompetenzen aufzubauen und langfristig im Haus zu halten. Zuvor sei mühsam aufgebautes Wissen oft bald wieder abgewandert, weil Stellen nur befristet besetzt wurden. Viele Museen wären seit 30 Jahren damit beschäftigt, Bestände zu digitalisieren. Letztlich stünden dann aber „im Keller Windows 98-Rechner mit veralteten Datenbanken“ und es gäbe keine Vorstellung, wie man diese Techniken managen müsse, verknüpfen könne und wo man damit überhaupt hinwolle.

Masterclass „Holacracy“

In einem zweistündigen Workshop hatte ich die Gelegenheit, mit drei weiteren Teilnehmer*innen einen Überblick über die Grundkonzepte der Holakratie zu bekommen. Es handelt sich dabei um ein Konzept zur Entwicklung von Organisationen, das zu mehr Agilität durch dezentrale Entscheidungsfindung und Ermächtigung der Mitarbeiter*innen führen soll.

Als Coach erklärte Dennis Wittrock, wie Aufgaben und Zuständigkeiten in Form von Rollen und Verantwortlichkeiten beschrieben werden. In der Holakratie geht es dann darum, wie die Regeln der Zusammenarbeit zwischen diesen Rollen vereinbart werden und wie ein Prozess der „verankerten Evolution“ dazu beiträgt, dieses Regelwerk beständig zu hinterfragen und anzupassen. Hinzu kommt eine ausdrückliche Ermächtigung der Beteiligten zum Handeln mit klaren Befugnissen und Grenzen. Zudem wird ausufernden Meetings mit unklarer Zielsetzung dadurch begegnet, dass es für zwei unterschiedliche Arten von Besprechungen feste Routinen und Strukturen gibt.

In einer simulierten Organisation mit vorgegeben Strukturen und Problemen hatten wir dann die Möglichkeit, eine praktische Besprechungssituation zu erproben.

Einsatz von KI im Kulturmarketing

Sehr interessant und stark besucht war der Workshop „Einsatz von KI im Kulturmarketing“ von Holger Kurtz, auch wenn der Begriff „KI“ für mein Empfinden sehr großzügig ausgelegt wurde.

Zunächst ging es darum, dass KI und allgemein statistikbasierte Bewertungs- und Prognoseverfahren immer eine gute Datenbasis als Ausganspunkt benötigen. Oft lägen diese notwendigen, gut strukturierten Daten in Kulturinstitutionen nicht in der benötigten Qualität vor. Ein erster Schritt müsse es daher sein zu fragen, welche Daten überhaupt benötigt werden, wie bzw. wo diese gesammelt werden könnten und was mit den Maßgaben der DSGVO vereinbar sei. Zudem brauche es festangestellte Personen im Haus, die ein grundlegendes Verständnis von IT-Fragestellungen hätten und einen Überblick darüber, über welche Daten die Einrichtung verfüge, wie diese strukturiert seien und zusammenhängen.

Als Beispiel wurde die Tate Gallery genannt, die mit einem eigenen Team von Data Scientists unter anderem automatisiert seher exakte Prognosen über die Besucherströme der nächsten Tage erstellen könnten, dazu aber auch über ein Dutzend Parameter aus verschiedenen Quellen zusammenführen müssten.

Es wurde dann Performance Marketing vorgestellt als die Art von Online-Werbung, bei der die Abrechnung auf Basis messbarer Interaktion erfolgt. Das können im einfachsten Fall Klicks auf die Anzeige sein. Noch besser ist es, wenn sich tatsächlich „Conversions“ (z. B. Kauf einer Eintrittskarte im Online-Shop) mit der Anzeige in Verbindung bringen lassen.

Bei diesen Werbeplattformen geht die Entwicklung dahin, dass nicht mehr fertige Werbebanner eingestellt und Zielgruppen ausgewählt werden. Werbeplattformen bekommen stattdessen eine Reihe von Bildern und einige Textvorschläge und beginnen damit eigenständig, Kombinationen und Varianten der Banner zu erstellen. Wenn die Plattform erkennt, dass eine Variante bessere Ergebnisse erzielt als andere, beginnt sie, diese Variante verstärkt auszuspielen. Sie sucht dabei automatisiert nach Mustern in den Nutzerprofilen, um „ähnliche“ Zielgruppen zu erreichen. Marketingverantwortliche stimmen also keine fertigen Anzeigen mehr ab oder definieren Zielgruppen, sondern müssen nur noch genug „Zutaten“ in ein solches System geben.

Wichtig dabei sei es zu verstehen, dass man nicht mehr die volle Kontrolle hätte über das, was letztlich ausgespielt werde, und dass man auch nie alle möglichen Anzeigen sehen würde. Erwähnt wurde ein Beispiel eines Kulturveranstalters, für den Anzeigen mit dem Schlagwort „Musical“ plötzlich sehr gut funktionierten und häufig angeklickt wurden – allerdings gab es überhaupt keine Musicals im Programmangebot.

Ein Thema für sich waren generative KI-Modelle, die im Moment hohe Aufmerksamkeit erfahren und Bilder oder Texte zu textbasierten „Prompts“ erzeugen können. Dieses Systeme bieten die Möglichkeit, auch ohne eigene Datensätze an einem Trend teilzuhaben, weil sie sich auf eine frei verfügbare, allgemeine Datenbasis stützen.

Beispiele für die Anwendung im Marketing sind die Erzeugung von Key Visuals oder realistisch anmutender Fotos, wenn solche Bilder z. B. für neue Produktionen noch gar nicht vorliegen oder aus Kostengründen nicht regelmäßig produziert werden können. Dabei ist es mit „Seeds“ (Voreinstellungen) möglich, auch bei wiederholter Anwendung einen einheitlichen Look zu erhalten.

Text-generierende Systeme könnten eine Unterstützung sein, um bei Routinetätigkeiten zu entlasten. Als Beispiel genannt wurde die immer wiederkehrende, ähnliche Formulierung von Theater- bzw. Abendzetteln auf Basis vorliegender Informationen über ein Stück oder die Künstler. Auch bei der Beantwortung von E-Mails im Kunden- und Besuchersupport könnten automatisch generierte Textvorschläge eine wesentliche Entlastung darstellen. Dabei sei immer zu bedenken, dass die von solchen Systemen generierten Antworten inhaltlich „halluziniert“ sein können. Es ist daher wichtig, dass fachlich versierte Menschen die Qualität und Korrektheit aller Aussagen prüfen.

Was will das digitale Publikum?

Am zweiten Konferenztag diskutierte zunächst ein sehr breit besetztes Panel die Frage, was „das digitale Publikum“ wünsche. Es wurde schnell klar, dass es „das Publikum“ gar nicht gibt. Beispielsweise Museen haben es bei einer interessierten Öffentlichkeit in Abgrenzung zu forschendem Fachpublikum mit so unterschiedlichen Gruppen zu tun, dass auch die Anforderungen an und Vorstellungen von „digitalen Angeboten“ sehr unterschiedlich ausfallen.

Die Gäste waren sich einig, dass digitale Inhalte dann sinnvoll sind, wenn sie einen Mehrwert schaffen. Als konkretes Beispiel wurde die Barrierefreiheit genannt, wenn also museale Angebote digital auch Menschen erreichen können, denen die Erfahrung vor Ort im Museum nicht möglich wäre. Dr. Gries ergänzte, dass „barrierefrei“ in Zukunft auch bedeuten könne, für Systeme der künstlichen Intelligenz so zugänglich zu sein, dass die Inhalte in das Training oder die Faktenbasis dieser Systeme einfließen können.

Prof. Dr. Patricia Rahemipour, Direktorin des Instituts für Museumsforschung, erwähnte zudem die Schwierigkeiten, die das Vergaberecht in der Praxis oftmals bereite. Es sei damit schwierig, Digitalprojekte durchzuführen und flexibel zu steuern. Oft sei es auch ein Problem, überhaupt ausreichend qualifizierte Bieter zur Teilnahme zu motivieren.

Marcus Lobbes, Direktor der Akademie für Theater und Digitalität, konstatierte, Theater hätten lange Zeit ihr Wissen und ihre Erfahrungen im Zusammenhang mit der Digitalisierung für sich behalten. Es habe kein Austausch darüber stattgefunden, was Projekte kosten, wie man bestimmte Probleme gelöst habe, wer welche Kompetenzen beisteuern könne und vor allem auch, mit welchen Versuchen man gescheitert sei. Mit der Initiative „Theaternetzwerk digital“ soll sich das ändern.

Agilität in Organisationen

„Wie bewegen wir unsere Organisation?“ war die Frage des nächsten Panels, das mit einer Kurzvorstellung der Holakratie (s. oben) begonnen wurde.

Doreen Mölders, Leiterin des LWL-Museum für Archäologie und Kultur, beschrieb, wie ihr Haus dazu den „Fonds Digital“ der Kulturstiftung des Bundes in Anspruch genommen hat. Im Rahmen der Organisationsentwicklung gehe es darum, eine „Kultur der Digitalität“ und digitale Arbeitsweisen zu etablieren. Tarifverträge und notwendige Stellenbeschreibungen machten es dabei noch sehr schwer, Ideen wie die der Holakratie umzusetzen. Trotzdem sei es aber möglich, feste Strukturen schrittweise zu lösen und zu ändern, wenn man den Mitarbeitenden das dazu notwendige Vertrauen und Empathie entgegenbringe.

Im nächsten Jahr werde es in ihrem Haus darum gehen, ein neues Leitbild für diesen Wandel zu entwickeln. Das Museum plane, in dieser Zeit das Angebot und Ausstellungsprogramm so zu reduzieren, dass für alle Mitarbeitenden ausreichend Gelegenheit bestehe, sich in diesen Prozess einzubringen. Das Ziel müsse es sein, Entscheidungen möglichst schnell da treffen zu können, wo sie gut getroffen werden können. Die notwendige fachliche Expertise dazu befinde sich oft in den Fachbereichen, nicht in der Führungsebene.

Michael Wuerges gab als Direktor der Kommunikation der Bayerischen Staatsoper einige Einblicke in die Struktur eines der größten Opernhäuser weltweit, das mit über 1000 Mitarbeiter*innen täglich über 2000 Karten verkaufen müsse. Die lange Tradition mit eingefahrenen Strukturen, „mächtigen Intendanten“ und auch vielen, oft wechselnden Mitwirkenden im künstlerischen Bereich machen es sehr schwer, organisatorische Änderungen zu erwirken oder ein gemeinsames Leitbild zu entwickeln.

Eine interessante Frage im Laufe der Diskussion war die nach der rechtlichen Haftung, wenn mehr Verantwortung auf die Mitarbeiter*innen übertragen werde. Die in meinen Augen korrekte Schlussfolgerung war, dass so oder so am Ende Führungskräfte „den Kopf hinhalten“ müssen. Trotzdem - oder gerade deshalb - sollte es diesen aber im Innenverhältnis der Organisation möglich und erlaubt sein, eine „stützende Struktur“ zu schaffen, mit der sie Verantwortung intern ab- und weitergeben können, um so den Kopf frei zu haben für die wesentlichen Entscheidungen und um sicherzustellen, dass die Entscheidungen mit größtmöglicher Expertise und aus verschiedenen Perspektiven heraus beurteilt werden können.

Was muss Führung leisten?

„Das Zeitalter des Leitwolfs ist vorbei“ war die Überschrift zum letzten Konferenzteil. Julia Becker, Aufsichtsratsvorsitzende der Funke Mediengruppe, stellte das Leitbild von Führung vor, das unter ihrer Leitung in den letzten Jahren entwickelt wurde, um auf massive Veränderungen der Medienbranche in den letzten Jahren zu reagieren.

Auch in diesem 10-Punkte-Programm geht es wesentlich darum, die Eigenverantwortung und Kompetenz der Mitarbeitenden zu stärken. „Agression und Isolationismus“ funktionierten nicht als Führungsstil, Empathie sei der Schüssel für gelungene Führung. Führung komme die Aufgabe als „Dirigent“ zu, aber nicht im Sinne eines streng geführten Symphonieorchesters, sondern im Stil einer Jazzband. „Jeder darf mal ein Solo spielen“, Unternehmensteile müssten sich in alle Richtungen austauschen können, statt in Silos zu denken. Zur Aufgabe von Führung gehöre es, das zu ermöglichen, dazu anzuhalten und es einzufordern.

Im abschließenden Gespräch mit Diandra Donecker, Geschäftsführerin und Gesellschafterin im Auktionshaus Grisebach, wurde die Arbeit und Unternehmenskultur in Organisationen und einem Marktumfeld thematisiert, das weiterhin überwiegend männlich dominiert sei. Frau Donecker sah einen Schlüssel zur Veränderung darin, für mehr Diversität in Unternehmen und Organisationen zu sorgen. Gerade für Führungspersonen sei es wichtig, ehrlich und offen zu sein und auch über eigene Fehler zu sprechen.

Roundup

Zum Abschluss möchte ich noch die gelungene Art der Moderation erwähnen, mit der Vorträge und Panels verbunden und dokumentiert wurden. Zu jedem Thema gab es während der Diskussion gefüllte Stichwortlisten aus den Blickwinkeln „Das gibt uns Schub“ und „Das hält uns zurück“. Mit dem Online-Tool „Mentimeter“ wurde direkt in Anschluss an die Gesprächsrunden live abgestimmt, welche Thesen und Fragen den größten Zuspruch unter den Teilnehmer*innen erhielten.

Wenn sehr alte Browser vollumfänglich unterstützt werden sollen, macht das die Weiterentwicklung sehr aufwändig und verhindert die Nutzung neuer Möglichkeiten. Auf der anderen Seite besteht bei der Definition einer solchen (Browser) Support Matrix besteht immer die Gefahr, dass ältere und nicht unterstützte Kombinationen von Geräten, Betriebssystemen und Browsern überhaupt keinen Zugriff auf Inhalte mehr bekommen. Da wir überzeugt davon sind, dass zumindest die Kerninformationen und -funktionen allen Besucher*innen zur Verfügung stehen sollten, stellen wir eine rein funktionale und gestalterisch reduzierte Version der Website für alle Browser bereit.

Technisch folgen wir den Grundprinzipien des Progressive Enhancement und setzen diese mit einer Variante von Yahoo's Graded Browser support um. Unsere Browser Support Matrix teilt demnach Browser nach Version in eine von zwei Stufen ein:

Functional ist unsere universelle Un­­ter­­­stüt­zungs­stufe. Wir stellen allen Brow­sern auf dieser Stufe serverseitig ge­ren­dertes seman­tisches HTML sowie mini­ma­les CSS und Java­Script zur Verfü­gung. We­sen­tliche Funk­tionen und Inhal­te müssen auf dieser Stufe zugäng­lich sein.

Enhanced ist unsere Unterstützungsstufe für moderne und/oder Evergreen-Browser. Sie ist so angelegt, dass sie immer auf die große Mehrheit aller Besucher*innen zutrifft (mind. 95%). Zusätzlich zur Kernfunktionalität stellen wir diesen Browsern JavaScript und fortgeschritteneres CSS zur Verfügung, um ihnen ein interaktiveres und visuell ansprechendes Besuchserlebnis zu bieten.

Zur detaillierten Erstellung einer Browser Support Matrix gibt es nach unserer Ansicht keine sinnvollen Branchenstandards, da die tatsächlich verwendeten Browser stark vom Zielpublikum, Markt etc. der einzelnen Website abhängen:

• Manche Angebote werden eher von jüngeren Besuchern genutzt, andere von älteren
• Der Grad der Technikaffinität der Besucher unterscheidet sich
• Je nach Website gibt es unterschiedliche Nutzungspräferenzen (Desktop vs. Tablet vs. Smartphone, …).

Unser Vorgehen ist es daher, die Anforderungen basierend auf den Statistiken der konkreten Website festzulegen, um die es geht – oder einer oder mehrerer möglichst gut vergleichbaren mit ähnlicher Zielgruppe.

Im Sommer 2023 nutzen wir als Grundlage einer kunden- und website-spezifischen Matrix die folgende Tabelle:

Um Erkenntnisse aus website-spezifischen Nutzungsstatistiken erweitert führt unsere Arbeitsweise dazu, dass wir selbst in 2023 noch eine Website betreuen, für die wir den Internet Explorer 11 in der "Enhanced"-Kategorie unterstützen – allerdings beobachten wir auch hier in den Statistiken seit 2021 einen deutlichen Rückgang der Nutzungsanteile und werden den aktiven Support zum Jahresende auslaufen lassen. Kein Wunder, denn Microsoft hat den Internet Explorer am 15.06.2022 offiziell in Rente geschickt und entfernt seitdem automatisch alle installierten Versionen bei Windows-Updates.

Es gibt (noch) keine einheitliche, gemeinhin akzeptierte Definition von „Green IT“. Verschiedene Einrichtungen des Bundes, Branchenverbände und große Anbieter von IT- und Cloud-Services stimmen aber darin überein, dass es um Maßnahmen zur umwelt- und ressourcenschonenden Nutzung von IT- und Kommunikationsdiensten über den gesamten Lebenszyklus hinweg geht.

Ressourcenschonender Betrieb der Rechenzentren

Sowohl die „Green IT Initiative“ des BMUV wie auch das ITZBund sehen im Betrieb von IT-Rechenzentren den mit Abstand größten Hebel zur Erreichung der genannten Ziele.

webfactory nutzt für das Webhosting Cloud-Services von Amazon Web Services (AWS). Die Maßnahmen von AWS zur Nachhaltigkeit im IT-Betrieb sind auf einer eigenen Website beschrieben. 

Zu den wesentlichen Eckdaten gehören:

• Die von uns genutzten Rechenzentren der Region Frankfurt wurden bereits 2022 mit 100% Strom aus erneuerbaren Quellen betrieben. Im weltweiten Betrieb von AWS lag der Anteil bei 90% und soll 2025 100% erreichen.

• Als weltgrößter Anbieter von Cloud-IT-Diensten hat AWS herausragende Möglichkeiten, den Betrieb der Rechenzentren im Hinblick auf Effizienz zu optimieren. Der Betrieb virtualisierter IT in diesem Maßstab ermöglicht es,die Auslastung vorhandener Hardware zu maximieren und damit die Effizienz zu steigern (Skaleneffekte).Beispielsweise können IT-Betriebsmittel besser entsprechend dem (prognostizierten) Bedarf gestartet oder gestoppt werden. Studien bescheinigen AWS, den Betrieb der Rechenzentren 5-fach energieeffizienter zu realisieren als durchschnittliche europäische Rechenzentren.

• Seit 2020 ist es AWS gelungen, die Nutzungsdauer von Servern von drei auf fünf Jahre und bei Netzwerkkomponenten von fünf auf sechs Jahre zu verlängern, was den Ressourcenverbrauch über die gesamte Wertschöpfungskette reduziert.

Ressourceneffizienz der entwickelten Software/Websites

Auch durch die Architektur und Programmierung von Webanwendungen und Websites lassen sich Einsparungen erzielen, die eine positive Auswirkung auf den Energieverbrauch entlang der gesamten Verarbeitungskette (Serverbetrieb, Netzwerke, Endgeräte) haben.

Die folgenden Maßnahmen haben zugleich unmittelbare Auswirkungen auf die von Endnutzer*innen wahrgenommene Performance der Website. Sie entsprechen damit einem unserer Grundprinzipien der performanceoptimierten Entwicklung, die wir auf unsere Seite über Performanceoptimierung beschrieben haben.

• HTTP-Caching: Ein Großteil der typischen Anfragen an Webserver kann mit identischen Antworten bedient werden. Das gilt auch für die meisten Seiten beim Einsatz eines CMS: Wenn zwischen zwei Anfragen keine Änderungen über das CMS erfolgt sind (und weitere Bedingungen erfüllt werden), können vorherige Ergebnisse erneut ausgeliefert werden. Es entfällt die vollständige serverseitige Verarbeitung, Datenbankabfragen und das Rendering von Templates. Es wird CPU-Zeitgespart und die Antwortzeiten für Nutzer*innen werden deutlich reduziert.

• Einsatz von Content Delivery Networks (CDN): Die Zwischenspeicherung der Antworten auf Servern in geographischer Nähe zu Nutzer*innen reduziert die über Netzwerke zu übertragende Datenmenge und Distanz, was letztlich Energie einspart und Ladezeiten verbessert.

• Browser-Caching: Durch geeignete Maßnahmen versuchen wir, möglichst viele Inhalte direkt im Browser-Cache nutzbar zu halten. Damit müssen einmalig geladene Inhalte bestenfalls nicht wieder beim Server angefragt werden.

• Konsequente Optimierung eingesetzter JavaScript-Bibliotheken und Stylesheets: Gängige JavaScript-Programmbibliotheken erfordern oft die Übertragung vieler hundert Kilobyte JavaScript-Code an den Browser, bevor mit der Darstellung der Seite begonnen werden kann. Wir achten bei der Auswahl von Bibliotheken auf denspäter damit bei Nutzer*innen verbundenen Ressourcenaufwand. Durch den Einsatz entsprechender Werkzeuge optimieren wir die Größe der zu übertragenden Stylesheets, JavaScript-Bibliotheken u. ä.

Fazit zu Green IT bei der webfactory

Unsere Websites werden in einem hocheffizienten und damit ressourcenschonenden Rechenzentrum mit Strom aus erneuerbaren Energiequellen betrieben. Auch bei der Entwicklung achten wir auf vielfältige Weise auf Ressourceneffizienz: Unsere Websites und Webanwendungen sind so programmiert, dass nicht mehr Rechenoperationen erfolgen, als für die Auslieferung der Website unbedingt nötig sind. Daten und Programmcode, die nicht erforderlich sind, werden gar nicht erst an den Browser des Besuchers übertragen.

Seiten, die von vielen Besuchern aufgerufen werden, werden nicht immer neu generiert, sondern von einem Zwischenspeicher, der regional in der Nähe des Besuchers liegt, ausgeliefert. So entsteht kein erneuter Rechenaufwand und die Daten müssen nur über eine kurze Strecke transportiert werden.

Statt in Panik auszubrechen, entschieden sich die Teammitglieder der Webfactory jedoch für eine ungewöhnliche Herangehensweise. Mit ihrer technischen Expertise begannen sie, improvisierte Zombieabwehrsysteme zu entwickeln. Statt Waffen setzten sie auf Computerkabel, Tastaturen und Mauspfeile, um die Zombies auf Distanz zu halten.

Die Designer entwarfen spezielle Zombie-Abwehr-Apps, die grelle Farben und hypnotische Muster nutzten, um die Zombies zu verwirren. Die Entwickler hackten sich in die Zombiesoftware ein und starteten ein Zombie-Tanzpartyprogramm, das die untoten Kreaturen in eine chaotische Tanzperformance verwickelte.

In der Webfactory herrschte bald ein unerwartetes Chaos aus Zombies, tanzenden Entwicklern und fliegenden Tastaturen. Doch trotz der gruseligen Umstände hatten die Teammitglieder ihren Humor nicht verloren. Sie nannten sich nun scherzhaft das "Zombieabwehr-Team" und kämpften auf ihre eigene verrückte Weise gegen die Apokalypse an.

Mit ihrem erfinderischen Geist und ihrer Fähigkeit zur Zusammenarbeit gelang es dem Team schließlich, die Zombie-Apokalypse in der Webfactory zu besiegen. Die Zombies wurden schließlich von ihren eigens entwickelten Abwehrsystemen in die Flucht geschlagen und die Büros kehrten zu ihrer Normalität zurück.

Diese unvergessliche Episode in der Geschichte der Webfactory führte nicht nur dazu, dass die Teammitglieder enger zusammenrückten, sondern auch zu einer neuen Tradition: jedes Jahr feierten sie den "Zombieabwehrtag", an dem sie ihre unkonventionellen Kreationen und ihre Fähigkeit zur Bewältigung unerwarteter Herausforderungen feierten.

Benutzeraccounts und Passwörter sind Teil unserer täglichen Arbeit, und natürlich ist auch ihre Angreifbarkeit ein wiederkehrendes Thema. Dabei geht es nicht nur darum, wie wir Passwörter möglichst sicher speichern, sondern oft auch um Fragen wie "Ginge das auch ohne Passwort?" oder "Was ist hier der bestmögliche Kompromiss aus Sicherheit und Nutzerfreundlichkeit (UX)?". Bereits 2019 haben wir unsere diesbezüglichen Erfahrungen und Lösungsideen in einen Vortrag auf einem regionalen Meetup gegossen.

Mit Maschinen gegen die Maschinen vorgehen: Passwortmanager

Ein Schwerpunkt des damaligen Vortrags war das Dilemma, dass es für Maschinen durch stetig steigende Rechenleistung immer einfacher wird, Passwörter zu knacken – während wir Menschen immer mehr unter den immer neuen Anforderungen an "sichere" Passwörter (Groß- und Kleinschreibung! Zahlen! Sonderzeichen! Mind. ein Konsonant aus phönizischer Keilschrift!) leiden. Experten sind sich seit langem einig: mit die beste Chance gegen Maschinen bieten uns andere Maschinen, in diesem Fall Passwortmanager. Die können nicht nur zufallsgeneriert sehr lange Zeichenketten generieren und sich für uns merken, sie unterstützen uns vor allem dabei, für jeden Login ein anderes Passwort zu nutzen.

Das sind direkt drei Vorteile:

• Echte zufallsbasierte Passwörter haben keine Verwundbarkeit gegenüber sogenannten Wörterbuchattacken, die, salopp gesagt, ein Buch wie den Duden nehmen und beliebig viele Kombinationen echter Wörter, z. T. mit leichten Modifikationen, testen. Ein "passwort" würde von einem Angreifer genauso gefunden wie ein "ichbraucheurlaub" oder sogar ein vermeintlich cleveres "sup3rgehe1m".
• Passwortmanager nutzen den gesamten erlaubten Zeichensatz, und wenn wir uns ein Passwort nicht merken müssen, ist es für uns irrelevant, ob es 8, 32 oder 64 Zeichen lang ist. Wichtig hierbei: die Zahl möglicher Varianten, die bei einer sogenannten "Brute-Force-Attacke" automatisiert getestet werden müssten, steigt exponentiell mit jedem weiteren Zeichen. Ein schlechter Vergleich: wenn man den Code vergessen hat, ist ein Fahrradzahlenschloss mit 3 Ringen (und 1.000 möglichen Kombinationen) vielleicht gerade noch so an einem Nachmittag durchprobierbar — bei einem mit 5 Ringen (100.000 mögliche Kombinationen) müsste man dagegen schon sehr leidensbereit sein und deutlich mehr Zeit investieren.
• Für jeden Account ein einzigartiges Passwort zu benutzen ist eine simple und effiziente Methode, sich gegen Datenpannen abzusichern. Das Hasso-Plattner-Institut schreibt dazu:

"Täglich werden persönliche Identitätsdaten durch kriminelle Cyberangriffe erbeutet. Ein Großteil der gestohlenen Angaben wird anschließend in Internet-Datenbanken veröffentlicht und dient als Grundlage für weitere illegale Handlungen."

Ist man von einem Datenleck betroffen, besteht eine erhöhte Gefahr, dass ein verwendetes Passwort entschlüsselt und für immer in Angriffsdatenbanken aufgenommen wird. Solange das Passwort aber nur für eine Plattform verwendet wurde, ist zumindest die Sicherheit aller anderen Dienste nicht betroffen.

Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt daher den Einsatz eines Passwortmanagers.

Datenpannen, geleakte Passwörter und gute UX

Moderne Passwortmanager bieten oft noch einen weiteren Vorteil: sie sind in der Lage, gespeicherte Passwörter gegen Listen bei Datenpannen erbeuteter Zugangsdaten zu testen und eine Warnung auszugeben, wenn ein vermeintlich sicheres Passwort bereits Teil einer Datenpanne war.

Wir sind überzeugt davon, dass Sicherheit ein Bestandteil guter UX ist – und gute UX Sicherheit schaffen kann. Und wir wissen auch, dass lange nicht alle Nutzerinnen und Nutzer der von uns betreuten Webseiten einen Passwortmanager einsetzen. Schon seit langem war es uns daher ein Anliegen, einen vergleichbaren Service auch selbst anzubieten, und letztes Jahr konnten wir die Funktionalität als Teil eines Anpassungsauftrags für die Extranets des Gemeinsamen Bundesausschusses (G-BA) umsetzen.

Bei der Vergabe eines neuen Passworts erfolgt nun automatisch eine Abfrage über den Dienst haveibeenpwned.com des renommierten Sicherheitsexperten Troy Hunt, und das neue Passwort wird nur akzeptiert, wenn es noch nicht Teil eines Datenlecks war. Erfreulicherweise bietet das von uns eingesetzte Open Source Framework Symfony diesen Überprüfungsschritt für Passwortfelder seit 2019 standardmäßig an.

Bei der Überprüfung wird natürlich kein Passwort übermittelt; tatsächlich erfolgt der Test sogar auf eine derartig ausgeklügelte Weise, dass die übertragenen Daten dem Anspruch der k-Anonymität genügen. Da Troy Hunt oft auf die Sicherheit seines Dienstes angesprochen wird, hat er die zugrundeliegende Methodik in seinem Blog detailliert (in englischer Sprache) beschrieben.

Bei uns war unmittelbar nach dem Launch des neuen Features die Freude groß, denn unsere Ansprechpartnerin schrieb uns folgende E-Mail:

Liebe webfactory,

vielen Dank für die Umsetzung.

Ich habe die Funktion ausprobiert und konnte mein Passwort ändern.

Allerdings ist mir aufgefallen, dass ich meine Passwörter mal ändern sollte, weil Ihr Sicherheitscheck bei mir angeschlagen hat.

Nun denn..

Ein voller Erfolg!

Das Hasso-Plattner-Institut veröffentlicht übrigens jedes Jahr eine Liste der "beliebtesten deutschen Passwörter".

Die Top Ten für 2022 war angeblich:

1. 123456
2. 123456789
3. 1Qaz2wsx3edc
4. 12345
5. password
6. qwertz
7. ficken
8. 12345678
9. passwort
10. Ebels123

Nun denn.

Matthias, Jano und ich haben dafür mehrere Tage zuvor den Tagesablauf geplant und alle nötigen Vorbereitungen getroffen.

Da dies nicht unser erster Girls'Day war, konnten wir mit den bisher gesammelten Erfahrungen den Tag wie folgt strukturieren:

1. Ankommen und Ankoppeln
2. Front-End
3. Back-End
4. Mittagspause
5. Projektmanagement
6. Konzeption
7. Abschluss und Feedback

Jeden Bereich unserer Arbeit haben wir mit einer kurzen inhaltlichen Vorstellung begonnen, gefolgt von Phasen, in denen die Mädchen selber kreativ werden konnten.

Dabei wurden sie kurzerhand selber zu Front- und Back-End-Entwicklern und haben mit HTML-Elementen und CSS-Befehlen ihre eigene kleine Website gestaltet und in scratch.org die Welt der Programmierung kennengelernt. Gestärkt durchs Mittagessen mussten sie dann gemeinsam den Projektablauf eines neuen Schulrucksacks planen. Und zu guter Letzt: ihre eigene Website planen, gestalten und anschließend ihren Mitstreiterinnen vorstellen.

Einige Mädchen hatten sogar schon Vorkenntnisse im Bereich der Webentwicklung und haben beispielsweise in der Schule schon mit scratch.org gearbeitet. Somit konnten sie sich untereinander helfen und im Team arbeiten (ähnlich wie wir das auch machen ;-) ).

Insgesamt hatten nicht nur die Teilnehmerinnen, sondern auch wir viel Spaß am Girls'Day. Ich persönlich fand es sehr spannend zu sehen, welche tollen Websites in der Konzeptionsphase entstanden sind:

Die Webseite "KickBox" legt den Fokus auf den Sport des Kickboxens und bietet die Möglichkeit, passende Ausrüstung direkt über den integrierten Shop zu erwerben.

Die Webseite "LeCaLi" widmet sich dem Reitsport und bietet im Shop alles, was das Herz eines jeden Pferdeliebhabers begehrt. Durch den Angebotsbereich lassen sich auch richtige Schnapper ergattern.

Abschließend wurde der Tag noch in einer kleiner Feedback-Runde nach der "Fünf Finger"-Methode rekapituliert.

Wir freuen uns schon auf das nächste Jahr <3!

Die webfactory ist in vielen Projekten für öffentliche Auftraggeber tätig, teilweise seit über 20 Jahren. Öffentliche Auftraggeber sind verpflichtet, bei der Erteilung von Aufträgen das Vergaberecht zu beachten. Dieses sieht vor, dass Aufträge grundsätzlich öffentlich oder zumindest wettbewerblich ausgeschrieben werden müssen und dass Rahmenvereinbarungen auf 4 Jahre begrenzt sein müssen (§21 Abs. 6 VgV). Immer wieder stellt sich daher die Frage, inwiefern unsere Art und Weise der langfristigen Zusammenarbeit vom Vergaberecht gedeckt ist. Müssen Aufträge für Betrieb und Weiterentwicklung zeitlich begrenzt sein, mit der Möglichkeit, dass das System alle paar Jahre in die Hände eines anderen Auftragnehmers gegeben wird? Muss ein System gar alle paar Jahre neu programmiert werden?

Softwareentwicklung als Theoriebildung

Um diese Frage zu beantworten, sollte man sich zuerst bewusst machen, worum es bei Softwareentwicklung geht: ein Modell der Realität zur Lösung einer bestimmten Aufgabe.

Peter Naur hat bereits 1985 in seinem Aufsatz "Programming as Theory Building" dargelegt, wie eng eine Software an die Menschen gebunden ist, die sie entwickelt haben. Der Aufsatz wurde im 2006 erschienenen Buch "Agile Software Development: A Cooperative Game" von Alistair Cockburn nachgedruckt und ist auch heute noch aktuell.

Naur legt dar, dass Softwareentwicklung als eine Tätigkeit gesehen werden sollte, bei der die Programmierer Erkenntnisse gewinnen und eine Theorie des relevanten Ausschnitts der Welt entwickeln. Er stellt dies in Kontrast zu der Wahrnehmung, bei Softwareentwicklung ginge es in erster Linie um die Produktion eines Programms und weiterer begleitender Textdokumente. Die Theorie, die bei dieser Tätigkeit entsteht und auf der die Software basiert, ist untrennbar an Personen gebunden, es handelt sich um implizites Wissen.

Folgende Gründe nennt Naur dafür, dass das Wissen, das der Entwickler über die Software hat, über das in Form von Code und Dokumentation niedergeschriebene Wissen hinausgeht:

1. Der Entwickler, der die Theorie hinter der Software kennt, kann erklären, wie sich die Lösung zu dem Ausschnitt der Realität verhält, den sie zu handhaben hilft. Diese Erklärung erstreckt sich auch darauf, welche Dinge der realen Welt in welchem Detailgrad in der Software abgebildet sind. Er kann für jeden Teil der Software erklären, welchen Aspekt der Welt sie abdeckt, und umgekehrt für jeden Aspekt der Welt sagen, ob und wie er in der Software berücksichtigt ist. Die Frage, welche Aspekte der Welt in der Software abgebildet werden müssen, setzt eine fundierte Kenntnis dieser relevanten (Fach-) Welt voraus.
2. Der Entwickler, der die Theorie hinter der Software kennt, kann erklären, warum jeder Teil des Programms so geschrieben ist, wie er ist. Er kann also den Programmcode begründen.
3. Der Entwickler, der die Theorie hinter der Software kennt, kann konstruktiv auf Änderungsbedarfe reagieren. Die Entscheidung, wie eine Änderung am besten vorgenommen werden kann, und die Gestaltung dieser Änderung hängen davon ab, wie ähnlich der neue Bedarf zu den bereits in der Software vorhandenen Fähigkeiten ist. Die Beurteilung dieser Ähnlichkeit setzt das oben beschriebene Wissen sowohl über die Software als auch über die von ihr abgebildete Realität voraus, das nur der Entwickler hat.

Wird eine Software von Entwicklern ohne angemessenes Verständnis ihrer Theorie angepasst, degeneriert sie mit der Zeit. Denn es kommen stets verschiedene technische Lösungen für die Umsetzung neuer Anforderungen in Frage, die alle technisch korrekt funktionieren. Aber nur, wenn sie der Theorie entsprechen, entwickelt sich die Software in einem stimmigen Gesamtbild weiter. Wenn sie dagegen der Theorie widersprechen, wirkt die Software zunehmend wie ein Flickwerk, dessen Zerfaserung nur mit groben Nähten aufgehalten wird. All diese Nähte können das Verständnis der Software und damit ihren Betrieb und künftige Weiterentwicklungen erschweren. Nur Entwickler, die die Theorie hinter der Software kennen, sind in der Lage, die Lösungen dahingehend zu bewerten, ob sie dieser Theorie entsprechen oder widersprechen.

Daraus folgert Naur, dass eine Software nur als lebendig angesehen werden kann, solange ein Team, das die Theorie der Software besitzt, mit ihrer Weiterentwicklung betraut ist und die Kontrolle über alle Modifikationen hat. Eine Software stirbt demnach, wenn das Entwicklerteam, das die Theorie besitzt, aufgelöst wird. Eine solche tote Software kann zunächst weiter genutzt werden, aber der Tod wird sichtbar, wenn Weiterentwicklungsbedarfe nicht mehr intelligent umgesetzt werden können.

Die Theorie hinter der Software kann neuen Entwicklern vermittelt werden, indem diese intensiv und über längere Zeit mit den ursprünglichen Entwicklern zusammenarbeiten. Dadurch werden die neuen Entwickler vertraut mit dem Stellenwert der Software im Kontext verschiedener Situationen der realen Welt und bauen das Wissen auf, wie die Software funktioniert und wie außergewöhnliche Situationen und Änderungsanforderungen in ihrer Theorie abgebildet werden. Die Vermittlung einer solchen existierenden Theorie an neue Entwickler ist sehr ähnlich zur Vermittlung anderer Fähigkeiten, bei denen es mehr darum geht, zu lernen, wie etwas getan wird, als darum, sich Faktenwissen anzueignen. Solche Tätigkeiten sind zum Beispiel das Schreiben oder das Spielen eines Instruments. Naur hält fest, dass die wichtigste Lernaktivität bei solchen Fähigkeiten darin besteht, dass der Schüler relevante Tätigkeiten unter der Beobachtung und Anleitung seines Lehrers ausübt. Im Falle der Softwareentwicklung sollte diese Anleitung Diskussionen über das Verhältnis zwischen der Software und den relevanten Aspekten und Aktivitäten der realen Welt beinhalten, ebenso wie über die Grenzen der in der Software vorgenommenen Abbildung der Realität.

Eine tote Software könnte laut Naur theoretisch wiederbelebt werden, indem ein neues Team die Theorie zur existierenden Software erneut entwickelt. Das ist allerdings ohne Kontakt zu Personen, die die Theorie noch besitzen, aus seiner Sicht praktisch unmöglich und wird jedenfalls teurer sein, als die Software neu zu entwickeln.

Neuentwicklung statt Weiterentwicklung?

Man könnte nun versucht sein, zu fordern, dass Software folglich regelmäßig neu entwickelt werden müsste, wenn die Weiterentwicklung der Software ausgeschrieben werden muss und eine Arbeit mit dem existierenden Quellcode ohne die zugrundeliegende Theorie nicht möglich ist.

Das würde zum einen bedeuten, dass die komplette Investition, die in die Entwicklung der Software geflossen ist, erneut getätigt werden müsste. Es ist aus meiner Sicht zumindest fraglich, ob das mit dem Wirtschaftlichkeitsgebot aus dem Haushaltsrecht vereinbar ist (siehe hierzu Softwareentwicklung für öffentliche Auftraggeber).

Zum anderen würde das aber auch voraussetzen, dass es überhaupt möglich ist, die existierende Software neu zu entwickeln. Dies ist mit einem erheblichen Projektrisiko und einem hohen Zeitaufwand verbunden, der benötigt wird, um überhaupt nur den aktuellen Status Quo wiederherzustellen – ohne dass die benötigte Weiterentwicklung damit auch nur begonnen wäre. In den meisten Fällen wird die Weiterentwicklung schneller benötigt werden als eine komplette Neuentwicklung des Systems abgeschlossen werden könnte. Eine solche Neuentwicklung bringt zudem auch das Problem der Datenmigration von der alten in die neue Struktur mit sich.

Hinzu kommt, dass eine Neuentwicklung bestehender Lösungen knappe volkswirtschaftliche Ressourcen – Softwareentwickler – binden würde, die dann nicht für die Entwicklung innovativer Lösungen für noch ungelöste Probleme zur Verfügung stehen.

Die Neuentwicklung bestehender Systeme sollte daher die Ausnahme und nicht die Regel sein.

Das passende Vergabeverfahren

Wie oben gezeigt, ist es für die langfristige erfolgreiche Weiterentwicklung komplexer Systeme existenziell, dass ein Entwicklerteam, das die Theorie hinter der Software besitzt, diese Weiterentwicklung vornimmt. Das Team hat damit einzigartiges technisches Wissen über die Software.

Und hierfür wiederum kennt das Vergaberecht einen entsprechenden Tatbestand: Gemäß §14 Abs. 4 Nr. 2 der Vergabeverordnung kann der öffentliche Auftraggeber Aufträge im Verhandlungsverfahren ohne Teilnahmewettbewerb vergeben, wenn der Auftrag nur von einem bestimmten Unternehmen erbracht werden kann, weil aus technischen Gründen kein Wettbewerb vorhanden ist.

In jurisPK-Vergaberecht heißt es dazu:

Führt eine rechtmäßige Leistungsbestimmung dazu, dass die Leistung nur noch von einem Unternehmen zu erbringen ist, erfüllt dies zunächst den Tatbestand des technischen Alleinstellungsmerkmals. Es besteht daher ein von der deutschen Rechtsprechung geprägter direkter Zusammenhang zwischen dem Leistungsbestimmungsrecht des öffentlichen Auftraggebers und dem Verhandlungsverfahren ohne Teilnahmewettbewerb aufgrund technischen Alleinstellungsmerkmals. OLG Düsseldorf: „Sind die vergaberechtlichen Grenzen der Bestimmungsfreiheit des öffentlichen Auftraggebers indes eingehalten, sofern die Bestimmung durch den Auftragsgegenstand sachlich gerechtfertigt ist, vom Auftraggeber dafür nachvollziehbare objektive und auftragsbezogene Gründe angegeben worden sind und die Bestimmung folglich willkürfrei getroffen worden ist, solche Gründe tatsächlich vorhanden (festzustellen und notfalls erwiesen) sind und die Bestimmung andere Wirtschaftsteilnehmer nicht diskriminiert. Bewegt sich die Bestimmung in diesen Grenzen, gilt der Grundsatz der Wettbewerbsoffenheit der Beschaffung nicht mehr uneingeschränkt." (OLG Düsseldorf v. 01.08.2012 - Verg 10/12 und im Anschluss OLG Düsseldorf v. 12.02.2014 - VII-Verg 29/13, Verg 29/13 - juris.)

Ortner in: Heiermann/Zeiss/Summa, jurisPK-Vergaberecht, 6. Aufl., § 14 VgV (Stand: 15.09.2022)

Der Kommentar zur VgV/UVgO von Malte Müller-Wrede konkretisiert:

Dem Rückgriff auf § 14 Abs. 4 Nr. 2 VgV steht grundsätzlich nicht entgegen, dass das Vorliegen der Tatbestandsvoraussetzungen dem öffentlichen Auftraggeber zuzuschreiben ist. Im Falle des § 14 Abs. 4 Nr. 2 VgV übt der öffentliche Auftraggeber stets einen gewissen Einfluss auf das Vorliegen der Tatbestandsvoraussetzungen aus, denn er gibt die Leistungsanforderungen vor, die dann nur von einem Unternehmen erfüllt werden können. Aber auch das Zutun des öffentlichen Auftraggebers zum Erwerb der Monopolstellung durch ein Unternehmen ist im Rahmen des § 14 Abs. 4 Nr. 2 VgV unbeachtlich. So sind singuläre technische Fähigkeiten infolge einer vorangegangenen Beauftragung durch den öffentlichen Auftraggeber gerade typische Folge des Leistungswettbewerbs. Anderes könnte allenfalls dann diskutiert werden, wenn die vorangegangene Beauftragung und die hieraus folgende Monopolstellung unter Missachtung des Vergaberechts erlangt wurden. Jedoch kann die Rechtswidrigkeit der vorangegangenen Beauftragung nach hier vertretener Auffassung nicht auf das neue Vergabeverfahren durchwirken. Sie muss im jeweiligen Vergabeverfahren angegriffen werden.

Müller-Wrede in: Müller-Wrede, VgV / UVgO - Kommentar, 5. Aufl. 2017,§ 14 VgV Wahl der Verfahrensart

Mit dem Verständnis von Softwareentwicklung als Theoriebildung und im Hinblick auf die große Bedeutung impliziten Wissens für die erfolgreiche Weiterentwicklung scheint es eindeutig, dass § 14 Abs. 4 Nr. 2 VgV hier zum Tragen kommen muss.

Müller-Wrede betont auch, dass der öffentliche Auftraggeber darlegen muss, dass einer oder mehrere der in §14 Abs. 4 Nr. 2 VgV genannten Gründe zwingend die Vergabe an ein bestimmtes Unternehmen erfordern. Er weist des Weiteren darauf hin:

Gelingt dies, so ist ein Wettbewerb um den öffentlichen Auftrag tatsächlich unmöglich und die Durchführung eines wettbewerblichen Vergabeverfahrens obsolet. Eine dennoch erfolgende Bekanntmachung oder Aufforderung von Unternehmen zur Angebotsabgabe würde eine tatsächlich nicht bestehende Zuschlagschance suggerieren.

Gilt das für alle Unternehmen?

Wichtig scheint mir noch die Feststellung, dass die oben dargestellte Situation nicht in jedem Projekt und jedem Unternehmen gegeben sein muss – denn sie setzt voraus, dass das Team, das die Theorie hinter der weiterzuentwickelnden Software besitzt, auch für die Arbeit an dem Projekt zur Verfügung steht.

Bei uns in der webfactory ist das typischerweise der Fall. Da wir uns auf langlebige Softwareprodukte spezialisiert haben, legen wir großen Wert auf Kontinuität im Team und eine geringe Fluktuation. Neue Teammitglieder werden bei uns Schritt für Schritt in Weiterentwicklungsprojekte eingebunden und mit der Theorie hinter den Softwaresystemen vertraut gemacht.

Bei größeren Unternehmen ist hingegen nicht unbedingt gesagt, dass eine Folgevergabe an das gleiche Unternehmen überhaupt dazu führt, dass die Entwicklung von einem Team durchgeführt wird, das die Theorie hinter dem System kennt. Wenn das aber nicht garantiert ist, ist eine Vergabe an ein solches Unternehmen auch nicht durch die obige Argumentation gerechtfertigt.

Und wenn alle Stricke reißen?

Natürlich kann es Situationen geben, in denen die Weiterentwicklung eines Systems durch das ursprüngliche Team nicht möglich ist und die Betreuung des Systems daher neu vergeben werden muss. In diesem Fall sollte aber, wenn die Software nicht komplett neu entwickelt werden soll, das ursprüngliche Team wenn möglich beratend bei der Entwicklung zur Seite stehen, damit das neue Team die Theorie hinter der Software lernen kann. Parallel zur Vergabe an den neuen Dienstleister sollte also der alte Dienstleister mit der Vermittlung des Wissens beauftragt werden. Die dadurch entstehenden Kosten sind durch die dadurch erreichte bessere Einarbeitung des neuen Teams, höhere Qualität der Weiterentwicklung und daraus resultierend ein längeres Leben der Software gerechtfertigt.