“Jeder kann sketchen!” Dies wollten wir in einem einem Meetup zeigen. “Wir” – das sind Kollegen der codecentric AG Berlin, die zeigen, dass Sketchnotes eine klare Berechtigung im Berufsleben haben. Dies ist ein kleiner Rückblick auf das Meetup vom 20.11.2018.<h2>Was sind “Sketchnotes”?</h2>Sketchnotes sind Notizen, die aus Text, Bild und Strukturen bestehen. Der Prozess der Sketchnote-Erstellung wird „sketchnoting“ genannt. Häufig werden Sketchnotes als Alternative zur konventionellen Mitschrift angefertigt. Im Gegensatz zu Texten sind Sketchnotes nur selten linear strukturiert. Die Visualisierung durch Sketchnotes ermöglicht es, komplexe Sachverhalte wesentlich schneller zu erfassen.Sketchnotes sind gerade zur Visualisierung im beruflichen Umfeld sehr gut geeignet. Im Prinzip gibt es drei Ebenen zum Einsatz: Jeder kann für sich selbst Sketchnotes nutzen, um Notizen zu machen und Zusammenhänge zu skizzieren.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qQialxTB6sW9oK0ityUQ"><img width="2224" height="1668" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qQialxTB6sW9oK0ityUQ" alt="Sketchnotes" /></a> Wer mehr möchte, kann seine Skills in seinem Team nutzen, um komplexere Sachverhalte zu visualisieren. Und selbstverständlich braucht niemand davor Halt zu machen, Sketchnotes zu nutzen, Sachverhalte für eine ganze Firma zu visualisieren oder der Öffentlichkeit zur Verfügung zu stellen.<h2>Was macht Sketchnotes so einfach?</h2>Sketchnotes bestehen aus einfachen Elementen, die kreativ zu neuen Formen zusammengesetzt werden können. Was nicht gezeichnet werden kann, wird einfach mit Text ergänzt oder visualisiert.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/7ACYw87rRm6aAaA1mpr4"><img loading="lazy" width="2224" height="1668" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/7ACYw87rRm6aAaA1mpr4" alt="Sketchnotes" /></a> Sketchnotes haben ihren Fokus auf Schnelligkeit. Kleinere Fehler und Ungenauigkeiten sind nicht wichtig, sie gehören sozusagen dazu. Was zählt, ist der Inhalt, der dem Zeichner schnell in Erinnerung ruft, um was es ging. Und mit ein wenig Übung lassen sich Ergebnisse erzielen, die auch anderen eine wertvolle Gedankenstütze bieten.<h2>Das Sketchnotes – Meetup</h2>In Kooperation mit der <a href="https://berlin-dose.de/" target="_blank">Berlin DoSE</a> führte die codecentric AG am Berliner Standort ein Meetup durch. Das Ziel war klar: Dies sollte keine Front-Beschallung werden. Wir wollten unsere Besucher mitnehmen, zum Ausprobieren und Mitzeichnen bewegen. Zwei Stunden gingen wie im Flug vorüber, sowohl Teilnehmer als auch die Referenten nahmen viel für sich mit. Und offensichtlich war für alle etwas dabei (Auszüge):<ul><li>“Ich hätte nie gedacht, dass es so einfach ist!”</li><li>“Ich wusste gar nicht, wie toll es sich auf satiniertem Papier zeichnen lässt!”</li><li>“Is there something more philosophical than to sketchnote about SKETCHNOTING?“</li></ul><blockquote>Hier noch die „Sketchnotes“ vom Sketchnotes Workshop <a href="https://t.co/zmIqFCZZdm">pic.twitter.com/zmIqFCZZdm</a> — Berlin DoSE (@BerlinDoSE) <a href="https://twitter.com/BerlinDoSE/status/1065607792432750592?ref_src=twsrc%5Etfw">22. November 2018</a> </blockquote><h2>Fazit</h2>Sketchen kann wirklich jeder. Ich freue mich, dass unser Meetup-Workshop einen schönen Einstieg für unsere Besucher geliefert hat.Es versteht sich von selbst, dass wir manche Themen nur anschneiden konnten, manches sogar wegfallen lassen mussten. Wer sich ausführlicher mit Sketchnotes beschäftigen möchte, den möchte ich auf unseren Sketchnote-Kurs hinweisen, bei dem wir ins Detail gehen. Der Kurs ist für das erste Quartal 2019 geplant.Kennt ihr schon die Ausgabe 12 unseres Entwickler-Magazins „Der Softwerker“ im Sketchnote-Design? <a href="https://www.codecentric.de/wissens-hub/softwerker/softwerker-12" target="_blank">Hier</a> erfahrt ihr mehr darüber.

Meetup: “Sketchnotes im Beruf”

Lasst uns ein agiles Projekt starten. Von der fachlichen wie von der technischen Seite werden Spezialisten abgestellt, um ein gegebenes Problem zu lösen. Der Rahmen ist gesetzt, die Entwicklung kann also beginnen. Das Team ist frisch, die Anforderungen sind klar, was kann jetzt noch schiefgehen? Einiges, lehrt uns die Erfahrung. Gerade am Anfang ist die Leistungsfähigkeit eines Teams eingeschränkt. Diese Tatsache ist nicht neu. Zur Erklärung wird oft das 4-Phasen-Modell von Tuckman herangezogen. Genau dieses Modell wollen wir in diesem Blogartikel beleuchten.<h2>Tuckmans Phasenmodell (1965/1977)</h2>Die vier Phasen forming, storming, norming und performing werden erstmals 1965 von Bruce W. Tuckman beschrieben.[1] Es handelt sich bei dieser Arbeit um eine Review anderer wissenschaftlicher Artikel. Die Artikel beschäftigen sich mit Gruppendynamik und Teamperformance. Tuckman postuliert als Zusammenfassung ein Modell, in dem ein Team bestimmte Phasen durchwandern muss, bevor es seine optimale Leistungsfähigkeit erreicht.1977 führte Tuckman zusammen mit Mary Ann C. Jensen eine Review seiner damaligen Arbeit durch.[2] Als Ergebnis wurde eine weitere Phase “adjourning” (hier: “unterbrechen”, “aussetzen”) hinzugefügt.<h3>Tuckmans postulierte Phasen</h3><table><tbody><tr><th>Phase</th><th>Charakterisierung</th></tr><tr><td>forming</td><td>“Die Teammitglieder kommen das erste Mal zusammen. Dieses Kennenlernen und erste Beschnuppern ist oft mit Unsicherheit verbunden: Werde ich vom Team akzeptiert? Kann ich mich in diesem Team voll entfalten? In dieser Phase sind die Beziehungen der Teammitglieder untereinander noch völlig offen und unklar.”</td></tr><tr><td>storming</td><td>“Die Teammitglieder versuchen, über Aufgaben- und Rollenkonflikte ihr Revier abzustecken. Diese Phase ist besonders kritisch. Stoßen hier dominante Charaktere aufeinander, kann dies den gesamten Arbeitsprozess des Teams beeinflussen. Deshalb sollte diese Phase mitunter durch einen Moderator begleitet werden.”</td></tr><tr><td>norming</td><td>“Nachdem die Machtkämpfe abgeschlossen sind, kann das Team zusammenwachsen. Das Festlegen von Regeln und die gemeinsame Definition von Rollen (norming) im Team unterstützen diesen Prozess.”</td></tr><tr><td>performing</td><td>“Die sich anschließende eigentliche Arbeitsphase beginnt und wird durch die Regeln gesichert.“</td></tr><tr><td>adjourning (1977)</td><td>“Für temporäre, nur vorübergehend zusammenarbeitende Teams schließen sich Ablösungsprozesse an. Die Teammitglieder lösen sich voneinander und auch von der gemeinsamen Aufgabe. Im Idealfall reflektieren sie gemeinsam oder auch individuell über ihre Teamerfahrungen und lernen daraus für folgende Gruppenarbeiten.“</td></tr></tbody></table>Quelle: Arbeits-, Organisations- und Personalpsychologie für Bachelor [3]<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/H6wvOawRsGTmE76FbfFQ"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/H6wvOawRsGTmE76FbfFQ" alt="Phasenmodell von Tuckman" width="700" height="393" /></a> Phasenmodell von Tuckman</div>Das Modell sagt voraus, dass diese Phasen nicht nur einmal, sondern potenziell wiederholt durchwandert werden. Als Auslöser für diesen ‚Neustart‘ finden sich u.a. diese Gründe:<ul><li>offene Teams, die einem Mitgliederwechsel ausgesetzt sind</li><li>stabile Teams, mit wechselnden Rollen- und Aufgabenteilungen</li></ul><h2>4-Phasen-Modell: Grenzen und Kritik</h2>Ein wichtiger limitierender Faktor wurde bereits erwähnt: Das Modell behandelt kleine Gruppen oder Teams. Die Größenordnung selbst wurde von Tuckman et al. keineswegs festgelegt. Andere Quellen nennen eine Größe von fünf bis acht Personen.Tuckman selbst äußerte eine gewisse Skepsis an seinem Modell, da seiner Ansicht nach die genutzten Quellen als nicht repräsentativ angesehen werden können. Er begründete dies mit der deutlich höheren Zahl an Artikeln über Therapie- und Trainings-Gruppen gegenüber Artikeln über natürliche oder experimentelle Gruppen.Weitere Autoren kritisieren den statischen Charakter des Modells. Demnach müssten alle Phasen durchwandert werden, bevor die komplette Leistungsfähigkeit wiederhergestellt sei. In späteren Erweiterungen des Modells werden Möglichkeiten eingeräumt, in denen das Team in frühere Stadien zurückfallen können.[4][5]Weiterhin beschreibt das Modell, dass die storming-Phase kritisch sei. Es lässt aber offen, ob und wie diese beendet werden kann. Ebenfalls ist offen was passiert, wenn die storming-Phase “niemals” endet und ggf. das Team zerbricht.[5] Diese Punkte hier mit zu betrachten würde den Rahmen dieses Blogartikels sprengen.<h2>Zusammenfassung</h2>Das Tuckman-Modell ist das mit Abstand bekannteste Modell zur Teambildung. Obwohl es durchaus Hinweise aus Beobachtungen gibt, die sich mit dem Modell erklären lassen, sollte man nicht außer Acht lassen, dass die Datenlage nicht als gesichert gilt. Interessanterweise hat die fünfte Phase “adjourning” sehr selten Einzug in die spätere Literatur gehalten. Bis heute wird daher häufig vom 4-Phasen-Modell gesprochen.Das Modell lässt bestimmte Fragen offen. Beispielsweise müssen sich nicht alle Teammitglieder in der selben Phase befinden oder die Wirkung von einer lang andauernden storming-Phase.Als Alternative zum 4-Phasen-Modell wollen wir hier nur in aller Kürze und beispielhaft das kybernetische Modell erwähnen.[6] Dieses Modell basiert auf der Theorie von geschlossenen Systemen, das durch Rückkopplungsmechanismen auf innere Störungen reagiert. Die Teamdynamik wird daher durch das Verhalten der Teammitglieder selbst bestimmt. Ein Durchlaufen festgelegter Phasen wird dadurch in Frage gestellt.Abschließend kann gesagt werden, dass das 4-Phasen-Modell eine gute Grundlage für die Erklärung vieler Gruppendynamiken ist. Man sollte jedoch im Kopf behalten, dass das Modell längst nicht alle Fälle abdeckt. Es können damit auch Gruppendynamiken auftreten, die dann nicht mehr durch das 4-Phasen-Modell erklärt werden können.<h2>Quellen</h2><ol><li>Tuckman B. W. Developmental sequence in small groups. In: Psychological Bulletin. 63, 1965, 384–399.</li><li><a href="https://www.staff.science.uu.nl/~daeme101/Stages%20of%20Small-Group%20Development%20Revisted.pdf" target="new">Tuckman B. W., Jensen M. A. C. (1977). Stages of Small-Group Development Revisited. Group & Organization Management, 2(4), 419-427.</a> </li><li><a href="https://lehrbuch-psychologie.springer.com/sites/default/files/atoms/files/web-exkurs.008.05.pdf" target="new">Kauffeld, S. (2014). Arbeits-, Organisations- und Personalpsychologie für Bachelor. Springer-Verlag: Berlin, Heidelberg.</a> </li><li>Brodbeck, F. C. (2004). Analyse von Gruppenprozessen und Gruppenleistung. In H. Schuler (Ed.), Lehrbuch Organisationspsychologie (pp. 415-438). Bern: Hans Huber.</li><li><a href="http://www.fernuni-hagen.de/wirtschaftswissenschaft/studium/download/lp_31711.pdf" target="new">Weibler J., Neuenfeld M, Serhane W., Bergin M. (2003) Organizational Behavior III. Kurs 41712. Fernuniversität Hagen</a> </li><li><a href="http://www.zrm.ch/images/stories/download/pdf/wissenschftl_arbeiten/seminararbeiten/seminararbeit_herold_20030502.pdf" target="new">Herold F. (2003) Seminararbeit: Der Weg der Gruppe. Universität Zürich, Pädagogisches Institut, Pädagogische Psychologie I</a> </li></ol>

Tuckmans 4-Phasen-Modell

Es ist kein Geheimnis: Immer mehr Firmen steigen auf eine Softwareentwicklung mit agilen Methoden und DevOps um. Auf Rückfrage hören wir oft, dass die klassischen Entwicklungsprozesse zu langsam sind. Was genau heisst das?<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aNmvIlWkT2ihJ28DUHwN"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aNmvIlWkT2ihJ28DUHwN" alt="Die klassische Arbeitsteilung sorgt für &quot;Zäune&quot; zwischen den Abteilungen" width="1959" height="627" /></a> Klassischer Entwicklungsprozess – nach Fertigstellung eines Lasten- und Pflichtenheftes wird der Auftrag in der Entwicklungsabteilung realisiert. Nach Beendigung der Aufgabe wird die Software in Betrieb genommen.</div>Eines ist klar: Der Weg von einer Idee bis zu ihrer Realisierung kann in klassischen Organisationen schon mal mehrere Monate bis Jahre dauern. Dies ist in Hinblick auf die steigende Komplexität in den Domänen und Prozessen auch kein Wunder. Aber worauf bezieht sich dann das Gefühl, der Entwicklungsprozess sei zu langsam? Auf die Reaktion des Kunden auf die fertige Software? Unternehmen beobachten, dass der Kunde die Software nicht nutzen will oder mit ihr unzufrieden ist, weil sie an seinen Bedürfnissen vorbeigeht.Das ist nicht verwunderlich: Die Wahrscheinlichkeit, dass ein Softwareprodukt nicht zu den Bedürfnissen passt, steigt mit der Dauer, die es braucht, um das Produkt auf den Markt zu bringen.Es ist klar, da muss “etwas” optimiert werden. Bei Softwareprodukten kann doch nur die Softwareentwicklung das Bottleneck sein… Oder?<h2>Vom Umgang mit Kunden-Feedback</h2>In klassischen Organisationsstrukturen wird Kunden-Feedback über separate Abteilungen, Call Centers oder – bei Geschäftskunden – über Key Account Manager erfasst. In Bezug auf Wissen über die (Un-)Zufriedenheit der Kunden gibt es die gesamte Spannbreite von “nicht präsent/unbekannt” bis hin zu “umfangreich und durch Studien gefestigt”.Das Problem ist nun, wie dieses Wissen um die Kundenbedürfnisse Eingang in die Software findet. Die klassische Ablauforganisation wirft zur Lösung die gesamte Maschinerie des Projektmanagements erneut an: Wie könnte eine (neue) Lösung aussehen? Wie schaut der (veränderte) Projektplan aus? Wann stehen die (schon verplanten) Ressourcen zur Verfügung, um die Kosten, Architektur und Projekte zu planen? Wer plant das Projekt, die Umsetzungsstrategie? Wer entwickelt wann die notwendige Softwareänderung?Ideen und Umsetzungspläne müssen von allen möglichen Fachabteilungen abgesegnet und genehmigt werden. Das Selbstverständnis ist, dass nur ein gut durchdachtes Produkt/Projekt erfolgreich sein kann. Dieser Weg kostet natürlich Zeit. Die Umsetzung muss mit dem Projektmanagement und der Softwareentwicklung abgesprochen werden. Zwischen einer Idee und dem Beginn (!) der Umsetzung liegen auf diese Weise mehrere Wochen.<h3>Erkenntnisse</h3>(#1) Die Ablauforganisation selbst ist der Grund dafür, dass Informationen über veränderte Kundenwünsche sehr spät in der Softwareentwicklung auftauchen.(#2) Eine Firma muss erheblich schneller in der Lage sein, aus Kundenfeedback Änderungen an ihrer Software ableiten zu können.<h2>Agile Softwareentwicklung</h2>Mit der Einführung von agilen Methoden wie SCRUM und Kanban ändert sich nun zumindest das Problem der langen Planung. Die <a href="http://agilemanifesto.org/iso/de/principles.html" target="_blank">Prinzipien</a> des <a href="http://agilemanifesto.org/iso/de/manifesto.html" target="_blank">Manifests für Agile Softwareentwicklung</a> sieht dafür u.a. eine “enge Zusammenarbeit von Fachexperten und Entwicklern” vor. In der Praxis heißt das, dass das Anforderungsmanagement (jetzt unter dem Namen Product Owner, PO) und die Entwicklung in ein Team zusammengeführt werden.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YkmlFH3nSquPv6s5ih8j"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YkmlFH3nSquPv6s5ih8j" alt="Agile Software Development sorgt für eine iterative Softwareentwicklung" width="1965" height="633" /></a> Agile – PO und Team konzipieren und entwickeln iterativ neue Versionen der Software; Zwischenstände werden als Release ausgerollt und in Betrieb genommen.</div>Diese Umstellung führt dazu, dass dem Unternehmen nun ein Ansprechpartner zur Verfügung steht, mit dem Änderungen an der Software besprochen werden können. Langfristige Projektpläne werden nicht mehr generiert, stattdessen werden Aufgaben kurzfristig bestimmt und umgesetzt. Das Team bestimmt selbst die Priorität und damit die Reihenfolge, mit der Aufgaben umgesetzt werden.Für Softwareentwickler entsteht eine neue Situation: Anstelle von detaillierten Weisungen werden nun nur noch Ziele (das “Was”) grob umrissen, die Umsetzung (das “Wie”) liegt in deren Verantwortung. Das bedeutet auch eine Verschiebung im Berufsbild: Diskussionen, Streitfähigkeit, Kompromissbereitschaft und Feedback werden essenziell. Der PO kommuniziert Anforderungen an das Team und erwartet direktes Feedback.Durch die iterative Softwareentwicklung kann der Kunde nun regelmäßig die Software begutachten und über Anforderungsänderungen informieren. Die Bereitstellung von neuen Softwareversionen wird stark verkürzt.Dennoch gibt es Verbesserungspotenzial. Das Manifesto definiert als erstes Prinzip: <a href="http://agilemanifesto.org/iso/de/principles.html" target="_blank">“Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.”</a>  Doch wer genau ist „der Kunde“? Viele Firmen interpretieren ihre Produktabteilung als internen Kunden, die das Produkt verwaltet und dem Kunden (= Nutzer) zur Verfügung stellt. Diese Sichtweise ist meines Erachtens falsch, denn es geht beim Feedback eindeutig um das des (zahlenden) Nutzers der Software. Leider wird durch dieses Missverständnis das Einholen von wertvollem Feedback verzögert.Trotz vieler wertvoller Impulse gab es retrospektiv auch Kritik am Manifesto, u. a.  dafür, dass es sich ausschließlich auf die Softwareentwicklung bezieht. Dieser Fokus führt in der Praxis dazu, dass der Betrieb der Software weiterhin losgelöst von der Entwicklung organisiert wird. Interessanterweise liegt das Problem erstmals in der Kette HINTER (“downstream”) der Softwareentwicklung. Was nützt eine schnell implementierte Software, wenn sie dem IT-Betrieb nach wie vor über den Zaun geworfen wird? Das Fehlen der Kommunikation sorgt dafür, dass der IT-Betrieb Zeitpläne für die Inbetriebnahme festlegen muss. Wo wir gerade bei (Nicht-)Kommunikation sind: Probleme, die ausschließlich im Betrieb auftreten, landen aufgrund dieser Grenzen wiederum gar nicht oder verzögert in der Entwicklung. <a href="http://www.melconway.com/Home/pdf/committees.pdf" target="_blank">Conway’s Law</a> lässt grüßen.Laufzeitprobleme, wie langsame Antworten oder Serverausfälle, machen den Kunden aber genauso unzufrieden wie schlecht programmierte Software.<h3>Erkenntnisse</h3>(#3) Mit der agilen Softwareentwicklung stehen für Entwickler erstmals Kommunikationsfähigkeiten im Fokus.(#4) Abteilungsgrenzen behindern den für Softwareprojekte notwendigen Austausch von Feedback.<h2>DevOps</h2>Die Agile Softwareentwicklung löste Diskussionen in allen IT-Abteilungen aus. Eine der bekanntesten Weiterentwicklungen ist die <a href="/wissens-hub/fachmedien">DevOps-Bewegung</a> . Das Akronym aus “Developer” und “Operations” (oder kurz “OPS”) deutet den Wunsch nach einer engen Zusammenarbeit zwischen Entwicklern und Betriebsspezialisten an.Wurden jetzt nur die Zäune der Abteilungen eingerissen? Es ist mehr: Die DevOps-Bewegung führt dazu, dass die Arbeitsorganisation zwischen IT-Abteilungen zugunsten der Zusammenarbeit von Experten in den Hintergrund tritt. Da das Produkt nicht mehr in der Verantwortung einer einzelnen Abteilung liegt, wird dies an das Team übertragen. Damit sind alle Experten eines Teams gleichermaßen für die Qualität und Bereitstellung der Software verantwortlich.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YSOdoywbS3ipr2O5mhBD"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YSOdoywbS3ipr2O5mhBD" alt="DevOps empowers continuous feedback" width="1647" height="564" /></a> DevOps – das Team erfasst die Erwartungen des Kunden/Nutzers, priorisiert diese und entwickelt fortlaufend Features, die sofort in Betrieb genommen werden; Feedback erfolgt durch den Kunden/Nutzer</div>Die DevOps-Bewegung hat es ermöglicht, den Fokus auf die gesamte Wertschöpfungskette einer Software und auf Feedbackschleifen zu legen. Dies bezeichnen Gene Kim, Kevin Behr und George Spafford als den zweiten Weg ihres Konzeptes <a href="http://www.itrevolution.com/wp-content/uploads/2012/11/11things.pdf" target="_blank">“Die drei Wege”</a> .Durch die Zusammenführung von fachlichen und technischen Experten stehen nun allen Mitgliedern mehr und bessere Informationen zur Verfügung. Ops-Werkzeuge wie Monitoring und Alerting liefern Feedback über den Zustand des Produktes.Meiner Meinung nach hat die DevOps-Bewegung die entscheidenden Impulse geliefert, um das agile Prinzip “Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.” in den korrekten Kontext zu setzen. Denn in letzter Konsequenz bedeutet dies, alle Experten, die zum Erfolg des Produktes beitragen, in das Produktteam zu integrieren. Dies schließt Kollegen aus Abteilungen wie Marketing, Finance, Customer Care, IT Ops etc. mit ein.Ich möchte noch einen wichtigen Experten für das Produkt explizit erwähnen: den (Be)-Nutzer der Software. Damit erreicht das Kunden-Feedback unmittelbar alle am Produkt beteiligten Experten.<h3>Erkenntnisse</h3>(#5) Um ein Softwareprodukt marktorientiert erstellen zu können, ist es notwendig, alle beteiligten Experten-Rollen in einem Team zusammenzuführen, um einen ungehinderten Informationsaustausch zu ermöglichen.(#6) Am schnellsten erhält das Team Feedback, wenn der Software-Nutzer selbst Teil des Teams ist. <h2>Zusammenfassung</h2>Ich hoffe, ich konnte mit meinen Ausführungen verdeutlichen, warum ich Feedback eine so hohe Wichtigkeit für Softwareprodukte beimesse. Viele Änderungen, die das Manifest der Agilen Softwareentwicklung und die DevOps-Bewegung in die Entwicklung von Software gebracht haben, haben den Informationsaustausch gefördert und damit die Reaktionsfähigkeit vieler Firmen erhöht. Für mich sind die folgenden Erkenntnisse besonders wichtig:<ul><li>Die klassische Ablauforganisation selbst ist der Grund dafür, dass Informationen über veränderte Kundenwünsche sehr spät in der Softwareentwicklung auftauchen.</li><li>Um ein Softwareprodukt marktorientiert erstellen zu können, ist es notwendig, alle beteiligten Experten-Rollen in einem Team zusammenzuführen, um einen ungehinderten Informationsaustausch zu ermöglichen.</li><li>Am schnellsten erhält das Team Feedback, wenn der Software-Nutzer selbst Teil des Teams ist.</li></ul>Für jeden Kollegen aus den Entwicklungs- und Ops-Abteilungen stehen neue Herausforderungen an. Es reicht nicht, Experte für das eine und/oder andere technische Thema zu sein. Das Thema <a href="/wissens-hub/blog?q=Soft+Skills">“Soft Skills”</a> verdient einen erheblich stärkeren Fokus. Neben der Fähigkeit, sich Wissen anzueignen, wird es nun wichtig, mit Experten aus den verschiedensten Fachrichtungen zu kommunizieren, sich auszutauschen, zu diskutieren, Feedback zu geben und einzuholen.Damit möchte ich diesen Blogbeitrag gerne schließen, nicht jedoch, ohne Sie/Dich/Euch um Feedback zu bitten.

DevOps: Es geht um Feedback

Heute beginnt ein neuer Sprint, das Portal, das wir für den Kunden bauen, befindet sich kurz vor dem Launch. Der Product Owner (PO) hat bereits angekündigt, dass noch ein wichtiges Feature fehlt. Ersten Schätzungen zufolge könnte das recht viel Zeit in Anspruch nehmen. 10:00 Uhr: es ist Sprint Planning, zusammen mit dem PO überlegt das Team, wie es das Feature schnellstmöglich umsetzen könnte. Die Diskussion zieht sich in die Länge. Kollege A schlägt vor, doch einfach mal das Feature “ins System zu hacken”: “Vergiss die Tests, die kosten doch sowieso nur Zeit. Und die Fallback-Geschichten bei der Service-Einbindung sparen wir uns auch im ersten Schritt”. Dem Kollegen B platzt der Kragen: “Bist Du irre? Du weißt doch, wir arbeiten hier testgetrieben!” Kollege A: “Du hast doch gehört, es soll schnell gehen. Willst Du mit Deinem TDD das ganze Projekt sprengen?!” Diese Situation ist typisch. Es gibt eine Meinungsverschiedenheit, die Diskussion eskaliert. Am Ende bleibt zu wenig Zeit, um eine durchdachte Lösung zu finden. Warum müssen die Kollegen A und B auch immer so emotional sein?Nun, es gibt auch andere Wege. Als Beobachter dieser Situation wird offensichtlich, dass die Kollegen einfach nur unterschiedliche Positionen einnehmen. Die Frage ist nun, wie man mit dieser Situation umgeht. Wie könnte Empathie bei diesem Thema helfen?<h2>Was ist Empathie?</h2><a href="http://www.soft-skills.com/empathie/" target="_blank">Empathie</a> ist die Fähigkeit, sich in die Gedanken, Gefühle und das Weltbild von anderen Menschen hineinzuversetzen. Der Begriff leitet sich vom griechischen Wort „empatheia“ für „Einfühlung“ ab. Die eigene Perspektive, Anschauung und Gedanken spielen dabei keine Rolle.Empathie sollte nicht mit <a href="https://de.wikipedia.org/wiki/Sympathie" target="_blank">Sympathie</a> (die “… sich spontan ergebende gefühlsmäßige Zuneigung”) verwechselt werden: der Beobachter wird und muss nicht alle Werte und Erfahrungen in gleicher Weise bewerten wie der Andere.<h2>Emotionale Reaktionen</h2>Eine Erklärung für emotionale Reaktionen würde den Rahmen dieses Blogartikels sprengen. Ich möchte daher auf das Kommunikationsquadrat von Friedemann Schulz von Thun verweisen. Das Modell beschreibt die Ebenen “Sachinhalt”,  “Appell”, “Beziehung” und “Selbstkundgabe”, auf denen sich Menschen je nach innerem Zustand meist unbewusst mitteilen. Zurück zu unserem Beispiel: Kollege A macht den Vorschlag, mit dem Programmieren zu beginnen und sich auf das Wesentliche zu konzentrieren. Wieso reagiert Kollege B darauf emotional? Die Sachargumente sind schnell klar: Tests sind ihm wichtig, er möchte nicht darauf verzichten.In unserem Beispiel sagt Kollege B: “Bist Du irre? Du weisst doch, wir arbeiten hier testgetrieben!” Er teilt also mit, dass er nicht auf TDD verzichten möchte (“Selbstkundgabe”). Der scharfe Ton (“Du weißt doch!”) macht klar, dass B seinen Kollegen auffordert, nicht auf Tests zu verzichten. Er gibt zu verstehen, dass er sich mit der Herangehensweise seines Kollegen an das Problem nicht anfreunden möchte. Eine mögliche Interpretation könnte sein: “Du bist leichtfertig und schaffst mir Probleme in der Zukunft”.  <h2>Was mache ich nun mit Empathie?</h2>Empathische Menschen reagieren oftmals intuitiv. Sie nehmen wahr, dass “etwas nicht stimmt” und versuchen zu ergründen, was die Ursache für diese Emotionen ist. Dies geschieht durch einfaches Nachfragen. Schließlich agieren sie zunächst nur auf der Basis von subjektiven Eindrücken. Ziel ist es, das Problem aus der Sicht des Kollegens verstanden zu haben. Auch bei der Problemlösung kann es nicht schaden, auf die oben beschriebenen Signale zu achten.Menschen, die das Gefühl haben, wenig oder gar nicht empathisch zu sein, sollten aber nicht so schnell aufgeben. Wir sind durch Schule und Arbeit darauf trainiert, Diskussionen auf der Sachebene wahrzunehmen. Es schadet nicht, bei Diskussionen einfach mal auf sein Gefühl zu hören und darüber zu reflektieren, was man neben der Sachinformation wahrgenommen hat. Wichtig: Empathie ist nur der erste Schritt. Um seine Eindrücke zielgerichtet einsetzen zu können, müssen weitere Fähigkeiten trainiert werden. Kommunikationstechniken helfen beispielsweise, heikle Themen so zu kommunizieren, dass sie vom Empfänger ohne weitere Eskalation akzeptiert werden können. Die eigene Kommunikation kann somit auch zum Problem werden. Hier kommt neben der verbalen auch die nonverbale Kommunikation ins Spiel.<h2>Verbale Kommunikation</h2>Unter verbaler Kommunikation verstehe ich hier alles, was durch gesprochene Worte ausgedrückt wird. Es ist nun eine Sache, bestimmte Eindrücke wahrzunehmen. Es ist eine andere Sache, eine Wahrnehmung in eine Frage umzuformulieren. Falsche Formulierungen können schnell zu Eskalationen führen.“Du bist ja irre” war eine erste Reaktion, mit der Kollege B seinem Unmut Ausdruck verlieh. Der Vorwurf ist im Raum, Kollege A entscheidet sich für einen direkten Gegenangriff (“Willst Du … das ganze Projekt sprengen?!”). Wer sich in die Situation einer anderen Person versetzen möchte, sollte seinem Gesprächspartner einen offenen Rahmen bieten. Ein wertschätzender und achtsamer Fragestil hilft allen Beteiligten, sich auf die eigentliche Frage zu fokussieren. Ich-Botschaften helfen, Vorwürfe zu vermeiden. Kollege A beispielsweise dürfte mit dieser Frage weiter kommen: “Ich merke, dass Dich meine Lösung nicht überzeugt. Wo siehst Du das Problem?” Natürlich gibt es eine Vielzahl an weiteren Hilfsmitteln und Techniken, die hier helfen können, z.B. aktives Zuhören, Spiegeln oder Reflexion. Eine strukturierte Feedbackkultur hilft jedem Teammitglied, Feedback geben und annehmen zu können.<h2>Nonverbale Kommunikation</h2>“Man kann nicht nicht kommunizieren”. So  lautet <a href="http://www.paulwatzlawick.de/axiome.html" target="_blank">Paul Watzlawicks erstes Axiom</a> . Gemeint ist damit, dass nicht nur das gesprochene Wort, sondern auch die Intonation, Körpersprache, selbst Schweigen eine Form der (nonverbalen) Kommunikation darstellen. Warum ist das wichtig? Es ist wichtig, sich bewusst zu machen, dass nicht nur das, WAS gesagt wurde, wichtig ist, sondern auch, WIE es gesagt wurde. Ein Kollege, der beispielsweise mit einem schlecht gelaunten Gesichtsausdruck einer Entscheidung zustimmt, macht unbewusst klar, dass er nichts von dieser Entscheidung hält und dass er sie vermutlich nicht lange unterstützen wird.  In dieser Situation ist eine empathische und achtsame Herangehensweise essentiell. Zum einen muss der offensichtliche Widerspruch aufgeklärt werden. Zum anderen wäre es fatal, den Kollegen mit dem Widerspruch zu konfrontieren. Hier helfen die beschriebenen Kommunikationstechniken, Feedback und aktives Zuhören, um die Situation zu klären und eine Lösung zu finden. Der entscheidende Unterschied liegt in der Vertrauenswürdigkeit und der Tragfähigkeit der Entscheidung.Wir alle senden nonverbale Signale. In bestimmten Situation sind diese Signale höchst ungewollt, da sie unsere wahre Intention verraten können. Ich persönlich möchte aber davon abraten, diese Kommunikation unterdrücken zu wollen. Das gelingt mehr schlecht als recht. Alternativ könnte man die eigene Reaktion dahingehend nutzen, zu hinterfragen, ob man selbst „Teil des Problems” ist. <h2>Zusammenfassung</h2>Empathie ist die Fähigkeit, sich in die Gedanken, Gefühle und das Weltbild von anderen Menschen hineinzuversetzen. Empathie ist gerade dann hilfreich, wenn eine Person über die verbale Kommunikation ein Botschaft sendet, die durch die nonverbale Kommunikation nicht bestätigt wird. Empathie ist dabei zunächst nur als Fähigkeit zu verstehen. In Kombination mit Kommunikationstechniken wird aus Empathie ein wertvolles Werkzeug im täglichen Umgang mit Kollegen und Kunden. Da die Interpretation stark von der eigenen Person abhängt, ist die Reflexion über sich selbst der dritte Baustein.In unserem Beispiel klärte sich die Situation, nachdem Kollege B seinen Unmut neu formulierte. Es stellte sich heraus, dass Kollege A noch keine klare Lösung gefunden hatte und Verzögerungen befürchtete. Diese Bedenken konnte Kollege B recht schnell ausräumen, so dass das Team zügig mit der Umsetzung beginnen konnte. Die Fallback-Lösung wurde ein paar Tage nach dem Launch bereitgestellt. Der PO zeigte sich sehr zufrieden mit der Lösung. Ich hoffe, mit diesem Blogartikel weitere Menschen zu ermutigen, sich mit dem Thema Empathie zu beschäftigen. Ich möchte diesen Artikel mit einem Rat abschließen: bitte sprechen Sie in Meetings nicht darüber, dass sie Empathie einsetzen wollen. Warum nicht? “Ich bin jetzt mal empathisch…” kommt nicht besonders gut an. Wie sehen Sie das?

Wie hilft Empathie bei der Softwareentwicklung?

JWT ist die Abkürzung für “JSON Web Token”, das für den Einsatz im Web konzipiert wurde. Typisches Einsatzgebiet für JWT ist die fortlaufende Authentifizierung bei SSO (“single sign-on”), JWT ist aber flexibel einsetzbar für alle Bereiche, in denen kompakte, signierte und u. U. verschlüsselte Informationen übertragen werden müssen. Dieser Artikel gibt einen Überblick über den Aufbau und die Nutzung von JWT.Eine konkrete Implementierung gibt es beispielsweise bei Atlassian Connect. Die Cloud-Lösung für Produkte wie JIRA, Confluence, Bamboo und andere nutzt JWT zur Kommunikation mit Add-ons von Drittanbietern. JWT wird hier eingesetzt, um Requests zu authentifizieren und die Integrität der Anfrage sicherzustellen. Einen Überblick über Atlassian Connect bietet <a href="/wissens-hub/blog/atlassian-connect-die-sicherheit-von-add-ons">unser Artikel</a>  über die Sicherheit von Atlassian.<h2>Aufbau eines JWT-Token</h2>Das JWT ist ein einfacher String, der als Request-Parameter oder im Header übertragen wird. Ein JWT hat den folgenden Aufbau:

```
HEADER.PAYLOAD.SIGNATURE
```

Ein JWT-Token besteht also aus drei Teilen, die durch Punkte (.) voneinander getrennt sind. Hier sind beispielhafte Belegungen dieser Teile:<ul><li>Header: “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9”</li><li>Payload: “eyJpZCI6IjEyMzQ1Njc4OTAiLCJuYW1lIjoiTWFydGhhIFRlc3RlciJ9”</li><li>Signatur: “AfF8fGzbhhpS9k-rgJt7RlZaUnP9phwmnPTku2fs4o0”</li></ul>Der Header beschreibt den Signatur- und/oder Verschlüsselungsalgorithmus und den Token-Typ. Die Daten werden im JSON-Format abgelegt und Base64-kodiert. Das vorliegende Beispiel sieht im Klartext so aus:

```
{"alg":"HS256","typ":"JWT"}
```

Im Beispiel wurde die Payload des JWT mit HMAC SHA256 (abgekürzt “HS256”) signiert.Als Payload wird das JSON-Objekt bezeichnet, das aus einer “beliebigen” Anzahl von Key/Value-Paaren besteht. Diese Key/Value-Paare werden ”Claims” genannt (siehe unten). Der Payload  wird ebenfalls Base64-kodiert. Im Beispiel hat der Payload folgenden Inhalt:

```
{ "id": "1234567890", "name": "Martha Tester" }
```

Das letzte Element ist die Signatur, die aus dem Header und der Payload berechnet wird. Der Algorithmus kann in Pseudocode wie folgt beschrieben werden:

```
content = base64UrlEncode(header) + "." + base64UrlEncode(payload);
signature = HMACSHA256(content, secret);
```

Auch die daraus entstehende Signatur wird ebenfalls Base64-kodiert und bildet den dritten Abschnitt des JWT.<h2>Payload und Claims</h2>Wie bereits erwähnt, enthält der Payload eine beliebige Anzahl von Key/Value-Paaren. Der Key wird in diesem Kontext als “Claim” bezeichnet. Prinzipiell darf der Payload beliebig viele Claims beinhalten. Natürlich wächst das JWT mit jedem Element und benötigt dann auch mehr Ressourcen bei der (De-)Kodierung. Es empfiehlt sich daher, die Informationen im JWT stark zu begrenzen.Claims können in drei verschiedene Typen aufgeteilt werden: registrierte, öffentliche und private Claims.<h3>Registrierte Claims</h3>Es handelt sich hierbei um Keys, deren Zweck in einem Standard festgelegt ist. Wichtig: Die Spezifikation definiert, dass alle Claims optional sind! Applikationen können also frei wählen, ob sie diese Felder nutzen. Wenn sie genutzt werden, sind öffentliche Claims wie folgt zu nutzen (Auszug):<ul><li>“iss” (Issuer): identifiziert die Einheit, die das JWT ausgegeben hat; Beispiel: die ID einer bestimmten JIRA-Applikation</li><li>“sub” (Subject): Dieses Feld wird dazu genutzt, den Nutzer, auf den sich eine Aktion bezieht, zu identifizieren; Beispiel: der Nutzer, der in JIRA eine Aktion ausgelöst hat</li><li>“aud” (Audience): identifiziert potenzielle Empfänger des JWT</li><li>“exp” (expiration time): der Zeitpunkt, zu dem das JWT-Token nicht mehr akzeptiert werden darf</li><li>“jti” (JWT ID): Dieser Wert ist dazu gedacht, Events zu markieren, die nur einmal verarbeitet werden sollen. Wie diese ID im konkreten Fall gespeichert und zur (In-)Validierung eines Events genutzt wird, ist die Aufgabe der Applikation selbst.</li></ul>Weitere Claims sind im <a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a> beschrieben.<h3>Öffentliche (“Public”) Claims</h3>Diese Claims bezeichnen Key/Values, die zusätzlich zum Standard benutzt werden können. Um Kollisionen in der Semantik der Keys ausschließen zu können, sind diese Claims öffentlich registriert. Das Registrierungsverfahren ist in einem <a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a>   beschrieben. Einen Überblick über öffentliche Claims gibt <a href="http://www.iana.org/assignments/jwt/jwt.xhtml">IANA</a> .<h3>Private Claims</h3>Hierbei handelt es sich um Keys, die bei verschiedenen JWT-Nutzungen eine unterschiedliche Semantik aufweisen können. Die Keys sind für Parteien gedacht, die über JWT kommunizieren wollen und für ihren Anwendungsfall einen Key explizit vereinbaren wollen. Die Namen sind nicht öffentlich registriert (siehe auch <a href="http://www.iana.org/assignments/jwt/jwt.xhtml">IANA</a> ).<h2>Vertraulichkeit und Datenintegrität</h2>Das JWT basiert auf zwei weiteren Standards, die zur sicheren Kommunikation im Web gesetzt wurden. Dies ist zum einen JWS (JSON Web Signature), ein Schema, das die Signierung von Nachrichten regelt, zum anderen JWE-Schema (JSON Web Encryption), das zur Verschlüsselung von JWT genutzt wird. Je nach Sensibilität der Daten müssen eines oder beide Verfahren für das JWT umgesetzt werden. Im Zentrum dieser Betrachtung stehen die Claims, die im Payload untergebracht sind. Egal, welche Stufe eingesetzt wird, es empfiehlt sich in jedem Fall, SSL für die Kommunikation zu nutzen.<h3>Keine Sicherung</h3>Für den Fall, dass die Daten keinen hohen Schutzcharakter aufweisen, kann im Header als Verschlüsselungsalgorithmus “None” angeben werden. In diesem Fall muss keine Signatur generiert werden. Der Payload kann nach der Base64-Entschlüsselung im Klartext gelesen werden. Es gibt keine Aussage darüber, ob die Nachricht vom richtigen Absender kam und ob die Nachricht verändert wurde.<h3>Nur Signatur (JWS)</h3>Für die meisten Fälle reicht es aus, sicherzustellen, dass die Daten vom richtigen Absender kommen und nicht verändert wurden. Der Payload kann auch hier nach der Base64-Entschlüsselung im Klartext gelesen werden. Das JWT enthält jedoch nun auch eine Signatur, die die Integrität der Nachricht sicherstellt. Das Verfahren ist das, welches eingangs im Detail vorgestellt wurde. Der <a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a> fordert, dass mindestens HMAC-SHA256 (“HS256”) implementiert wurden, er empfiehlt außerdem die Implementierung von  RSA-SHA256 (“RS256”) und  ECDSA-SHA256 (“ES256”). Der Empfänger weiß nun, wer die Nachricht versandt hat und dass die Nachricht nicht verändert wurde. Die Payload kann jedoch nach der Base64-Entschlüsselung im Klartext gelesen werden (keine Vertraulichkeit).<h3>Signatur (JWS) und Verschlüsselung (JWE)</h3>In der letzten Stufe werden die Inhalte des Claims selbst verschlüsselt (JWE-Schema) und zusätzlich über  das JWS-Schema signiert. Die Inhalte können dann nur noch über das gemeinsame Kennwort oder den privaten Schlüssel entschlüsselt werden.Bibliotheken können dieses Level optional unterstützen. Sollte dies der Fall sein, sind nur die folgenden Standards Pflicht: RSAES-PKCS1-v1_5 mit 2048-Bit-Schlüssel („RSA1_5“), AES Key Wrap mit 128- and 256-Bit-Schlüssel („A128KW“ und „A256KW“) sowie AES-CBC/HMAC SHA-2 („A128CBC-HS256“ und „A256CBC-HS512“). Der Absender ist nun authentifiziert, die Nachricht ist authentisch und vertraulich.<h2>Gültigkeitsdauer eines JWT</h2>Die Gültigkeit eines JWT ist begrenzt, wenn der registrierte Claim “exp” benutzt wird. Dieser enthält einen Zeitstempel. Der <a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a> schreibt vor, dass das Token nicht mehr weiter verarbeitet werden darf, wenn dieser Zeitpunkt überschritten wurde. Das JWT ist dann als ungültig anzusehen.<h2>Wie wird das JWT genutzt</h2>Da JWT erst sinnvoll ist, wenn eine Signatur verwendet wird, muss vor der eigentlichen Nutzung ein Schlüssel (der <a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a> spricht vom “secret”) festgelegt werden. Dieser kann – z.B. als Antwort auf ein Login – zwischen den Kommunikationspartnern ausgetauscht werden. Asymmetrische Verfahren werden auch unterstützt, es werden dann die öffentlichen Schlüssel ausgetauscht. Der Schlüssel sollte mindestens über eine gesicherte HTTP-Verbindung (HTTPS) übertragen werden, um ein einfaches Auslesen zu vermeiden. Noch besser ist natürlich der Gebrauch asymmetrischer Verfahren.Mit dem Austausch des Schlüssels kann nun die Kommunikation zwischen den beiden Partnern durchgeführt werden. Dazu generiert die Applikation für ihren Request den vereinbarten JWT mit dem Schlüssel des Partners und liefert das JWT als Parameter (z.B. ‘jwt’ bei GET-Requests) oder als “Authorization”-Header (bei POST, PUT, OPTIONS, DELETE) an den Partner aus. Atlassian Connect beispielsweise zeigt auf deren Supportseite, wie die Kommunikation mit GET und POST aufgebaut sein kann.Der Kommunikationspartner kann den Request entgegennehmen, das JWT entschlüsseln und dessen Integrität überprüfen. Ist dieser Schritt erfolgreich, kann die erwünschte Anfrage ausgeführt werden. Bei Antworten wird dasselbe Verfahren angewendet. Das JWT kommt also bei jedem einzelnen Request zum Einsatz.<h2>Sicherheitslücke</h2>Leider weist das JWT eine Sicherheitslücke auf: Der <a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a> definiert, dass eine Bibliothek eine bestimmte Anzahl von Signatur- und Verschlüsselungs-Algorithmen bedienen muss. Dazu gehört auch der “None”-Algorithmus für unsignierte JWT. Leider beschreibt der Standard nicht, wann und wie der “None”-Algorithmus NICHT genutzt werden darf. Bei der Nutzung von JWT ist es daher notwendig, zu überprüfen, dass tatsächlich eine korrekte Signatur erstellt wurde, um manipulierte JWTs zu vermeiden. Die schließt auch die Kontrolle des Headers auf einen korrekten Signatur-Algorithmus ein. Weitere Details liefert dieser Bericht.<h2>Zusammenfassung</h2>JWT ist sehr gut für den Austausch von Nachrichten in gesicherten Umgebungen zwischen zwei Anwendungen geeignet. Die angebotenen Mechanismen stellen die Authentizität und Integrität von Nachrichten sicher, sensible Daten können optional verschlüsselt werden.Theoretisch könnten JWT gänzlich ohne Sicherung genutzt werden. In der Praxis empfiehlt es sich jedoch, mindestens die Verbindung per SSL zu sichern und die Nutzdaten (“Payload”) des JWT zu signieren. Für besonders sensible Daten sollten die Daten im Payload außerdem verschlüsselt werden. Es gibt eine bekannte Sicherheitslücke, die durch eine eigene Überprüfung des genutzten Algorithmus leicht umgangen werden kann.Für die Implementierung des JWT muss man nicht mehr selbst Hand anlegen, es gibt im Netz diverse Implementierungen für die unterschiedlichsten Sprachen. Bei <a href="https://jwt.io/">JWT.io</a> findet man unter dem Menüpunkt “Libraries” einen Überblick.

JSON Web Token (JWT) im Detail

In der <a href="/wissens-hub/blog/einfuehrung-atlassian-connect">Einführung in Atlassian Connect</a> haben wir gesehen, dass Add-ons eigene Anwendungen sind, die von verschiedenen Anbietern betrieben werden und über das Internet mit der Atlassian-Anwendung kommunizieren. Besonders im Unternehmenskontext stellt sich die Frage nach der Sicherheit und Vertraulichkeit der Daten. Diese Aspekte wollen wir in diesem Artikel genauer beleuchten.Wir benutzen JIRA als Beispiel, die Überlegungen treffen aber auf alle Connect-Anwendungen (z.B. Confluence, HipChat, Bitbucket) zu.<h2>Der Überblick</h2>Wir betrachten im weiteren Verlauf vier verschiedene Bereiche, in denen der Sicherheitsaspekt eine Rolle spielt. Einen Überblick gibt das folgende Bild:<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hv50r3KSTMC4uLs5elqd"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/hv50r3KSTMC4uLs5elqd" alt="blog_atlassian_connect_security_groß" /></a> Insbesondere wollen wir im Zusammenhang mit Sicherheit die folgenden Punkte genauer beleuchten:<ol><li>die Kommunikation zwischen Atlassian-Anwendungen und Add-ons</li><li>das Berechtigungskonzept der Atlassian-Plattform</li><li>die Anforderungen an das Connect Add-on</li><li>Schutz privater Add-ons</li></ol><h2>Kommunikation zwischen den beiden Anwendungen</h2>Wie bereits beschrieben, interagieren die Anwendungen über öffentliche Netze, daher muss die Kommunikation zwischen den beiden Systemen abgesichert werden. Die Daten werden über das Internet gesendet und dürfen weder verfälscht noch von Dritten ausgelesen werden. Connect unterstützt zwei Sicherheitsmechanismen für die Kommunikation: HTTPS und <a href="/wissens-hub/blog/json-web-token-jwt-im-detail">JWT</a> .Bevor wir näher auf diese beiden Mechanismen eingehen, muss zum Verständnis noch ein anderer Punkt erwähnt werden. Ein Connect-Add-on unterliegt einem Lifecycle, für dessen Phasen Webhooks registriert werden können. Während der Installation des Add-ons findet über einen solchen Webhook der Austausch der Sicherheitsinformationen statt. Diese enthalten auch ein Geheimnis, welches im weiteren Verlauf wichtig wird.Für Add-ons, die im Marketplace gelistet werden sollen, ist die gesicherte Übertragung mittels HTTPS verpflichtend. Damit werden die Daten verschlüsselt übertragen und können nicht von Unbefugten ausgelesen werden. Die Verschlüsselung muss die gesamte Kommunikation umfassen, also auch die Übertragung des Add-on Descriptors und ganz besonders den Austausch der Sicherheits-Informationen bei der Installation.Außerdem wird zur Signierung der Nachrichten <a href="/wissens-hub/blog/json-web-token-jwt-im-detail">JWT</a> eingesetzt. Damit wird eine Authentifizierung umgesetzt, denn es kann für jede Nachricht geprüft werden, ob sie vom angegebenen Absender stammt. Für die Erstellung dieser Signatur wird das bei der Installation ausgetauschte Geheimnis genutzt.REST-Anfragen an die JIRA-API müssen immer signiert sein, ansonsten werden sie wie anonyme Nutzer behandelt, die keinen oder nur minimale Berechtigungen haben. Durch die Signatur weiß die Anwendung, von wem die Anfrage kommt und kann weitere Sicherheitsprüfungen durchführen (siehe nächster Abschnitt).Auch bei eingehenden Nachrichten im Add-on sollte die Signatur geprüft werden. Die Atlassian-Anwendung signiert jede Nachricht, die Prüfung dieser Signatur liegt aber in der Verantwortung des Add-on Entwicklers. Nur wenn er diese verifiziert, kann er sicher sein, dass die Anfrage von einem authentifizierten Partner kommt. Für die Erstellung und Prüfung der Token bietet Atlassian fertige Bibliotheken an.<h2>Berechtigungen</h2>Atlassian Connect unterstützt die Vergabe von Berechtigungen an einzelne Add-ons. Dies wird über einen eigenen Add-on Nutzer realisiert, der genau wie ein normaler Nutzer konfiguriert werden kann. Dieser Nutzer wird jedoch nicht auf die in der Lizenz freigeschalteten Nutzer aufgerechnet.Grundlegende Anforderungen wie “Lesen” und “Schreiben” von Daten können die Add-ons in ihrem Descriptor angeben, diese werden “Scopes” genannt. Um beispielsweise Daten in der Anwendung zu verändern, muss zwingend der zugehörige Scope “write” angegeben sein. Die angeforderten Scopes werden bei der Installation aufgelistet und müssen vom Administrator bestätigt werden. Auch wenn bei einer Aktualisierung neue Scopes hinzukommen, muss der Administrator erst bestätigen, dass diese gewährt werden sollen.<h2>Sicherheit des Add-ons</h2>Nachdem wir nun die Kommunikation und den Zugriff auf die Kern-Anwendung betrachtet haben, wird es Zeit sich der Sicherheit in der zweiten Anwendung zu widmen. Was nützt die sichere Kommunikation, wenn das Add-on selbst offen wie ein Scheunentor ist?Ein für Anwender kritischer Punkt ist die Speicherung von Kundendaten im Add-on. Dazu müssen Anbieter eine Erklärung zur Datensicherheit im Marketplace veröffentlichen. Atlassian gibt auch hierfür Empfehlungen und Richtlinien vor, die Umsetzungsverantwortung liegt aber beim Anbieter des Add-ons. Bei der Speicherung ist grundlegend zu beachten, dass die Daten getrennt nach Mandanten (verschiedene Cloud-Instanzen verschiedener Kunden) gespeichert werden. Die Daten selbst müssen natürlich gegen Zugriffe und Manipulationen durch Dritte geschützt werden.Dieser letzte Punkt gilt ganz allgemein für die ganze Webanwendung und das zugrundeliegende System. Aufgrund der vielfältigen Möglichkeiten, solch eine Anwendung zu implementieren und zu betreiben kann es an dieser Stelle nur ganz allgemeine Hinweise zur Absicherung geben. Es gibt einige bekannte <a href="https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013">Angriffszenarien</a> , die immer nach dem gleichen Prinzip ablaufen und für deren Vermeidung Empfehlungen vorhanden sind. Details können den <a href="https://security.berkeley.edu/secure-coding-practice-guidelines">verlinkten Seiten</a> entnommen werden.Neben dem Schutz vor direkten Angriffen auf das Add-on ist für den Anwender auch die Ausfallsicherheit bedeutsam. Wenn ein Add-on nicht verfügbar ist, kann dies die Arbeit des Kunden deutlich einschränken. Deshalb muss der durchgehende Betrieb sichergestellt werden. Da ein Add-on von mehreren Cloud-Instanzen aufgerufen wird, können auch keine individuellen Wartungsfenster vereinbart werden. Im Gegenteil, die Kunden können weltweit verstreut sein und in völlig unterschiedlichen Zeitzonen arbeiten. Auch hier liegt es wieder in der Verantwortung des Anbieters, für die ständige Verfügbarkeit zu sorgen.Weiterhin muss der Schutz vor Datenverlust bei Hardwareausfällen gewährleistet werden. Dazu müssen beispielsweise Redundanzen und Backups eingerichtet werden.<h2>Private Add-ons im Marktplatz</h2>Für Kunden, die ihre intern genutzten Add-ons selbst schreiben wollen, bietet Atlassian einen Weg, diese als “private Add-ons” im Marktplatz zu listen. Für den Fall, dass das Add-on gar nicht im Marktplatz auftauchen soll, gibt es außerdem noch einen weiteren Weg. Dreh- und Angelpunkt für alle Add-ons ist der Atlassian Marktplatz. Speziell für den Fall privater Add-ons gibt es nun zwei Optionen:Das Add-on wird als “privat” im Marketplace gelistet und ist somit nur für den Anbieter sichtbar. Für die Installation in JIRA wird ein separates Token benötigt, mit dem das Add-on sichtbar gemacht werden kann. Die Token können auf einer eigenen Seite verwaltet werden und gelten jeweils nur für eine Instanz. Zur Einbindung des Add-ons in JIRA muss der Administrator außerdem explizit private Add-ons erlauben. Danach kann die eigene Erweiterung wie gewohnt über den Marktplatz installiert werden. Diese erste Option bedeutet einen gewissen Aufwand. Sie bietet den Vorteil, dass Atlassian ein Monitoring für die Verfügbarkeit des Add-ons durchführt und warnt, wenn ein Plugin nicht erreichbar ist. Die zweite Option besteht darin, das private Add-on im Entwicklungsmodus einzubinden. Dieser erlaubt die Installation ohne eine Registrierung im Marktplatz. Allerdings ist dieser Weg von Atlassian nicht für den Livebetrieb vorgesehen. So gibt es beispielsweise kein Monitoring und auch die Absicherung des Add-ons gegen die Nutzung durch Dritte ist schwieriger, da keine gültigen Lizenzinformationen übertragen werden können.Zusammengefasst gibt zwei Pfade, mit denen private Add-ons in Applikationen eingebunden werden können. Während die Nutzung von privaten Add-ons bei geschäftskritischen Prozessen die bessere Wahl ist, bietet die Einbindung von unkritischen Add-ons über den Entwicklungsmodus einen schnellen und unkomplizierten Einstieg.Der letzte Blick gilt noch einmal der Frage, wie private Add-ons bereit gestellt werden. Auch wenn der Name „privates Add-on“ dies vielleicht nicht suggeriert, muss dennoch auch dieses Add-on über eine Internet-Schnittstelle eingebunden werden wie jedes andere öffentliche Add-on auch. Es ist daher unabdingbar, auch bei privaten Add-ons auf die richtige Absicherung zu achten. <h2>Ergebnis</h2>Wie man im Artikel sieht, gibt es sehr viele Punkte, die einen Einfluss auf die Sicherheit des Add-ons haben. Es ist aber auch zu bedenken, dass Server-Add-ons nicht pauschal als sicher eingestuft werden können. Auch diese können große Sicherheitslücken beinhalten. Und auch das Hosting einer JIRA Server Instanz durch den Anwender birgt Risiken, wenn er sich nicht damit auskennt.Die Frage, ob Connect-Add-ons sicher(er) sind, lässt sich also nicht pauschal beantworten. Atlassian unterstützt die Anbieter durch die Bereitstellung von Bibliotheken und den Zwang zu verschlüsselter Kommunikation. Es werden Empfehlungen gegebenen, und in der Dokumentation gibt es einen eigenen Punkt zum Thema Sicherheit. Der größte Teil der Verantwortung liegt aber beim Anbieter der Erweiterung. Dieser muss auf viele Dinge achten und vieles richtig machen, dann können die Add-ons durchaus als sicher gelten. Die Überprüfung für den Nutzer ist hier aber sehr schwer, er muss dem Anbieter vor allem Vertrauen entgegenbringen.

Atlassian Connect: die Sicherheit von Add-ons

<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/V1IEfd6DTziez3kyBfSv"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/V1IEfd6DTziez3kyBfSv" alt width="2224" height="1668" /></a> Hinter so manchem Problem steckt eine recht kleine Ursache</div>

Im codecentric Blog schreiben codecentricer*innen über aktuelle IT-Themen: Agile Methoden, Softwarearchitektur, KI, Testing und vieles mehr.

Großes Problem, kleine Ursache

<div><a rel="external" target="_blank" href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/V1IEfd6DTziez3kyBfSv"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/output=format:webp/V1IEfd6DTziez3kyBfSv" alt="" width="2224" height="1668"></a> Hinter so manchem Problem steckt eine recht kleine Ursache</div>

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Großes Problem, kleine Ursache

War dieser Beitrag hilfreich?

Blog-Autor*in

Großes Problem, kleine Ursache

War dieser Beitrag hilfreich?

Blog-Autor*in

Jetzt für unseren Newsletter anmelden