cards42.org

Die Mitmachkarten für Softwarearchitekt:innen

Darstellung verschiedener cards42-Karten als Beispiel
Cards for Analyzing and Reflecting on Doomed Software

Die Begleitseite zum cards42-Projekt. Now also availabile in English!

Einleitung

Willkommen beim cards42-Projekt! Die Karten von cards42 unterstützen bei der täglichen Arbeit mit Softwarearchitekturen. Die Karten geben kurze Denkanstöße für festgefahrene Situationen und helfen, neues Licht auf schwierige Herausforderungen zu werfen. Diese Webseite bietet ausführliche Erklärungen sowie die Hintergründe und weitere Informationen zu den Karten.

Karten

ResourceAllocationExpectation

#expectation

Download: PNG SVG

Oft sind wir in unserer eigenen Welt mit all ihren Beschränkungen gefangen. Wir sind darauf konditioniert, uns bescheiden zu geben – bescheiden sind damit dann auch unsere Lösungen.

Aber was wäre, wenn ihr unerschöpfliche Ressourcen nutzen könntet? Was würde es im Softwaresystem bewirken? Was sind die maximal sinnvollen Ressourcen? Wie weit seid ihr hiervon weg? Wie bekommt ihr die wirklich wichtigen Ressourcen, um euer Softwaresystem noch besser zu machen?

Sammelt die Möglichkeiten auf dieser Karte und diskutiert sie mit eurem Team!

Architektur-Quick-Check

#quickcheck

Download: PNG SVG

Wichtige Qualitätsziele bestimmen Entscheidungen bei der Umsetzung von Softwaresystemen maßgeblich. In diesem Quick-Check kannst Du Deine TOP 3 Qualitätsziele mit der umgesetzten Lösung vergleichen, um zu sehen, ob diese zusammenpassen.

Finde als erstes heraus, was die TOP Qualitätsziele sind. Dann identifiziere die wesentlichen Architekturansätze Deines Softwaresystems. Das sind die Dinge, die Du einer technikaffinen Person erzählst, die wissen will, wie ihr die Software aufgebaut habt. Schätze dann ab, wie gut der jeweilige Architekturansatz die Erreichung eines Qualitätsziels unterstützt (oder auch entgegenwirkt).

Mehr Informationen

Architecture Decision Record

#adr

Download: PNG SVG

In länger entwickelten Softwaresystemen ist es mit der Zeit sehr schwierig, getroffene Entscheidungen aus der Vergangenheit nachzuvollziehen. Daher ist es wichtig, Entscheidungen und deren Beweggründe verständlich zu dokumentieren.

Mittels Architecture Decisions Records (ADRs) gibt es die Möglichkeit, Entscheidungen möglichst leichtgewichtig und einheitlich zu dokumentieren. Zudem werden hier die Gründe für eine Entscheidung und die dabei durchlaufenen Gedankengänge sowie der Kontext (Zeit, Wissen, Beteiligte, etc.) festgehalten.

Mit diesem Template könnte ihr üben, eure Entscheidungen nach den Ideen der ADRs zu strukturieren.

Mehr Informationen

Die 8-Stunden-Torte

#torte

Download: PNG SVG

Der Tag hat 24h und die Nacht ist auch noch da. — Unbekannt.

…und plötzlich war der Tag schon wieder vorbei. Aber was habt ihr bewegt? Diese Zeittorte hilft euch zu sehen, worin ihr eure wertvolle Zeit investiert:

  • Nutzt ihr eure Zeit auch wirklich effektiv?
  • Welche der Zeitslots könnt ihr einfach loswerden?
  • Wie hart am Anschlag seid ihr ausgelastet?

Beurteilt eure genutzte Zeit auch danach, ob ihr von der Arbeit getrieben seid oder ob ihr über die Zeit selbst bestimmen könnt:

  • Welche Zeit investiert ihr für zukunftsgerichtete Arbeit?
  • Wie viel Zeit verschwendet ihr mit ungeplanten Arbeiten?
  • Welche Zeit geht für Routinearbeiten drauf?

Mehr Informationen

Deine Produktbox

#produktbox

Download: PNG SVG

Oft fehlt bei in die Jahre gekommenen Softwaresystemen die Vision oder das Zielbild. Was ist der richtige Weg? Für wen machen wir all das? Ergibt das überhaupt alles noch einen Sinn?

Die Produktbox hilft euch, wichtige Antworten für eure Software aus der Sicht der Kunden zu finden:

  • Was wird eigentlich entwickelt?
  • Wer hat den Nutzen?
  • Was sind die zentralen Verkaufs- und Nutzungsargumente?
  • Was sind die Kernfunktionen?
  • Wie hebt sich das Produkt von anderen Produkten oder der Vorgängerversion ab?

Durch die Beantwortung solcher Fragen bekommt ihr ein besseres Gefühl dafür, wofür ihr die Software wirklich entwickelt.

Mehr Informationen

Arbeite ich nach gängigen Entwicklungsstandards?

#standards

Download: PNG SVG

Mit der immer komplexer werdenden Software haben sich im Laufe der Jahre kontinuierlich mehr Standards etabliert, welche die Entwicklung und Evolution eines Softwaresystems nachweislich positiv unterstützen.

Prüft in eurem Team, welche dieser Standards ihr umsetzt und wo es möglicherweise Nachholbedarf gibt. Überlegt euch auch, warum ihr fehlende oder unzureichende Maßnahmen bisher nicht angegangen seid.

Mehr Informationen

  • Das Buch Accelerate liefert wissenschaftliche Belege zu der ein oder anderen Good Practice

Meine Architektur

#bierdeckel

Download: PNG SVG

Das System ist zu komplex, um es kurz mal eben aufzumalen! – diesen oder ähnliche Sätze hat mit Sicherheit jede*r Entwickler*in schon einmal gehört.

Eine gut strukturierte und klare Softwarearchitektur muss jedoch auf einen Bierdeckel passen.

Versucht, die wichtigsten Strukturen eurer Architektur kompakt auf der Karte zu skizzieren.

  • Wann trefft ihr auf Platzprobleme? Besitzt ihr zu viel unnötigen Ballast?
  • Wird es an manchen Stellen zu detailliert? Ist das System vielleicht zu unterschiedlich abstrahiert?
  • Wisst ihr nicht, was ihr malen sollt? Sind wesentliche Konzepte der Architektur nicht bekannt?

Diskutiert euer Vorgehen beim Zeichnen und die Ergebnisse. Überlegt euch, welche Maßnahmen ihr für eine noch klarere Strukturierung eures Softwaresystems vornehmen könnt.

Mehr Informationen

Der unbekannte Bekannte

#unbekannte

Download: PNG SVG

Vermutlich hat jede an einem Softwareprojekt beteiligte Person in einer technischen Rolle dieses Problem schon einmal erlebt: Man glaubt, alles richtig zu machen, und auf einmal möchte ein Stakeholder aber etwas ganz anderes. Das Unverständnis ist groß, die Frustration steigt.

Was denkt ihr, bewegt diese Person? Versucht euch, in ihre Lage zu versetzen und überlegt, was die Motivation hinter dem Verhalten des Stakeholders ist. Wie könnt ihr auf seine Bedürfnisse eingehen, um die Situation produktiver und für alle angenehmer zu gestalten?

Mehr Informationen

Mein schmerzhaftestes Problem

#schmerzen

Download: PNG SVG

Probleme verursachen Kosten. Wenn diese Problemkosten die Kosten für die Lösung überproportional überschreiten, ist es durchaus rentabel, Probleme aus wirtschaftlichen Gründen anzugehen.

Diese Karte hilft Dir, ein für Dich sehr wichtiges Problem strukturiert zu erfassen und die damit verbundenen Kosten abzuschätzen. Die Intervallschätzung drückt dabei aus, wie sicher oder unsicher Du in Deiner Schätzung bist.

Mehr Informationen

Root Cause Analysis

#rootcause

Download: PNG SVG Beispiel 1

Softwareentwickler*innen lösen tagtäglich hunderte von kleinen und großen Problemen. Wir sind dadurch darauf konditioniert, schnell Lösungen hervorzubringen. In manchen schwierigen Situationen ist dies aber kontraproduktiv. Wir reagieren hier oft auch mit unserem antrainierten Lösungsreflex auf das erste vermeintliche und für uns klar erscheinende Problem.

Diese Karte soll euch dabei helfen, den ersten Reflex zu unterdrücken, in dem ihr mit gezielten Warum?-Fragen erst die wahren Probleme ergründet.

Versucht die sog. “5 Whys” bei verzwickten Situationen einzusetzen, um nicht nur ständig Symptome zu lösen, sondern die richtigen Problemursachen bei der Wurzel anzupacken.

Mehr Informationen

Erfolg in der Zukunft

#erfolg

Download: PNG SVG

Oft liegen sehr naheliegende Lösungen vor uns, welche maßgeblich zum Erfolg eines Softwaresystems beitragen, aber wir sehen sie gerade nicht. Zu sehr sind wir mit unserer Engstirnigkeit im Tagesgeschäft gefangen.

Diese Karte löst dieses Dilemma dadurch, dass sie euch gedanklich ganz bewusst in die ferne Zukunft versetzt. Damit eröffnet sich eine völlig andere Perspektive auf das “heutige damals”, da ihr nun auf die Gegenwart zurückblickt.

Gedanklich in der Zukunft angekommen, sammelt die TOP 3 Aktionen, die passiert sind, um euer Softwaresystem so richtig erfolgreich werden zu lassen. Diskutiert anschließend wieder im Hier und Jetzt, warum ihr die Maßnahmen noch nicht getroffen habt:

  • Was muss passieren, damit ihr es besser habt?
  • Was passiert kurz davor?
  • Was passiert dann als nächstes?
  • Wie könnt ihr jetzt loslegen?

Mehr Informationen

Wie schlimm redest Du Dir das Dokumentieren?

#ausreden

Download: PNG SVG

Das Schreiben einer Dokumentation gilt als eine der unbeliebtesten Aufgaben in der Softwareentwicklung. Sehr häufig wird die Wichtigkeit der Dokumentation nicht gewürdigt oder als umständlich abgetan.

Eine gute Dokumentation hilft nicht nur anderen, sondern auch der schreibenden Person selbst. Das Schreiben und Aktualisieren der Dokumentation muss kein Hexenwerk sein, es kann parallel zur Entwicklung geschehen – sogar innerhalb der bereits geöffneten Entwicklungsumgebung. Die Verwendung von arc42 bildet eine gute Grundlage für eine gute und einfache Dokumentation von Softwarearchitekturen.

Mehr Informationen

Das Worst-Case-Szenario

#tonne

Download: PNG SVG

Häufig überlegt man erst nach dem Ende eines Projekts was zu dem oft fatalen Ausgang geführt hat. In agilen Projekten werden zudem Retrospektiven veranstaltet, um frühzeitig Risiken für ein Projekt zu finden, aber beschränken sich diese oft nur auf die Ereignisse der vergangenen Wochen.

In beiden Fällen könnten wir fröhlich vor uns hin arbeiten, bis es einen harten Cut in Form eines Projektabbruchs kommt – den wir uns dann so gar nicht erklären können.

Aber warum muss es erst so weit kommen? Macht euch Gedanken, was dazu führen könnte, dass euer Produkt in der nahen Zukunft gegen die Wand gefahren wird. Nimmt dies für unterschiedliche Zeiträume vor, damit ihr nicht im Hier und Jetzt gefangen seid. Nutzt dann diese Erkenntnisse, um geeignete Gegenmaßnahmen zu definieren und umzusetzen.

Standortbestimmung

#standort

Download: PNG SVG

Vielen Teams ist nicht bewusst, wie gut ihre Software eigentlich ist und wo für ihren Erfolg Gefahren lauern. Die Standortbestimmung hilft euch dabei, ungenutzte Chancen zu finden und blinde Flecken zu identifizieren.

Diskutiert hierfür untereinander, mit welchen Stärken eure Software punkten kann:

  • Was lief bisher richtig gut?
  • Worauf seid ihr so richtig stolz?

Fragt euch auch, welche Schwächen derzeit vorhanden sind:

  • Wo tut ihr euch schwer?
  • Was fehlt euch?

Sucht auf dieser Basis Gelegenheiten, um die identifizierten Schwächen zu kompensieren:

  • Welche Chancen könnt ihr in naher Zukunft nutzen?
  • Was könnt ihr gleich selbst ändern?

Identifiziert ebenfalls Risiken, die sich in eurer Software verbergen:

  • Welche ungünstigen Entwicklungen in eurem Umfeld gibt es?
  • Wo lauern mögliche Gefahren?

Mehr Informationen

Technische Schulden

#schulden

Download: PNG SVG

Der Begriff “Technische Schulden” wirkt heutzutage schon sehr abgedroschen, diffus und auch abstrakt. Mache für Dein Softwaresystem sichtbar, was ihr im Team damit meint. Schätzt dazu ab, was und wie viel an “Technischen Schulden” ihr habt. Definiert und diskutiert die gefundenen Punkte untereinander, damit klarer wird, an was es Eurem Softwaresystem wirklich mangelt.

Mehr Informationen

Vermeide den #Shitstorm!

#shitstorm

Download: PNG SVG

Es gibt Personen in und um eure Software, welche einen großen Einfluss haben, ohne dass ihr es wisst. Findet heraus, welche Personen wie wichtig für den Erfolg eures Softwareprodukts sind und wie sie euer Softwaresystem sehen. Sind sie damit eher die Gewinner bzw. oder Nutznießer? Oder verlieren sie etwas, wenn euer Softwaresystem erfolgreich ist? Haben sie eine Hidden Agenda und manipulieren euere Entwicklung vielleicht sogar?

Geht entsprechend der Ansichten über euer Softwaresystem auf die jeweiligen Personen zu:

  • Wie könnt ihr Influencer besser informieren?
  • Wie könnt ihr Zusicherungen nachhalten?
  • Wen könnt ihr besser in die Pflicht nehmen?
  • Wer kann euch helfen, wenn ihr etwas eskalieren müsst?

Mehr Informationen

Code-Smell-Monster

#codesmell

Download: PNG SVG

Ähnlich wie in Horrorfilmen, gibt es auch in der Softwareentwicklung Monster. Diese kosten euch zwar nicht das Leben, dafür aber sehr viel Zeit, Nerven und im schlimmsten Fall Geld. Gottklassen, von denen eine riesige Anwendung abhängt, switch-Anweisungen mit unzähligen Einträgen oder eine Parameterliste, welche den halben Bildschirm einnimmt: all das sind die Monster, die uns jeden Tag begegnen können. Wie sieht dein persönliches Code-Smell-Monster aus? Male es auf die Karte und überlege dir, wie du es besiegen kannst.

Weitere Informationen

Checkliste Dokumentation

#dokucheck

Download: PNG SVG

Oft haben wir hunderte Seiten Dokumentation – und gefühlt versteht diese niemand oder sie ist hoffnungslos veraltet. In der Folge wird meist weniger Dokumentation erstellt oder vorhandene nicht mehr weiter gepflegt. Selten hinterfragen wir allerdings den Grund für das Unverständnis. Mit unserer Checkliste könnt ihr in ein paar Minuten prüfen, ob die vorhandene Dokumentation korrekt auf die Zielgruppe abgestimmt und auf dem aktuellen Stand ist.

Hakt dafür bei jedem Aspekt, den ihr klar mit “Ja!” beantworten könnt, das entsprechende Kästchen an. Gibt es Aspekte, die nicht OK sind? Dann habt ihr schon die ersten Anhaltspunkte, wo ihr eure Dokumentation schrittweise verbessern könnt. Idealerweise führt ihr diesen Check regelmäßig durch, damit ihr sicher sein könnt, dass eure Dokumentation immer zielgerichtet und aktuell bleibt.

Was würde ___ tun?

#idol

Download: PNG SVG Beispiel 1

Ihr wisst bei einem kniffligen Problem nicht mehr weiter? Ihr müsst etwas schnell umsetzen, habt aber eine Denkblockade? Ihr seid verzweifelt, weil euch die einfachsten Ideen fehlen?

Fragt euch: Was würde jetzt eine Person, zu der ihr aufschaut, in eurer Situation machen?

  • Was würde Margaret Hamilton über eure “Herausforderungen” bei der Umsetzung von zuverlässiger Software sagen?
  • Wie würde James Bond die Performance-Bottlenecks mit der Datenbank eliminieren?
  • Was würde das Krümelmonster mit euren zahlreichen Ticket-Leichen tun?

Zieht euch aus eurer misslichen Lage, indem ihr euch bewusst eine andere Sichtweise auf eure Probleme schafft!

Der goldene Zauberstab

#zauberstab

Download: PNG SVG

Wäre es nicht schön, wie Hermine Granger in “Harry Potter” den Zauberstab schwingen zu können und sofort ist die Brille – oder in unserem Fall ein Software-System – repariert?

Leider ist die Welt nicht so einfach und wir haben keinen Weg, um per Zauberspruch unsere Probleme zu lösen. Stattdessen bedarf es viel harter Arbeit, um problematische Systeme zurück in geordnete Bahnen zu führen.

Aber vielleicht hilft es euch beim Nachdenken, wenn ihr unseren goldenen Zauberstab schwingt. Überlegt euch, was euer Zauberspruch reparieren würde, wenn ihr die Möglichkeit hättet. Diskutiert anschließend die Ergebnisse in der Gruppe. Und wer weiß, vielleicht findet sich ja ein magischer Einfall, der das ein oder andere Problem löst.

Powerskills

#powerskills

Download: PNG SVG

Verschiedene Softwaresysteme mit ihren verschiedenen Softwarearchitekturen brauchen auch verschiedene Fähigkeiten der Beteiligten, um erfolgreich zu sein.

  • Welche Fähigkeiten wären in eurem Team von großem Nutzen?
  • Habt ihr im Team die notwendigen Skills?
  • Welche Skills nimmt ihr implizit an, habt es aber nicht kommuniziert?

Findet es mit dieser Karte heraus, in dem ihr die vier wichtigsten Skills in die vier Felder schreibt! Ihr wollt es noch genauer machen? Dann vergebt zusätzlich noch Punkte zwischen 0-100, um die Ausprägung der jeweiligen Fähigkeit festzulegen.

Stellt ihr fest, dass euch notwendige Skills fehlen, sucht nach Möglichkeiten, euch diese gezielt anzueignen oder holt euch Leute in euer Team, die diese Skills besitzen.

Traum

#traum

Download: PNG SVG

Wir Techies können es oft gar nicht erwarten, bei einem neuen Softwareprojekt in die Tasten zu hauen. Zu selten fragen wir uns aber: “Sind denn die Grundlagen für ein erfolgreiches Softwaresystem bekannt?”

Ist dies nicht der Fall ist, kann sich ein Team noch so stark anstrengen:

  • Die Motivation wird stetig abnehmen, da eine gemeinsame Zielvorstellung im Team fehlt.
  • Böse Überraschungen in Form von Risiken lauern hinter jeder Ecke, da an sie nicht gedacht wurde.
  • Ständige Konflikte und Spannungen werden euch begegnen, da wichtige Trade-Offs nicht abgewogen und offengelegt wurden.
  • Die Ziele für die relevanten Stakeholder werden nicht erreicht werden, da beides nicht bekannt ist.

Diese Checkliste hilft euch bei der Einschätzung, ob ihr in der Anfangsphase eures Projekts an die wichtigsten Dinge gedacht habt, und gibt Denkanstöße, was euch noch fehlen könnte.

Weitere Informationen

  • Michael Keeling gibt in seinem Buch “Design It! From Programmer to Software Architect” viele Denkanstöße für erfolgreiche Softwareprojekte
  • Der Softwarearchitekturdokumentationsbaukasten arc42 bietet Platz, um die wichtigsten Dinge einer Software festzuhalten

Investment-Sanity-Checker

#investment

Download: PNG SVG

Investitionen sagen viel über den Status eines Softwareprojektes aus. Häufig müsst ihr als Architekt*innen technische Themen (wichtig) gegenüber den Produktthemen (dringend) vertreten.

Support/Bugfixing – Fehler sind oft leichter zu beheben, je eher sie im Zyklus der Softwareentwicklung gefunden werden. Hotspots bei Fehlern sind gute Kandidaten für Refactorings. Ihr solltet hier idealerweise einen Wert unterhalb von 10% haben – sehr wahrscheinlich ist der Wert aber größer.

Technische Verbesserungen – Reduziert ihr technischen Schulden eures Systems, so verbessert ihr dadurch die Qualität der Software und reduziert gleichzeitig die Kosten für Fehlerbehebung sowie Entwicklungszeiten neuer Themen.
Die Empfehlung liegt bei etwa 10-15%.

Neue Features – Die Entwicklung neuer Funktionen bringt den Geschäftswert, daher solltet ihr hier am meisten investieren. Mindestens 50% oder mehr eurer Entwicklungszeit solltet ihr darauf verwenden, neuen Wert zu schaffen.

Architekturarbeit – Nur durch kontinuierliche Arbeiten an der Architektur könnt ihr die Software am Leben halten und ermöglicht das Adressieren neuer Zukunftstrends sowie Anforderungen. Ein Empfehlungswert liegt hier bei 15-20% in größeren Projekten.

Mehr Informationen

Minidoku

#minidoku

Download: PNG SVG

Viele Personen verbinden mit Architekturdokumentation lange und komplexe Dokumente, deren Aussagekraft meist fragwürdig ist. Dementsprechend hoch sind die Hürden, selbst mit einer Dokumentation anzufangen. Dass dies aber auch ganz einfach sein kann, demonstriert unsere Minidoku.

Beginne damit, den geschäftlichen Grund der Software zu nennen oder kurz zu beschreiben. Damit ist klargestellt, warum man diese Software überhaupt braucht. Anschließend notiere die drei wichtigsten Qualitätsmerkmale, geordnet nach ihrer Priorität. Zum Schluss werden noch die wichtigsten Design-Entscheidungen skizziert, damit diese nachhaltig dokumentiert und nachvollziehbar sind.

Mit dieser Minidoku ist dann auch erfolgreich der Grundstein zu einer umfangreicheren Architekturdokumentation gelegt. Um diese ohne unnötigen Overhead zu erstellen, kann z. B. ein Template wie arc42 verwendet werden.

Mehr Informationen

Nicht eingeschlagene Wege

#wege

Download: PNG SVG

Jeden Tag werden Entscheidungen getroffen, die unsere Software oft langfristig gestalten. Jeder dieser Entscheidungen liegen mehrere Optionen zu Grunde, von denen allerdings immer nur eine als Lösungsansatz gewählt werden kann. Die gewählte Option wird meistens in einer Architekturdokumentation beschrieben und ist damit nachvollziehbar. Was ist aber mit den Optionen, die ebenfalls betrachtet aber nicht ausgewählt wurden? Auch diese sollten dokumentiert werden, um die getroffenen Entscheidungen langfristig nachvollziehen zu können.

Überlegt euch nun, welche Wege ihr bewusst nicht in eurer Software eingeschlagen habt. Tragt diese auf der Karte ein und beschreibt, was der Grund für die Ablehnung der einzelnen Optionen war. Die Ergebnisse dieser Karte könnt ihr beispielsweise verwenden, um Architecture Decision Records für eure Software anzulegen, um so deren Historie nachvollziehbarer zu gestalten.

Mehr Informationen

How to learn X

#expertise

Download: PNG SVG

Niemand von uns kann alles, aber sicher kann jede/r etwas besonders gut. Dieses besondere Wissen zu teilen, hilft euch, euer Team noch besser zu machen und Wissensinseln zu verringern.

Was ist also euer absolutes Expertenthema? Schreibt dieses Thema – jede und jeder für sich – auf eine Karte und überlegt euch, welche fünf Anleitungen, Bücher, Blogs oder sonstige Ressourcen euch dabei geholfen haben, in das Thema einzusteigen. Sortiert diese, beginnend bei der leichtesten Einstiegsressource, und schreibt sie ebenfalls auf die Karte.

Tauscht euch im Anschluss über eure Ergebnisse aus. Hat vielleicht noch jemand dieses Thema gewählt und es war niemandem bewusst? Perfekt! Denn dadurch ergibt sich eine größere Ansammlung an Wissen und vielleicht auch unterschiedlichen Lernressourcen. Sammelt die ausgefüllten Karten idealerweise an einem Ort, der jeder und jedem im Team zugänglich ist. So könnt ihr jederzeit auf die Lernressourcen zurückgreifen und euer Wissen erweitern.

Risikominimierung

#minirisiko

Download: PNG SVG

Auch wenn wir es ungerne hören: Risiken begleiten unsere Projekte vom ersten Moment an. Häufig wird jedoch vergessen, sowohl diese Risiken als auch deren Gegenmaßnahmen, entsprechend zu dokumentieren. Dies kann später fatale Folgen haben, wenn beispielsweise auf zu fragile Nachbarsysteme gesetzt, oder vielleicht auch relevante Regulatorik übersehen wird.

Überlegt euch, welche Risiken es in eurem Projekt gibt und dokumentiert je ein Risiko pro Karte. Im Anschluss daran notiert ihr die Maßnahme zur Minimierung des Risikos und die davon erwarteten Auswirkungen.

Diskutiert die Ergebnisse miteinander. Habt ihr möglicherweise ein bisher unbekanntes Risiko entdeckt? Sehr gut! Damit könnt ihr euer Projekt gleich etwas sicherer machen und die Architekturdokumentation erweitern. Zusätzlich könnt ihr sowohl euch als auch betroffene Stakeholder dafür sensibilisieren.

Businessability

#vergleich

Download: PNG SVG

Wer kennt es nicht: Man darf ein neues Projekt starten und hat die Qual der Wahl bei der Auswahl der zu nutzenden Technologie. Als Techniker*in nimmt man natürlich am liebsten die neueste Sprache oder das neueste und hipste Framework, aber ist das wirtschaftlich überhaupt vertretbar? Häufig gibt es für neue Technik kaum Support, wenige Spezialisten und hier und da muss auch das Rad erst wieder neu erfunden werden. Das alles kostet Geld – im Worst Case sehr viel Geld. Damit ihr den wirtschaftlichen Faktor einer Technologieentscheidung nicht vernachlässigt, hilft euch diese Karte, die wichtigsten Fragen zu beantworten.

Vergleicht dazu zwei Technologien, die ihr für euer Projekt auswählen würdet. Dann entscheidet für jede Frage, welche der beiden die Anforderungen besser erfüllt. Dazu könnt ihr ein für euch passendes Bewertungssystem nutzen, beispielsweise eine Bewertungsskala von 1-5. Zählt am Ende die Einzelbewertungen pro Technologie zusammen und vergleicht das Ergebnis. Möglicherweise seid ihr überrascht, dass vielleicht doch nicht die neue Supertechnologie “gewonnen” hat, sondern etwas Älteres und Etabliertes.

Das Ergebnis dieser Bewertung könnt ihr nun für die weitere Projektplanung und eine Architekturdokumentation nutzen. Außerdem hilft euch die Bewertung dabei, eine Entscheidung auch bei Projektleiter*innen / -manager*innen vertreten zu können, die weniger auf Technik, aber dafür umso mehr auf Wirtschaftlichkeit einer Lösung achten.

Technologie-Roadmap

#roadmap

Download: PNG SVG

Kennt ihr das? Ihr kommt ganz frisch von einer Konferenz und möchtet den ganzen neuen Kram jetzt und sofort bei euch umsetzen. Dann aber denkt ihr darüber nach, und irgendetwas hindert euch dann doch daran: der ganze vorhandene alte Kram!

Es sind oft die vorhandenen Rahmenbedingungen, welche es (zumindest jetzt) schwer machen, den Tech-Stack zu aktualisieren. Aber wie könnt ihr frühzeitig kommunizieren, dass ihr schon die ein oder andere neue Sache im Blick habt?

Diese Karte hilft euch, einen klaren Kopf zu behalten, anstatt zu verzweifeln und das Handtuch zu werfen. Legt offen, welche Technologie ihr in welchem Stadium der Adaption seht. Bewertet nicht nur die neuen Trend-Themen, welche ihr interessant für eure Software findet, sondern versucht auch, bereits verwendete Technologie in eine der folgenden Stadien einzuordnen und damit die aktuelle Sichtweise auf die Technologien zu kommunizieren:

  1. Abwarten: Schon gehört, passt jetzt noch nicht direkt zu uns
  2. Ansehen: Könnte interessant sein, wir informieren uns näher
  3. Austesten: Es gibt einen guten Anwendungsfall, den wir umsetzen
  4. Anwenden: Ja, hat sich bewährt, wir nehmen das jetzt ins Standardportfolio
  5. Aufhören: Ok, wir wollen hier langsam mal weg davon
  6. Abbauen: Überall, wo wir darüber stolpern, kommt es raus

Mehr Informationen

  • Ein ähnliches Vorgehen ist im Technology Radar zu finden (welches wir zur Inspiration nutzten)

Kundennutzen

#nutzen

Download: PNG SVG

“Lasst uns doch dieses neue Framework einbauen, das letzte Woche erschienen ist!”

Bestimmt habt ihr in einem eurer Projekte diese Aussage in ähnlicher Form schon einmal gehört oder gar selbst getroffen. In erster Linie schreibt ihr eure Software für eure Anwender*innen oder euren Kund*innen. Und dennoch wird bei Entscheidungen viel zu selten darauf geachtet, welchen Nutzen eure Zielgruppe von der bevorstehenden Änderung hat.

Ihr wollt ein eigenes komplexes Logging-Framework für eure Software schreiben und rechnet mit ca. sechs Wochen Entwicklungszeit? Dies wird für die Stakeholder sehr wahrscheinlich – hoffentlich! – keine spürbaren Auswirkungen haben, hindert euch aber gleichzeitig daran, in dieser Zeit neue Features zu entwickeln.

Ihr habt vor, eine weitere, neue Bezahlmethode in euerem System zu integrieren, seid aber nicht sicher, ob dafür neun Wochen Entwicklung verwendet werden können? Viele eurer Anwender*innen könnten dankbar sein, dass sie eine neue Möglichkeit bekommen, Produkte bei euch zu bezahlen. Dieses Feature hat also einen sehr großen Nutzen.

Mit dieser Karte könnt ihr bei euren nächsten Entscheidungen überprüfen, wie viel Nutzen die Anwender*innen daraus ziehen und ob die Änderungen tatsächlich sinnvoll oder notwendig sind.

Mehr Informationen

News

04.11.2019: Das 2. Set ist on- und offline verfügbar!

11.10.2019: Die Karten des 2. Sets sind im finalen Review.

09.08.2019: Wir haben an der Performance und an der Usability gearbeitet

07.08.2019: Das Review des Redesigns des 2. Packs ist erfolgt

08.07.2019: Das Repo zur cards42.org-Seite ist nun public (Tweet)

04.07.2019: Die 1. Auflage von cards42 ist nach der Java Forum Stuttgart Konferenz komplett vergriffen (Tweet)

02.07.2019: 1. Nachdruck des 1. Teils wurde in Auftrag gegeben (mit verbesserter Banderole)

26.06.2019: Die Arbeiten am 2. Teil-Pack (von 3) beginnen. Es wird teils noch spielerischer (Tweet).

24.06.2019: Wir feiern Premiere auf der Konferenz “Developer Week 2019” (Tweet).

18.06.2019: Wir gehen live (Blog-Post)! Der dazugehörige Tweet geht durch die Decke (Tweet). Wir sind gespannt, wie die gedruckten Karten bei euch ankommen!

Häufig auftretende Fragen

Wie komme ich an die Karten?

Die ersten gedruckten Kartenpacks gibt es auf Konferenzen, wo INNOQ mit vertreten ist (wie z. B. der DeveloperWeek, dem Java Forum Stuttgart oder dem Herbstcampus). Wenn alle 42 Karten fertig sind, denken wir über eine Online-Bestellmöglichkeit nach.

Wie entstand die Idee?

Markus ging eines Abends (noch nachhaltig beeindruckt von einem INNOQ Event) in eine Buchhandlung und entdeckte dort die “50 Karten: Kunterbunte Mitmach-Karten für das Handgepäck”. Diese Karten sollen Kinder zum Nachdenken über verschiedenste Dinge anregen. Markus hat sich von diesem Konzept für die “Mitmach-Karten für Softwarearchitekten*innen” inspirieren lassen und so entstanden die ersten Ideen für cards42.

Ein Foto welches die ersten Kartenideen zeigt

Warum der Name “cards42”?

Wir folgen damit der Tradition von Gernot Starke (INNOQ Fellow) bei der Namensgebung. Gernot hat bereits die Projekte arc42 und aim42 ins Leben gerufen. Er hat auch den Ursprung von 42 erklärt.

OK, und die Domain war natürlich auch noch frei ;-)

Feedback

Gerne kannst Du uns Feedback zu cards42 zukommen lassen. Nutze hierfür bitte GitHub Issues oder schreibe uns auf Twitter an. Für längere Rückmeldungen kannst Du gerne auch den Initiator des Projekts, Markus Harrer, direkt per E-Mail unter markus<punkt>harrer<at>innoq<punkt>com anschreiben.

Mitwirkende

Kontakt

Dir gefällt cards42 und Du möchtest mehr davon haben? INNOQ bietet Dir ein umfangreiches Angebot an Themen rund um Softwarearchitektur.

Besuche uns unter https://www.innoq.com/de/architektur/ oder kontaktiere uns unter https://www.innoq.com/de/kontakt. Gerne stellen wir auch das cards42-Projekt inkl. Hands-On direkt in Deiner Firma vor!