Dockerimage für CI/CD mit Sloppy CLI

Schreibe eine Antwort

In CI/CD-Situationen, also in Situationen, in denen wir automatisiert gewisse Aussagen über und Aufgaben am aktuellen Entwicklungsstand einer Software vornehmen wollen, sind wir häufig auf die Kommandozeile angewiesen.

TL;DR: Das Runner-Image z.B. für GitLab ist auf DockerHub frei verfügbar dielok/sloppy-cicd. Wir werden die Dockerfile auch in Kürze bei Github veröffentlichen.

Über entsprechende Skripte, also aneinandergereihte Befehle, automatisieren wir dann den Prozess und visualisieren ihn in Form von sogenannten Build- und Deploymentpipelines.

Auch mit dem Cloud-Anbieter Sloppy muss dies natürlich irgendwie innerhalb eines Skriptes möglich sein, damit wir den Entwicklungsstand auch automatisiert veröffentlichen können. So kann die Anwendung auch letztlich von Endnutzern verwendet werden. Dies kann ein Server sein, oder ein ganzes Netzwerk aus Servern, daher sprechen wir von Umgebungen. Auf der sogenannten Produktivumgebung läuft die Anwendung für den Endverbraucher. Umgangssprachlich „Prod“.

Auch auf Umgebungen die nicht produktiv sind, müssen die aktuellen Entwicklungsstände ausgerollt werden können. Diese dienen beispielsweise den Tests der Qualitätssicherung, Demonstrationen für Stakeholder und der Beobachtung des Fortschritts durch Manager. Das soll so zuverlässig, einfach und schnell wie möglich ablaufen: Also automatisiert.

Das geht mit Sloppy im Handumdrehen. Super einfach ist ein neues Projekt (Umgebung) angelegt, Services, Apps in Form von Docker-Containern definiert.Nicht nur in dem UI. dem Portal von Sloppy. Sloppy bietet eine gut entwickelte CLI-Anwendung, mit der Apps, Services und Projekte verwaltet und gesteuert werden können.

Und so können auch die Deployment-Schritte in der Pipeline mit Sloppys CLI-Tool automatisiert werden. Das Skript für diesen Schritt ist dann gerade einmal zwei Zeilen lang:

script:
- export SLOPPY_APITOKEN="$SLOPPY_APITOKEN"
- sloppy change --image docker/container:${CI_COMMIT_REF_NAME} umgebung/service/app

(Auszug aus der CI/CD-Konfiguration für Gitlab)

Zu verbessern wäre, dass dieser Pipelineschritt noch wartet, bis das Deployment erfolgreich abgeschlossen wurde und der Service gestartet werden konnte.

Doch wie bekommt die Pipeline die Sloppy CLI, sodass der Befehl sloppy überhaupt zur Verfügung steht? Entweder lädt und installiert die Pipeline die Binaries bei jeder Ausführung dieses Schrittes oder die Anwendung wird bereits in den zugrundeliegendeliegenden Container installiert und steht immer gleich zur Verfügung.

Für unser Zwecke habe ich den Container mal erstellt und auf Docker Hub verfügbar gemacht: dielok/sloppy-cicd. Viele Erfolg.

Sloppy hat einen genialen Ansatz als Cloud-Anbieter

Schreibe eine Antwort

Wenn ich Sloppy richtig verstehe, wollen sie ein Cloud-Anbieter sein, der grundsätzlich bei den Großen mitmischt. Und ich denke, dass werden sie auch, denn Sloppy nicht aus dem Silicon Valley sondern aus Köln zeigt mir gerade, was AWS, Google Cloud und Azure eigentlich falsch machen.

Sloppy ist im Wesentlichen ein Cloud-Anbieter, der auf den Kern der Sache konzentriert ist: Container (ob jetzt Pod oder Docker oder oder) spezifizieren und und den Cluster hochfahren. Das, sowie die restlichen Aufgaben, die es im Operrationsumfeld gibt, sollten nicht, eigentlich nicht und hätten es nie müssen: Hexenwerk sein.

Beispielsweise etwas, was vollkommen unterschätzt ist: Die sogenannte Docker-Compose-Datei. Im eigenen Team habe ich es miterlebt: Docker-Compose wird so ein bißchen als Spiellösung abgetan. Es ist aber ein komplett ausreichendes, universelles Interface um Cluster im Allgemeine zu definieren. Ob das jetzt Kubernetes, OpenShift oder sonst was läuft.

Sloppy hat dies sofort erkannt. Mindestens über deren CLI-Tool kann man diese Docker-Compose-Datei hochladen und damit den gesamten Cluster hochfahren und konfigurieren. Ich finde es schon alleine bemerkenswert, dass so eine kleine Firma ein beachtliches, einfach zu nutzendes CLI-Tool entwickelt und den Users zu Verfügung stellt.

Die GUI ist bereits jetzt sehr gut verwendbar. Es lassen sich verschiedene Projekte erstellen. Verschiedene Zonen. Ich kann die Container (standarmäßig vom Docker-Hub) definieren und die Instanzen skalieren. Rolling-Deployments kommen gleich mit.

In CI/CD Pipeline kann ich ohne viel Aufwand Deploymentsteps definieren, die die Anwendungen auf die jeweiligen Umgebungen deployen bis durch auf die Produktionsumgebung.

Ich weiß nicht, welche Wünsche das offen bleiben, für welchen Anwendungsfall.

Evtl. gibt es diverse Compliantsrichtlinien, die sich ohne die Konfigurationsmöglichkeiten eines AWS oder Azure nicht realisieren lassen. Okay. Aber das ist doch dann die eigentliche Niesche.

Eigentlich könnten man sogar darauf wetten, dass sich herausstellen wir, dass der Sloppy-Ansatz eigentlich für die Masse geeigneter ist, als die großen Cloud-Anbieter. Denn der Betrieb via Sloppy erfüllt im Prinzip alles, was 95% der aktuellen Nutzer derzeit bei AWS und Co. nur kompliziert und umständlich und nicht so einfach bekommen. Das macht Sloppy schon sehr gut.

Positionierung: Ergebnisse des Smoketests mit Google Ads

Schreibe eine Antwort

So, wir kennen also die Angebotslücken am Markt (Artikel „Ergebnisse unserer Markanalyse“). Aus der Marktanalyse wissen wir, dass das Angebot für Marktplatzentwicklung und DevOps relativ gering ist. Also klare Sache? Die entsprechenden Suchanfragen bei Google bespielen und die Projektanfragen flattern rein? Denkste!

Neben der A/B-Splittests, der Smoketests, der Landingpages, der Zielgruppendefinition ist auch das Schalten und Designen von Google Anzeigen wieder eine eigene Wissenschaft. Auch hier bin ich Autodidakt und schreibe diesen Artikel als Amateur im Online Marketing (Auch wenn ich mittlerweile überzeugt bin, dass man diesen Anspruch an Kleinteiligkeit bei den meisten sogenannten Experten nichteinmal bekommen wird).

Die Keywordrecherche mittels „Intents“

Die Idee war, eine Keywordrecherche durchzuführen. Die Grundlagen kenne ich seid Jahren. Ich habe zusätzlich gelernt, dass Google mittlerweile verschiedene Suchanfragen bestimmten, sogenannten „Intents“ zuordnet. Für unsere Themen wäre das z.B. der Intent „Was ist Marketplace Development?“ oder „Was ist DevOps?“. Diese Intents gibt es in drei Kategorien: Informational, Purchase und Transactional. Die „Was ist…“ Intents sind klar aus der Kategorie Informational. Denn diese Intents suchen halt nach Detailinformationen. Uns wir später noch beschöftigen, dass es nicht immer klar ist, zu welcher Kategorie Google gewisse Intents zuordnet.

Mir waren die Intentkategorien erstmal egal. Ich habe eine erste Keywordrecherce, vorerst für DevOps selbst gemacht und diese Liste dann einem selbsternannten Keywordexperten gegeben. Der hat dann noch diverse Tools verwendet, um weitere Keywordideen zu finden. Wahrscheinlich hat der auch nichts anderes gemacht, als den Google Keyword Planner zu verwenden und mich dafür zu Kasse gebeten. So ist das Unternehmerleben: Manchmal zahlt man nur für die Möglichkeit einer erbrachten Leistung.

Ich habe unterschiedliche Keywords in der Liste: „devops ci cd“, „devops vorteile“, „gitlab devops“, „devops bedeutung“, „devops tutorial“, „devops“ und viele ähnliche Weitere. Wie man sieht, sind fast alle aus der Kategorie Informational, aber zu welcher Kategorie gehört „devops“?

Anzeigen entwerfen

Jetzt ist die Frage: Ist da genug? Ich habe jedenfalls jetzt erstmal keine Ideen mehr.

Der Verlauf der Kampagne

Gewundert hat mich, dass es wieder nur 5000 Menschen zu geben scheint, die in ganz Deutschland, Österreich und der Schweiz, die in drei Wochen nach DevOps-Themen bei Google suchen. Das glaube ich nicht, wenn man sich den Buzz um DevOps vor Augen führt. Eher hätte ich damit gerechnet, dass 10000 pro Woche suchen und entsprechend die Klickpreise hoch sind, da es viel Konkurrenz gibt.

An den schlechten Klickrate konnte ich auf die Schnelle nichts ändern. Aber die Anzahl der Impressionen könnte auch an unserem Tagesbudget gelegen haben. Daher habe ich dieses mal von 5€ auf 15€ pro Tag angehoben und tatsächlich war ein proportionaler Anstieg der Klicks zu sehen. Da ist also Luft nach oben.

Der Klickpreis liegt bei unter 1,50€, was ich okay finde und uns Spielraum für Experimente gibt. Bei 10€ pro Klick wäre jedes weitere Experiment ein teures Unterfangen.

Ergebnisse des Smoketests

Auf wenn also die Performance mit 1,21% Klickrate (Click Trough Rate, CTR) unterirdisch ist. Die Ausstiegsrate auf unserer DevOps-Landingpage ist auch nicht so gut. 20% steigen derzeit aus. Eine gute Erkenntnis ist aber, dass wir 1,48€ pro Klickzahlen und mit einem Budget von 25€ pro Tag durchschnittlich 20 User an Traffic auf unsere Landingpage leiten können, wann immer wir wollen.

Was uns eine neue Kundenanfrage (also eine Konversion) allerdings kostet, können wir aktuell nicht abschätzen, da wir bisher leider keine Konversion hatten. Wir können nur sagen, dass bei jetzigem Setting, eine Kundenanfrage teurer als 155€ ist, was ich nicht gehofft habe. Hoffentlich können wir das optimieren.

Learnings

Build, Meassure, Learn ist noch immer das Motto. Also war haben wir gelernt? Wir können Hypothesen für einen nächsten Test ableiten. Eine starke Vermutung ist die Intentkategorie. Wir haben Anzeigen geschaltet, die einen Suchenden erwarten, der nach einer Dienstleistung sucht, die also einen Intent der Kategorie Purchase erwarten. Die Keywords gehen fast alle eindeutig auf Intents der Kategorie Information. Und selbst das Keyword „devops“, das nicht eindeutig einer Intentkategorie zuzuordnen ist, gehört wahrscheinlich zu Information. Denn schaut man sich die anderen Suchergebnisse und Anzeigen auf „devops“ an, sind dies klar Inhalte, die DevOps erklären und es nicht verkaufen wollen.

Daraus erklärt sich möglichweise die niedrige CTR. Wir sollten als Experiment also Anzeigen entwerfen, die Informationen zum Thema bieten.

Nebenbei: Kann man daraus eine Regel ableiten? Wenn das zentrale Keyword eines Themas zur Intentkategorie Information gehört und ein hohes Interesse erfährt, dann ist das Thema in einem Frühstadium des Produktlebenszyklusses?

Aber wenn es also so gut wie keine Suchen vom Intent Purchase gibt, woher kommen dann die Kunden für DevOps. Nur wie unsere durch Word-of-Mouth? Vielleicht von Messen? Irgendwo müssen die ja herkommen. Eine Hypothese ist, unsere Kunden geben allgemeine Keywords ein um dann einen auf DevOps spezialisierten Dienstleister aus der Masse herausstechen zu sehen und mit den Vorteilen von DevOps konvertiert werden. Das entspricht allerdings wenig meiner persönlichen Erfahrung mit Kundenverhalten.

Ausblick

Wir werden es sehen. Wir machen nun folgende Experimente: Wir checken, ob die CTR bei Anzeigen, die dem Informationintent entsprechen, steigt. Wir checken, ob DevOps-Anzeigen auf unspezifische Suchen wie „Individuelle Softwareentwicklung“ besser funktionieren. Wir A/B-Splittesten die DevOps-Landingpage um zu schauen, ob wir nicht trotz der schlechten Werte, einen akzeptable Preis pro Projektanfrage erzielen können. Letztlich, wenn 1/10 Anfragen erfolgreich ist, wir je Anfrage einen Aufwand von 4 Stunden haben, haben wir eine CAC (Customer Acquisition Cost) von etwa 2.500€, was bei üblichen Projektumfängen immer noch okay wäre.

Planning-Poker-Tool bekommt neue Version

Eine Antwort

Sprint Planning in Remoteteams ist an und für sich eine runde Sache. Als die Remotearbeit aufgrund der Pandemie anstieg, haben wir uns daran begeben und auch das Planning Poker runder gemacht. Jetzt haben wir unserem Agile Casino ein Update gegönnt. Mit dem Update kamen Features dazu, die Stabilität wurde erhöht. Im Folgenden gehen wir etwas ins Detail.

Hintergrund

Wir haben am Anfang der Pandemie einen Prototypen (eher schon ein MVP) für das Planning Poker. Was heißt hier „wir“? Das Team lässt mich an der Stelle mit Recht etwas im Stich, denn die haben Wichtigeres zu tun. Ich halte es allerdings für eine tolle Gelegenheit, auch mal zu demonstrieren, wie wir an die Entwicklung von modernen Cloudanwendungen herangehen.

Grundsätzlich – wenn auch klein – erfüllt es alle Eigenschaften einer Cloud-Anwendung (eine SaaS, Software as a Service). Es gibt zwar keine Abomodell (da es kostenlos ist), das könnte es aber geben (andere Scrumpoker online haben ja Pläne wie 8 Euro pro Monat etc.) und Abo ist ja ein Kennzeichen für eine Cloudanwendung. Unser Abomodell kostet quasi 0 Euro.

Das Update

In diesem Update ging es um ein paar Features und um Stabilität. Für den Betrieb im Cluster mussten wir Änderungen vornehmen. Auch die QS-Schritte haben wir auf ein professionelles Niveau gehoben, in dem wir die anfänglich rundimentären automatisierten Tests (sogenannte Integrationstests) erweitert haben.

An Features gibt es nun neben der Rolle des Entwicklers auch die Rolle des „Inspectors“. Denn es ist häufig der Fall, dass weitere Personen dem Planning beiwohnen, die den Entwicklern im Raum keinen Platz wegnehmen sollen. Inspektoren sind alle Nichtentwickler eines Scrumteams und Sonstige. Was bleibt also nach Scrum Guide noch? Genau: Der Scrum Master und der Product Owner. Sonstige können alle möglichen Stakeholder sein.

Es sind zwar weiterhin nur sieben Entwickler möglich (das es in einem Scrum Team nur maximal neun Personen geben darf, neun minus zwei ergibt sieben Entwickler). Ich finde diese Aussage im aktuellen Scrum Guide nicht mehr. Dahre denke ich, werde ich diese Begrenzung evtl. aufheben.

Außerdem habe ich den Invite Link verbessert. Der lässt sich jetzt einfacher in die Zwischenablage kopieren und ist professionell eingebunden.

Geplante Features

Jira: Ich ich denke bereits über eine Jira-Anbindung nach. Es wäre sehr nützlich, wenn geschätzte Werte gleich via Klick in die entsprechende Story im Jira übernommen werden könnte. Aber auch sehr aufwändig. Vielleicht packe ich das Feature mal in eine Art Premiumpaket, dass treue Leser und Kunden natürlich kostenlos erhalten.

Timer: Ein Timer wäre sehr nützlich, der für alle synchron läuft.

Score: Im Score-Board sollten die Spieler mit den Minimal- und Maximalwerten markiert werden. Die Spielergebnisse je Schätzrunde sollten auch hübscher dargestellt werden.

T-Shirt-Größen: Derzeit gibt es nur die vorgegebene Werteskala. Der User sollte weitere Skalen wählen können. Eventuell sollte er auch Skalen erstellen können.

Fazit

Der agile Ansatz funktioniert einmal mehr. Agile Casino bietet bereits jetzt eine gute Basis und den Nutzen, Schätzpoker in Remote-Teams störungsfrei und kostenlos durchzuführen.

Mit dem aktuellen Update kommen weitere Möglichkeit hinzu. Aus Qualitätssicherungssicht ist die Anwendung ab dieser Anwendung jetzt komplett stabil.

Was haltet ihr von dem ganzen Vorgang? Nutzt ihr das Tool oder wollt ihr es nutzen? Welche Features sollten wir noch reinbringen und was hat eurer Meinung nach Priorität? Schreibt es in die Kommentare.

DevOps: Versionierungsstrategie bei Continuous Delivery

Schreibe eine Antwort

Setzen wir die Version aus dem Quelltext heraus? Sollte die CI/CD-Pipeline die Version setzen und womöglich auch einen Tag automatisiert im Version Control System (VCS, z.B. Git, Mercurial, Subversion) setzen?

Achtung: Dieser Artikel ist eher Low-Level und für Build-Engineers, Entwickler und Architekten geeignet.

TL;DR: Wenn der Kunde mit kryptischen Buildnummern oder Hashwerten und keine Aussage über die Kompatibilität in der Versionsbezeichnung nötig ist, kann der einfach mit jedem Commit bis auf die Produktion automatisiert werden.

Meist ist dies jedoch nicht der Fall. Die Anwendung besteht wahrscheinlich aus einem Backend und einem Frontend, wenn es sich um einen einfachen Fall handelt. In vielen Fällen haben wir bereits Microservice Infrastruktur mit mehreren Servicen, die über Schnittstellen miteinander kommunizieren und voneinander abhängen. Abwärtskompatibilitäten und Breaking-Changes wollen durch die Versionierung transparent gemacht werden.

Doch Breaking Changes in einem Softwarestand zu identifizieren, ist aus meiner Sicht nicht automatisiert möglich. Eventuell könnte man experimentell über Schnittstellenkontrakte und automatisierte Tests Abwärtskompatibilität automatisiert testen, das ist aber nur eine fixe Idee eines zu kreativen Entwicklers. Auch zwischen Patch und Minor-Release zu unterscheiden ist Ermessenssache. Der Punkt ist, um abhängige Anwendungen mittels der Versionsnummer über Major-Updates und wahrscheinliche oder sogar sichere Kompatibilitätsprobleme zu informieren, benötige ich einen Menschen.

Zum Einsatz kommt natürlich Semantic Versioning — Sie wissen schon: major.minor.patch-snapshot.

Das ist der manuelle Teil. Der automatisierte Teil ist relativ unproblematisch: Jeder Commit im VCS erzeugt über die CI/CD-Pipeline ein Artefact mit der Buildnummer (wahlweise dem Commit-Hash). So etwas wie meine-anwendung:4711, wobei 4711 die Buildnummer ist.

Dieses Artefakt – sei es ein Docker-Image, eine EXE, ein Tar-Archiv, eine Jar-Datei, whatever – wird üblicherweise in einem Artefaktspeicher abgelegt (Artifactory, Nexus, Docker Registry, etc.) und von dort dann weiter auf die entsprechenden Umgebungen bis hin zur Produktion ausgerollt: „deployt“. Dort werden dann verschiedene Integrationstests, Ende-zu-Ende-Tests, Abnahmetests und so weiter ausgeführt.

Bei einer Codebasis, einer Anwendung, die gepflegt, weiterentwickelt und ausgeliefert wird, ist das easy. Die Buildnummer ist zentrale Wahrheit. Was aber wenn x Anwendungen entwickelt werden und in einem Ökosystem zusammenspielen müssen. Was bedeutet in diesem Kontext ein „neuer Build“? Anwendung-1 ist bei Build 6364 während Anwendung-12 erst bei Build 56 ist. Wie komme ich hier zu allgemeinen, automatisierten Testaussagen. Das behandeln wir mal in einem anderen Artikel.

Für unser einfaches Szenarion kommt jetzt wieder die manuelle Versionierung ins Spiel. Denn ich möchte meine neue Version nicht als 4711 veröffentlichen. Eine oft genutzte Eigenschaft meiner Schnittstelle stand in der letzten Version 1.2.3 noch zur Verfügung, ist aber jetzt nicht mehr dabei. Es ist Zeit für eine Version 2.0.0.

Wie benennen wir jetzt also den Build 4711 mit 2.0.0? Manuelles Ändern des Dateinamens? Sicher nicht. Aus meiner Sicht ist das Folgende am einfachsten: Wir nutzen Tags, falls uns VCS das hergibt (Git kann das natürlich).

Die Buildnummer ist nichts weiter als die fortlaufende Nummer der Pipelineausführung, durch die das Artefakt erzeugt wurde. Dieser Pipelinedurchlauf läuft auf einem bestimmten Codestand, der wiederum in einem Commit im VCS eindeutig enthalten ist.

Indem wir manuell einen Tag 2.0.0 auf diesen der Buildnummer 4711 eindeutig zugeordneten Commit setzen, lösen wir ein Event aus. Dieses Event triggert eine Pipeline, die nun das Artefakt nicht mit der Buildnummer, sondern der Tag-Bezeichnung versieht.

Jetzt ist es noch wichtig, die Artefakte vielleicht systematisch aufzuräumen, aber auch das ist ein Thema für einen weiteren Artikel.

Wirtschaftlicher Nutzen von CI/CD

Eine Antwort

Produktinnovation ist in einer digitalisierten Welt der Schlüssel zum Erfolg. Um sich vom Wettbewerb abzuheben, sollen Innovationen so rasch wie möglich und voll funktionsfähig an den Markt gebracht werden. Doch konventionelle Entwicklungsmethoden sind meist schwerfällig und bremsen die Time-to-Market. Um die Zeitspanne zwischen Entwicklung und Marktveröffentlichung zu verkürzen, sind in der Vergangenheit effektive Ansätze entwickelt worden.

Bei konventionellen Vorgehensweisen, vergehen teilweise Monate bis es zu einem Release kommt. Zunächst müssen alle Fehler behoben und Funktionen entwickelt bzw. erweitert werden. Erst danach folgt ein großes Update. Dabei werden beinahe alle Änderungen und Anpassungen manuell durchgeführt und der Prozess wird dementsprechend anfälliger für Fehler. Der gesamte Prozess ist wenig flexibel sorgt oftmals für komplexe Workarounds für die Entwickler.

Eine Lösung für dieses umständliche Vorgehen muss her. Ein lohnender Ansatz soll den Entwicklungsprozess von Software vereinfachen und zugleich beschleunigen: Das CI/CD.

Unterschied zwischen Continuous Integration (CI) und Continuous Delivery (CD)

Was ist also CI/CI? CI bzw. CD steht für Continuous Integration bzw. Continuous Delivery. Continuous Integration (CI) ermöglicht eine kontinuierliche Integration von neuem Code in ein gemeinsames Repository während Continuous Delivery (CD) für die Überführung des Codes von Repository in die Produktion zuständig ist.

Durch die Anwendung von CI/CD können sowohl die Fehlerquote als auch der Release-Zyklus minimiert werden. Im ersten Schritt, der Continuous Integration, testet der Entwickler den von ihm produzierten Teil des Codes bevor er ihn in das Controle-Repository übermittelt. Danach folgt meist eine neue Quellcode-Version, welche mittels Unit-Tests auf Fehler geprüft und in Testumgebungen eingefügt wird. Hier werden auch ganzheitliche Systemtests durchgeführt. Wenn der neue Teil des Codes erfolgreich alle Tests durchlaufen hat, wird das Team automatisch benachrichtigt. Zudem werden Informationen über die Anzahl der Tests und der gefundenen Fehler gesammelt.

Continuous Delivery (CD) setzt dort an, wo Continuous Integration endet. Bevor Software in die Produktionsumgebung übermittelt wird, werden Systemtests, Unit-Tests (inklusive API-Tests und Lasttests) und Integrationstests durchgeführt. Diese Tests sind allesamt Teil von Continuous Delivery und werden automatisch durchgeführt. Über den kompletten CI/CD-Prozess hinweg, können Fehlermeldungen rasch und direkt über Feedback-Kanäle an die Entwickler weitergeleitet werden.

Nachfolgend sind die relevantesten Vorteile von CI/CD aufgelistet, die letztlich in einer Kostensenkung resultieren.

  • Kleine Schritte: Statt große Teile des Codes auf einmal zu integrieren und in späterer Folge deren Fehler umständlich zu beheben, werden bei CI/CD mehrere kleinere Teile in das Repository eingefügt. Das Continuous Testing wird dadurch erleichtert, weil nur kleinere Stücke untersucht werden müssen und mögliche Probleme somit eher gefunden werden.
  • Kürzere Release Rates: Durch das rasche Erkennen und Beheben von Fehlern, können mehrere kleinere Code-Teile in kürzeren Abständen released werden. Dies ist allerdings nur möglich, wenn in einem kontinuierlichen Prozess entwickelt und der Code in einem releasefähigen Zustand gehalten wird.
  • Ordentlicher Backlog: Wird CI/CD in den Entwicklungsprozess integriert, so verändert sich die Fehlerquote im Backlog. Da kleinere Fehler rascher gefunden werden, kann sich das Team auf kritische Probleme konzentrieren.
  • Einfache Wartung: Mithilfe von Microservices können einzelne Bereiche eines Systems heruntergefahren werden ohne das restliche System betroffen ist. Somit können Wartungsarbeiten nahezu unbemerkt stattfinden.
  • Continuous Feedback: Durch die regelmäßige Integration des Codes, entsteht eine verlässliche und kontinuierliche Feedbackschleife. In dieser befinden sich vor allem Entwickler. Deren Rückmeldung zu Pipeline Build-Fehler, Merging-Problemen, Architektur-Rückschlägen usw. ist enorm wichtig für den gesamten Prozess.

Darauf sollte geachtet werden

Den Entwicklern soll die Arbeit mit dem CI/CD-Ansatz erleichtert werden, weshalb ein einfacher Prozessaufbau essentiell ist. Je weniger sie sich mit dem eigentlichen Prozess und manuellen Aufgaben aufhalten, desto effektiver kann gearbeitet werden. Zudem sollten Entwickler bis auf wenige Ausnahmen, direkt am Master-Branch arbeiten um eine sofortige Integration und das zugehörige Testen zu ermöglichen.

Wird CI/CD in den Entwicklungsprozess von Software integriert, so müssen automatisierte Tests auf allen Ebenen durchgeführt werden. Dies schließt mitunter Unit-, Integrations- und Systemtests ein, genauso wie automatisierte Tests für Funktionalität, Benutzerfreundlichkeit, Leistung, Last, Stress und Sicherheit durchgeführt werden müssen. Erst dann kann von CI/CD ganzheitlich profitiert werden.

Als nützliche Tools erweisen sich beispielsweise Repository-Management-Systeme wie Gitlab und Bitbucket oder Services für die Build-Automatisierung wie Jenkins oder eben auch Gitlab. Beispiele für die Testautomatisierung sind das Tool Katalon Studio oder jUnit in der Javawelt. Aber die Auswahl ist praktisch unendlich.

Fazit

Continuous Integration und Continuous Deployment zerstückeln den Entwicklungsprozess in kleine Teile. Diese Teile werden in regelmäßigen Abständen in ein gemeinsames Repository integriert und nach dem Testen dem Kunden rasch zur Verfügung gestellt. Sie sind ein zentrale Teil der DevOps-Methodik. Der gesamte Entwicklungsprozess wird übersichtlicher und flexibler, dadurch werden Fehler einfacher gefunden und behoben. Um mit der Konkurrenz mitzuhalten bzw. diese sogar zu übertreffen und unnötige Fehlersuche zu vermeiden, ist die Integration von CI/CD in den Entwicklungsprozess also eine einfache, effektive aber auch mittlerweile unverzichtbare Methode.

Entwickler schaffen sich ab: WebAssembly, jHipster und Low-Code – und das ist gut so

Schreibe eine Antwort

Wir machen uns überflüssig. Meine These: Und das ist gut so. Wir wollen es noch nicht wahr haben und genießen derzeit noch eine Art Schutzposition. Während es Mangel an IT-Kräften gibt und die Digitalisierung für viele Bereiche Stellenabbau bedeutet entwickeln sich die Technologien paradox. Paradox ist es aber nur auf den ersten Blick.
Die scheinbare Paradoxie: Entwickler werden durch ihre eigene Digitalisierung selbst von den Auswirkungen auf den minimierten Arbeitskräftebedarf betroffen sein. Nicht langfristig, sondern es steht kurz bevor! Wie kann das sein?

Entwickler sind derzeit noch in einer Position, dass die Digitalisierung so langsam akzeptiert ist, in manchen Bereichen bereits Fahrt aufnimmt, aber so richtig verankert in vielen Bereichen noch nicht ist. Auch mit dem Pandemieschub ist im Allgemeinen die Führungskraft abhängig von ihren Technologieberatern, meist Entwickler, die Aufgaben planen und Aufwände einschätzen. Überliche Muster dabei sind: Backendentwicklung ist sehr aufwändig im Vergleich zur Frontendentwicklung, native Appentwicklung ist keine einfache Webentwicklung und zu einem gegeben Design benötigt es grafikaffine Entwickler, die dies auch Umsetzen können. Die Entwicklung verrät dem Management natürlich nur zögerlich, dass diese Aufgaben heute zu einem Bruchteil des Aufwandes zu erledigen sind.
Die drei Kernbereiche, aus denen die Aufwände für die Entwicklung entstehen, sind kurz davor zu fallen.

Kernbereich 1: Backendentwicklung wird durch Standgeneratoren ersetzt

Die Backendentwicklung hat den Ruf, das eigentliche Feld des hochspezialisierten Entwicklers zu sein. Das ist historisch so gewachsen. Betriebssystementwicklung (Linux-Kernel, etc.), Algorithmenentwicklung (Facebook, Google) sind das Herzstück der jeweiligen Innovationen. Und in der Tat, überall dort, wo es viel neue Businesslogik zu entwickeln gibt, werden auch in Zukunft noch die spezialisierten Entwickler benötigt. Doch für die meisten Geschäftsmodelle gibt es heute Frameworks, die in dem Backendbereich eingesetzt wird. Dazu kommen Generatoren, wie jHipster, die nicht nur große Teile des Backends einfach auf Basis von standardisierten Diagrammen automatisiert erzeugen können. Auch Swagger geht nach dem Konzept „Interface-First“ vor. Gar nicht so unglaublich aber wahr: Eigentlich braucht man nur beschreiben, welche Daten ausgetauscht werden sollen und schon steht fast das gesamte Backend. Und das ist ein sinnvoller Fortschritt, der dort vollzogen wird. Warum sollen die immerselben Businesslogiken von der Backendtruppe immer wieder auf neue händisch eingetippt werden? Oder warum soll der Entwickler sich Stunden aufschreiben, in denen er eigentlich nur Altes kopiert und sich ansonsten auf die faule Haut legt?

Da wir bereits von Businesslogik sprechen, die früher üblicherweise im Backend angesiedelt war, so kommt der eine oder andere vielleicht auf die Idee, dass diese nun einfach in die Frontendentwicklung abwandert und dann eben dort stattfindet. Das ist nicht richtig. Sie wandert zwar im Zuge der ebenfalls richtigen Evolution von klassischen, serverabhängigen, mehrseitigen Anwendungen in richtung Singlepage-Application oder PWA (Progressive Web Apps) also Anwendungen, die eher unabhängig von einem Server funktionieren und deshalb viel Businesslogik in der Anwedung selbst und nicht im Server haben. Doch diese wird bereits von den entsprechenden Generator wie jHipster gleich mitgeneriert.

Kernbereich 2: Spezialisten für native Appentwicklung

Derzeit ist es sinnvoll für Innovationen, mit einem plattformunabhängigen Framework App für mobile Geräte zu entwickeln. Einfach weil es günstiger ist, gleich für mehrere Plattformen zu entwickeln. Besser und hochwertiger allerdings ist die native Entwicklung für jede Plattform im Speziellen. Also eigens für Apple (iOS) und eigens für Android. Dafür benötigt man spezielle Swift oder Java-Entwickler. WebAssambly ist die nächste Evolutionsstufe: So wie Website einfach von eine Domain geladen werden, können mit WebAssembly schon heute native Apps entwickelt werden, die nicht über einen AppStore geladen werden müssen, sondern einfach über eine Domain abgerufen werden können. Und diese werden, sobald es die entsprechenden Phones dafür gibt, gleichmaßen gut auf dem Phone, dem Tablet und dem Desktop laufen. Schnell, nativ entwickelt.

Kernbereich 3: Frontendentwickler ablösen

Zu meiner Anfangszeit gab es Microsoft Frontend. Wer mit diesem Tool glaubte, Webentwicklung betreiben zu können, wurde schnell eines besseren belehrt. Das Tool wurde praktisch zu einem Witz unter allen Menschen, die sich mit der Entwicklung von Software oder auch nur einfachen Webseiten im Web beschätigten. Auch andere Tools, die Frontends irgendwie grafisch entwickeln lassen wollten, erreicht nie den Wartbarkeits und Erweiterbarkeits und Sauberkeitsanspruch echter Softwareentwickler. Heute gibt es allerdings die ersten Tools, wie WebFlow, die einen Grafiker in die Lage versetzen, seine Designs quasi direkt in diesem Tool umzusetzen, mit den üblichen Werkzeugen, mit leicht ungewohnter Herangehensweise. Ist diese Herangehensweise in gewissen Blöcken zu denken, allerdings akzeptiert, so generiert der Design gleich das gesamt Frontend. Ein Entwickler stöpselt bloß noch die Details zusammen. So ein Tools ist beispielsweise WebFlow.

Was für den Entwickler bleibt ist Zusammenstöpseln: Das werden die Waldundwiesenentwickler übernehmen. Davon wird der Bedarf dann in Zukunft gewaltig abnehmen. Und neue Businesslogik für echte Innovationen wird weiterhin benötigt. Das wiederum werden die besten Spezialisten auf ihrem Gebiet ausführen.

Starke Grundsteine für neue Wege setzen

Schreibe eine Antwort

Im Zeiten des Wandels 2020/2021 arbeiten wir mehr denn je an der Zusammenarbeit mit starken Partnern an unserer Seite und investieren in Innovationen. Der Fokus unserer Mitarbeiter liegt in der optimalen Umsetzung unserer Projekte, wobei ein Blick immer auf die Marktsituation und Entwicklung der Branche gerichtet ist. Wir freuen uns daher über einen neuen starken Partner an unserer Seite: Thomas Giessmann-FahrSicherung. Bei seinem Projekt www.ebikeVersicherungen.net setzen wir das ausgezeichnete Know-How unserer Mitarbeiter und unsere Stärke auf den Aufbau dieser Vision ein.

Die E-Bike Versicherung bietet einen Vergleich von Versicherungen für Zweiräder und ist demnach ein Insuretech-Startup. In dieses interessante Feld treten wir nun ein. Isuretech ist eine Kombination von Versicherung und Technologie, wobei der größte Vorteil zur klassischen Versicherung der optimale Zuschnitt auf eine konkrete Situation ist. So kann diese für einen bestimmten Zeitraum gebucht werden, ohne dass eine Kündigung notwendig ist, leicht und schnell per App. Der Vergleichsrechner der E-Bike-Versicherungen ermittelt das perfekte Produkt für den Kunden und berücksichtigt dabei alle Faktoren, wie Anlass, Modell, Zeit. Durch nur wenige Eingaben wird in kürzester Zeit eine Übersicht von möglichen Versicherungen erstellt, die u.a. einen Vollkaskoschutz zum Neuwert, Diebstahlschutz und den Verschleiß abdecken. Besonders für Berufspendler oder Sportler, die oft kostspielige Modelle besitzen, lohnt sich dies. E-Bike Versicherungen bietet hier für den Kunden die einfachste und schnellste Methode, um die verschiedenen Anbieter auf einen Blick zu vergleichen. Unser Entwickler Michael Deichen ist Experte im Backend und optimiert momentan die Schnittstelle zu www.flixcheck.de und trägt dazu bei die Seite noch professioneller zu gestalten und eine einfachere Handhabung für Kunden umzusetzen.

Wir sind absolut überzeugt von dem Erfolg dieser Zusammenarbeit und unterstützen das Projekt auch ohne den größten Gewinn zu erwarten. Vielmehr sehen wir unseren jetzigen Anteil als Investition in eine großartige Zukunft, denn Engagement stellt auch eine Form von Investment dar. Auch nach der ersten Phase des Kennenlernens freuen wir uns ihnen auch weiterhin zur Seite zu stehen. Schon von Beginn an gestaltete sich die Zusammenarbeit äußerst professionell und es bildete sich ein gut funktionierendes produktives Team aus Geschäftsführung, Entwicklern und Projektmanagement, das stetig an der Weiterentwicklung der Website und zugehörigen Schnittstellen arbeitet. Wir freuen uns Teil des Wachstums in diesem jungen Startup zu sein und sind positiv gestimmt auch langfristig ein starkes und erfolgreiches Team mit E-Bike-Versicherungen zu bilden.

Positionierung und Marktanalyse

Positionierung: Ergebnisse unserer Marktanalyse

Eine Antwort

In den letzten Wochen haben wir uns einer Repositionierung unterzogen. Obwohl wir stetig und solige wachsen, machen wir eigentlich die gleichen Fehler, wie viele andere Softwareentwickler da draußen: Wir sind zu diffus in unserem Angebot.

Ich bin kein Marketingspezialist. Solche Aufgaben gebe ich für gewöhntlich an externe Dienstleister. Doch diese zentralen Design- und Ausrichtungsthemen sollte der Unternehmer selbst machen. Perfektionieren können es später andere. Deshalb sind die folgenden Themen aus der Perspektive eines Autodidakten geschrieben.

Warum sollte ein Kunde unsere Dienstleistungen beauftragen? Die Frage aller Fragen. Sicher entwickeln wir einfach besonders gut, effizient und zuverlässig – aber das sagen alle anderen auch. Momentan ist der einzige echte Grund, warum Kunden zu uns kommen: Wir werden von anderen Kunden empfohlen und wissen wovon wir sprechen, weshalb wir in Kundengesprächen einen guten Eindruck hinterlassen.

Das ist eine gute Basis, nur würden wir gerne auch Unternehmen unterstützen, die nicht direkt aus unserem eigenen Umfeld kommen. Also müssen wir auf uns aufmerksam machen. Doch ohne die Empfehlung, stehen wir genau so ununterscheidbar da, wie die meisten bei Google. Das heißt es „Von der Idee bis zum Launch“, „Experte für Individualsoftware“, „Individuell & Maßgeschneidert“, „Wir bauen digitale Produkte“, etc.

Doch was ist eigentlich die Leistung, die sie anbieten? Ein „Experte für Individualsoftware“ lässt sich klassisch durch ein Lastenheft briefen und geht dann den Entwicklungsprozess durch, bis am Ende die gewünschte Software herauskommt. Das können wir auch. Ob nun jemand einen Markplatz, eine Enterprise-Software, ein Spiel, einen Onlineshop oder eine Desktopapplikation entwickelt haben wollte, das spielte 1995 keine große Rolle.

Kommunikation aus den 90ern

Heute jedoch macht es einen gewaltigen Unterschied, ob wir noch nie einen Shop bspw. auf Basis von Shopware in Betrieb genommen haben, dafür aber seit einem Jahrzent Plattformen entwickeln und für unsere Kunden betreiben.

Und die Landschaft ist unfassbar divers. Was früher Buchhaltung, Officeanwendungen, Unterhaltungssoftware und vielleicht noch Internetseiten waren, sind heute zig verschiedene Themengebiete mit ihren eigenen Hürden. Heute gibt es, wenn man allgemein von Softwareentwicklung spricht, alles Denkbare: Globale Lösungen für die betriebliche Resourcenplanung mit hohen Hardwareanforderungen, Datenanalyse mit Datamining, Datenanalyse mit Business Intelligence, neben Internetseiten spielt sich alleine im Browser Gaming, Webanwendungen (Google Docs, Spotify, Microsoft Tasks und tausend andere), IoT-Plattformen, E-Commerce und Plattformen/Ecosystems wie Appstores, Marketplaces wie Booking, HRS, Uber, Freelance.de, Stellenanzeigen.de, Markt.de und wieder tausend mehr. Um nur einen Bruchteil aufzuzählen.

Diese Systeme sollen je nach Anforderung, Nachfrage und Last anpassbar und erweiterbar sein. Also auf moderen Infrastruktursystemen laufen, wie sie AWS (Amazon), Azure (Microsoft) und andere anbieten: Die Infrastruktur soll skalierbar sein. Dies allein umfasst ein Team von Spezialisten.

Man spricht von Cloud, wenn dazu moderne Abomodelle kommen. Auch für diese Anforderungen muss es wieder erfahrene Leute im Team geben.

Auch die Branche macht einen unterschied. Ob wir für unsere Messekunden oder für unsere Jobmarktplätze Plattformen entwickeln, kommen verschiedene Erfahrungsschätze zur Geltung. So ist es ein himmelweiter Unterschied, ob man für Transport, den Handel oder die Finanzwelt entwickelt .

Wo stehen wir in diesem Spiel: Eine Markanalyse

Auch unsere Kommunikation war darauf ausgelegt, potentielle Kunden davon zu überzeugen, dass wir alles entwickeln können. Und selbstverständlich können wir uns tatsächlich in alles einarbeiten. Alles ist irgendwie verwand. Webapps und Apps für Apple-Smartphones (iOS). Marktplätze und Onlineshops. Selbst für die Buzzthemen Blockchain, Machine Learning und Datenanalyse hätten wir theoretisch Leute, die entsprechende Fähigkeiten hätten, aber derzeit keine Spezialisten in dem Bereich sind. Das ist nicht unser Kerngeschäft, das macht z.B. Blockchain Solutions hier in Hamburg besser.

Also was sind denn eigentlich die Bereiche? Und es geht ja auch darum, den sogenannten offiziellen Titel dieses Feldes zu kennen.

CheckMobile (unser Vermieter hier in Hamburg) und wenige andere Softwaredienstleister in Hamburg haben sich zum Beispiel auf Business Process Automation spezialisiert. Prozessautomatisierung – klar. Dass BPA das allgemein etablierte Akronym ist, müsste einem natürlich klar sein um sich darauf nach außen zu positionieren, selbst wenn man bereits vielleicht seit Jahrzehnten erfolgreich Prozesse automatisiert. Natürlich weiß man das wahrscheinlich, wenn man bereits darauf spezialisiert ist.

Andere Bereiche werden häufig als API-Development, E-Commerce Development, Marketplace Development, Cloud Application Development, Web Development, Software Engineering, Software Testing Services und noch ein paar andere bezeichnet.

Jetzt haben wir eine einfach Exceltabelle erstellt, mit all den sichtbaren Mitbewerbern in Hamburg und geschaut, welche Spezialisierung, welche Kundenbranchen, welche Kundengröße sie am Markt kommunizieren. Aus Datenschutzgründen poste ich diese Tabelle hier nicht, aber es ist kein Hexenwerk, sobald man sich im klaren ist, welche Services überhaupt im Raum stehen. Dann lassen sich die Mitwerber einfach googlen und die Tabelle erstellen.

Die Erkenntnis für uns ergab sich, dass Schnittstellenentwicklung, Marktplatzentwicklung noch völlig unbelegt sind. Außerdem haben wir das Thema DevOps noch mit in die Liste aufgenommen und auch dafür hat bisher noch kein Spezialist die Hände gehoben.

Was können wir denn so richtig gut?

Jetzt ist ja schon so, dass wir tatsächlich in manchen Bereichen besonders viel Erfahrung haben. Instinktiv würde ich auf Userexperience, Backendentwicklung, Architektur, Altsystemmodernisierung (Legacy Code), DevOps, Prototypenentwicklung und eben Markplätze tippen. Schnittstellenentwicklung können wir auch sehr gut.

Legacy Care und Fast Prototyping stellen wir bereits seit einer Weile heraus. Die die Nachfrage scheint nicht direkt besonders hoch zu sein. Die Fakten geben besonders her: Marktplatzentwicklung, DevOps, Prototypen und die Altsystemmodernisierung. In den Bereichen haben und hatten wir besonders viele Projekte und einige Tools und Best Practices angesammelt.

Also die Überschneidung ja klar: Wir sollten unsere Fähigkeiten insbesondere in der Marktplatzentwicklung und auf dem Gebiet DevOps herausstellen.

Nachfrageanalyse und Zielgruppenanalyse

Herauszufinden, wie hoch die Nachfrage bei diesen Kandidaten nun tatsächlich ist, das ist der nächste Schritt. Wir haben jetzt also die Konkurrenz analysiert und eine Angebotslücke festgestellt. Ganz offensichtlich gibt es sowohl an dem Buzzthema „DevOps“, als auch an dem Thema „Marketplace Development“ ein hohes allgemeines Interesse. Wie hoch dieses konkret ist, wie die potentiellen Kunden anzusprechen sind und über welche Kanäle sie zu finden sind, das spare ich mir für den nächsten Artikel zu unserem Positionierungsabendteuer aus.

Positionierungsakt 1: Zukunftsmenschen und Sinusmileus (Kartoffelgrafik)

Schreibe eine Antwort

Eigentlich ist es Wahnsinn einen IT-Dienstleister aufzubauen. Interessante Einsichten hat mir das Projekt „Zukunftsmenschen“ heute gebracht. Die Positionierung ist derzeit das zentrale Thema meiner Strategieaktivitäten. Ich bin Nachfrageanalysen beschäftigt bei denen ich die Sinusmilleus wieder zurate gezogen habe.

„Zukunftsmenschen“ ist ein Studienprojekt, der Youtubefund ist eine Art Interview von Puppen als entsprechende Repräsentanten der einzelnen Millieus. Toll gemacht. Leider fehlt einem zu der Vorstellung irgendwie das Programmheft, wenn man so will. Ich konnte mir den Gesamtzusammenhang über den Projektabschlussbericht und die Website rekonstruieren.

Zugegeben: Es hat mich erstaunt, dass Kehrwasser 2019 letztlich Fahrt aufgenommen hat. Der Erfolg war das Ergebnis halbsystematischen Probierens. Durch die Erfahrungen, die ich zwischen 2015 und 2018 in IT-Dienstleistern, Agenturen machte, konnte ich immerhin unser Angebot bzgl. der Business Values schärfen. Meine Vertriebsbemühung musste davor geradezu kläglich scheitern. Aus dem Elfenbeinturm der Technik, der wissenschaftlich, theoretischen Sicht auf die Informationstechnologie und entsprechenden Dienstleistungen war mir die Sicht des Kunden auf einen IT-Dienstleister vorher nicht bewusst.

Erst das Verständnis für das Projektmanagement, auf der Ebene des ökonomischen Entscheiders zu kommunizieren brachte mich zumindest zu den Einsichten, die Sorgen aus Managementperspektive vordringlich zu kommunizieren. Dies und der technische fundierte Hintergrund, brachte Kehrwasser die ersten ernstzunehmen Aufträge letztlich ein, nach meiner bisherigen Einschätzung.

Doch dies ist nur das eine Ende des Spektrums. Die feingranulare Positionierung von Kehrwasser inmitten etlicher Dienstleister alleine lokal in Hamburg und etlicher Anbieter in diesem Umfeld online ist dringend notwendig um den nächsten Schritt gehen zu können.

Neben der Fokussierung auf wenigere Nischenthemen (DevOps, DevSecOps, Markeplace Development und Release Management) ist eine Dimension der Positionierung auf den Descision Maker der Kunden. Dazu war mir eine Überblick über die Rollen in unserer Gesellschaft notwendig.

Ich stolperte also über das Video „Zukunftsmenschen – Deutschlands zehn soziale Milieus als Charaktere“. In diesem Werden die Personas, also repräsentative Charaktere der einzelnen Milieus als Puppen animiert interviewt und stellen so die Erkenntnisse der Milieuforschung überspitzt, quasi an ihren Gitterpunkten, greifbar dar.

Zukunftsmenschen ist die Abschlussarbeit von Anne Stürmer an der ecosign / Akademie für Gestaltung in Köln. Die Basis ist wiederum die Abschlussarbeit des Projekts „Erfolgsbedingungen für Systemsprünge und Leitbilder einer Ressourcenleichten Gesellschaft“ (Autoren: Dr. Holger Berg, Dr. Maria Schnurr, Michael Schipperges, Holger Glockner; Veröffentlicht durch das Umweltbundesamt).

Leider weichen die Millieusbezeichnungen von den üblichen Bezeichnungen der Sinusmilieus ab. Also die bekannten Hedonisten, Traditionelle, Performer, Expeditive etc. In Zukunftsmenschen sind sie Moderne Gehobene, moderner Mainstream, kritische Reflexive usw. Also wo stehen die, die wir im Video sehen?

Ich habe mich noch nicht tief in den Beitrag des Umweltbundesamtes eingelesen. Die von den üblichen Kartoffelgrafiken abweichende Positionierung findet sich in Abbildung 6 des Dokuments (siehe Screenshot unten).

Außerdem findet sich auf zukunftsmenschen.com eine Galerie über einen Prosprekt in dem die einzelnen Milieus dann definiert werden. Dort kann man sich durch die Charaktere klicken. Falls Anne das liest: Es wär toll mal ein PDF von diesem Pamflet zu bekommen.

Abbildung 6 des Abschlussberichts „Erfolgsbedingungen für Systemsprünge und Leitbilder einer Ressourcenleichten Gesellschaft“