Als sie von Frachtwerk hörte, war ihr sofort klar, dass sie sich die Gelegenheit nicht entgehen lassen wollte. Doch bevor sie eine endgültige Entscheidung traf, nahm sie sich die Zeit, die Organisation sorgfältig zu prüfen. Ein zentrales Kriterium war, dass sie sich menschlich gut aufgehoben fühlt.

Sandra bat um einen Schnuppertag und nutzte die Probezeit bewusst, um ihre zukünftigen Kolleg:innen näher kennenzulernen. Sie beobachtete nicht nur die Arbeitsweise, sondern auch das zwischenmenschliche Verhalten im Team. Schließlich verbringt man mehr Zeit mit der Arbeit und den Kolleg:innen als mit Freunden oder der Familie.

Es war ihr wichtig, mit Menschen zusammenzuarbeiten, die ihre Arbeit gerne machen und nicht mit Gedanken wie „Mist, schon wieder Montag“ oder „Boah, der Kollege schon wieder“ ins Büro kommen.

Eine der größten Herausforderungen sah sie darin, Spannungen und Fehler offen ansprechen zu können. Sie wollte sicherstellen, dass dies in einem unterstützenden Umfeld akzeptiert und vielleicht sogar dankbar angenommen wird.

Nach all diesen Überlegungen und Erfahrungen stellte Sandra fest, dass Frachtwerk genau die richtige Organisation für sie ist. Und so ist sie seit über 2,5 Jahren unsere Teamfee – ein Beweis dafür, dass ihre sorgfältige Auswahl und ihr Bauchgefühl sie nicht getäuscht haben.

„Offenheit und Mut sind die Bausteine eines starken Teams – nur so können wir gemeinsam wachsen und Herausforderungen meistern.“

Fun (Facts):

• Ich bin eine waschechte Berlinerin.
• Ich liebe Pilze, zwei meiner Lieblingspilze sind:
  – der Purpurfilzige Holzritterling. Dieser riecht muffig, so nach feuchtem Hauskeller. Ich liebe diesen Geruch
  – der Schwefelporling, der aufgrund seiner Textur und seines Geschmacks auch unter dem Namen “Chicken of the Woods” bekannt ist.
• Ich habe drei Ausbildungen: Kauffrau für Bürokommunikation, Technicial Support Specialist und Finanzbuchhalterin
• Ich besitze mehr als 10 Paar Schuhe vom gleichen Modell in unterschiedlichen Farben.

FRACHTWERK

Was hast du gelernt, also welche Erfahrungen bringst du mit?

SANDRA

Ich arbeite bereits seit über 30 Jahren mit Menschen in den unterschiedlichsten Branchen zusammen, so z. B.:

• in Bars und auf Veranstaltungen
• im IT-Support (div. Hard-, Software- und Dienstleistungsanbieter)
• als Teamleitung (Disposition und Wartung von Fotoautomaten)
• im Eventmanagement
• als Assistenz der Geschäftsführung
  • im sozialen Sektor (Beschäftigung von geistig und psychisch benachteiligten Menschen)
  • in der Wohnungsverwaltung (WEG)
  • im Baugewerbe (Straßen, Brücken und Wehre)
  • in der Lebensmittelbranche (Brauerei)
  • im Bildungssektor (Arbeitnehmervertretungen)

“Da wird man alt wie ’ne Kuh und lernt trotzdem dazu.”

FRACHTWERK

Was sind deine Aufgaben und Verantwortlichkeiten als Teamfee?

SANDRA

Meine Aufgaben sind sehr vielfältig. Ich kümmere mich um Personalangelegenheiten, Recruiting und Weiterbildung. Ich bin verantwortlich für den Einkauf und wirke an internen Prozessen mit. Auch die Organisation von Events, das Office- und Accountmanagement, den Posteingang und Aktualisierungen in unserem internen Wiki gehören zu meinen Aufgabengebieten. Manchmal werde ich auch zur Gärtnerin, zur Elektrikerin, zur Inneneinrichterin, Lebensmittelkontrolleurin, Psychologin, Beraterin oder zur Handwerkerin.
Abgesehen von den genannten Themen nehme ich mich gerne allem erstmal an, wofür sich noch niemand verantwortlich fühlt und habe gern stets ein offenes Ohr für meine Kollegen:innen.

FRACHTWERK

Wie sieht ein typischer Arbeitstag für dich aus?

SANDRA

Typisch? Ich versuche es mal: Ich schaue am Tag zuvor, welche festen Termine ich am kommenden Tag habe und starte dann je nachdem zwischen 5:00 und 11:00 Uhr in meinen Arbeitstag.
Als Erstes schaue ich in unser Hauptkommunikationsmittel (Mattermost), um mich zu verbinden und in den Tag zu kommen. Dann checke ich die Postfächer und meine To-Do-Liste und schaue, ob es etwas Dringendes zu erledigen gibt und packe es ggf. auf meine Tages-To-Do-Liste oder erledige es sofort. Dann fange ich mit dem Dringendsten an.

Aaaaaaaaaaaaaaaaaber – Erstens kommt es anders und zweitens als man denkt. bzw. eine kleine Aufgabe gebiert “plötzlich” Kinder.

FRACHTWERK

Wie meinst du das, eine Aufgabe gebiert “plötzlich” Kinder?

SANDRA

Ein Beispiel: Ich möchte einen Termin für mehrere Personen im Kalender einstellen, und dazu fehlt noch ein Detail. Ich frage nach, bekomme nicht umgehend eine Antwort und muss somit die “kleine” Aufgabe auf später verschieben. Irgendwann erhalte ich Antwort, und daraus ergibt sich ein To-Do, wofür ich erst ein Telefonat führen muss, um den Termin festzumachen. Ich erreiche die Person nicht und lege mir die Aufgabe für später auf meinen Tages-To-Do-Liste. Wenn mich dann die Person zurückruft, stecke ich gerade in einer anderen Aufgabe, vielleicht sogar in einer ähnlichen Geschichte, und lasse diese liegen und widme mich der alten Aufgabe. Und wenn ich vermeintlich alle Dinge zusammen habe und den Termin verschickt habe, kommt eine Absage von einem der Teilnehmer:innen und eine Änderung oder Wunsch dazu (…) und alles beginnt von vorn – ich wollte doch nur schnell einen Termin einstellen.
Somit verbringe ich mit einer Aufgabe, die so von außen betrachtet nur 5 min dauert, gern mal in Summe 30 min.

In der Übertreibung liegt ja die Ansicht. Stell dir mal vor, ich würde mein Tageswerk aufschreiben und auf meiner Liste stünden lediglich 8 Terminvereinbarungen, könnte man dies leicht missverstehen bzw. sich die Frage stellen, was bitte hat daran 8h gedauert.

„Die kleinsten Dinge machen oft die meiste Arbeit.„

FRACHTWERK

Welche Fähigkeiten sind besonders wichtig in deiner Rolle, und warum?

SANDRA

Eine der größten Herausforderungen ist tatsächlich, die vielen Aufgaben zu jonglieren. Ich bewege den Prioritätenschieberegler ggf. mehrmals täglich. Manchmal fällt mir dadurch auch mal etwas herunter, und dann muss ich gnädig mit mir sein. Selbstfürsorge ist also gut im “Gepäck” zu haben.

Besonders wichtige Fähigkeiten sind: Neugier, Begeisterungsfähigkeit (auch sich selbst), Resilienz, Toleranz und Verständnis, Flexibilität, Problemlösungsfähigkeit, Reflektiertheit, Humor und überhaupt eine prositive Grundeinstellung sowie die Fähigkeit, sich zu organisieren.

Beim Organisieren ist das Wichtigste, “alles” am richtigen Ort zu notieren. Dazu gehört die Nachbearbeitung eines Meetings, das Festhalten von aufgeschnappten Ideen und Wünschen, eigene Gedanken zu einem Thema sowie Ergebnisse aus einer erledigten Aufgabe – und das umgehend. Denn wenn ich es nicht sofort umsetze, kommt etwas dazwischen und ich bin gedanklich schon wieder ganz woanders. Und wenn ich oder eine:r meiner Kollegen:innen dann über die vergessene Notiz stolpern, bedeutet dies ggf. ein erneutes Hineindenken, ein Nachfragen und demnach unnötige Zeit, die aufgebracht werden muss, weil ich vergessen habe, eine Ergebnisnotiz am richtigen Ort aufzuschreiben.

Und nicht zu vergessen: eine klare Kommunikation! Bei Frachtwerk kommunizieren wir intern viel über unseren Chat. Hier ist die Art und Weise, sprich das Schreiben mit Emojis und lieber ein Wort mehr als zu wenig, wichtig. Dabei tue ich mich manchmal schwer, so im “Eifer des Gefechts”. Ich arbeite dran

“Die Botschaft liegt im Auge des Betrachters.”

FRACHTWERK

Was macht dir an deinem Job am meisten Spaß, und warum?

SANDRA

In meinem Job bei Frachtwerk bereiten mir die Menschen, mit denen ich zusammenarbeite, am meisten Freude.

Dann macht es mich zufrieden, interne Abläufe so reibungslos wie möglich zu gestalten und sicherzustellen, dass meine Kolleg:innen sich auf mich verlassen können.

Weiter finde ich es großartig, dass ich mir meine Zeit und Aufgaben selbst einteilen kann. Da es so viele sind, kann ich oft mein Gemüt entscheiden lassen, was mir heute leichter fällt bzw. worauf ich richtig Bock habe.

Uuuund es gibt diese Tage, an denen sich alles zusammenfügt; tausend erledigte Kleinigkeiten bilden ein Großes und Ganzes, und dann kann ich “plötzlich” an einem Tag mehr abhaken als manchmal in einer ganzen Woche. Ich liebe diese Tage.

Kurz gesagt: Ich liebe es, wie ein Krake verschiedene Themen zusammenzubringen. Der Abwechslungsreichtum begeistert mich, und ich genieße es, als aktive Litfaßsäule zu fungieren.

„Das Leben ist bunt und aufregend, wenn die Langeweile keinen Platz hat.“

The post Achtarmige Teamfee – ein Interview mit Sandra von Frachtwerk appeared first on Frachtwerk.

(Fun-)Facts über Pia:

• Pia hat in México studiert und lebt seitdem jedes Jahr im Winter in Spanien, um von der Sprache und dem Meer umgeben zu sein.
• Sie ist ausgebildeter Coach.
• Sie hat zudem FaceID gemastert und kann das Handy ihrer kleinen Schwester mit der Gesichtserkennung entsperren.

FRACHTWERK:

Wie bringst du deine Selbstständigkeit und Frachtwerk unter einen Hut?

PIA:

Die Frage hat direkt mit mir resoniert, denn es ist zweifelsfrei ein echter Balanceakt. Von Anfang an habe ich mir feste Tage für meine Selbstständigkeit und meine Rolle bei Frachtwerk gesetzt – und das funktioniert auch ganz gut. Dass wir unsere Arbeitszeit bei Frachtwerk selbst gestalten können, kommt mir an Tagen zu Gute, wo sich spontan Termine o. Ä. ergeben.

Die eigentliche Herausforderung ist aber weniger die zeitliche Planung, sondern die emotionale Komponente. Oft habe ich die Angst, dass ich einem der beiden Standbeine nicht gerecht werde. Ich liebe schnelle Ergebnisse und fokussierte Arbeit, was manchmal schwierig ist, wenn man am nächsten Tag einen kompletten Themenwechsel hat. Da das aber mein Herzensweg ist, würde ich mich aktuell immer wieder so entscheiden.

FRACHTWERK:

Wie würdest du Agile Organisationsentwicklung einem Laien erklären?

PIA:

Stell dir das Rudel bei „König der Löwen“ vor, jedoch gibt Mufasa seine Rolle als Rudelführer ab. Stattdessen werden Aufgaben und Verantwortung verteilt, untereinander kommuniziert und spontan auf neue Situationen regiert.

Rollenverteilung

Jeder Löwe hat eine spezifische Rolle, wie z. B. die Wachsamkeit in der Nähe des Wassers, die Jagdstrategien oder die Aufzucht der Jungen. Diese Rollen können je nach Situation angepasst werden, wenn sich die Bedürfnisse des Rudels ändern.

Zusammenarbeit

Die Löwen arbeiten eng zusammen und unterstützen sich gegenseitig. Wenn ein Löwe eine Herausforderung hat, kommen die anderen zusammen, um Lösungen zu finden.

Flexibilität

Wenn eine Gefahr droht, wie ein Angriff eines anderen Rudels, kann jeder Löwe schnell seine Rolle ändern, um das Rudel zu schützen. Diese Flexibilität ermöglicht es dem Rudel, sich schnell an neue Situationen anzupassen.

Feedback und Lernen

Nach einer Jagd oder einer Begegnung mit einem Feind sprechen die Löwen darüber, was gut gelaufen ist und was verbessert werden kann. Sie lernen gemeinsam und passen ihre Strategien an.

Selbstorganisation

Das Rudel organisiert sich selbst und trifft Entscheidungen gemeinsam, ohne dass immer ein einzelner Anführer die Richtung vorgibt. Jeder Löwe hat die Möglichkeit, seine Meinung einzubringen.

Durch diese Aufteilung von Rollen und Verantwortung wird das Löwenrudel agiler und kann besser auf Veränderungen reagieren. Agile Organisationsentwicklung bedeutet also, dass Teams flexibel, kooperativ und selbstorganisiert arbeiten, um gemeinsam Ziele zu erreichen und sich kontinuierlich zu verbessern.

FRACHTWERK:

Welche Tipps hättest du gerne gehabt, bevor du angefangen hast, agile Methoden oder Prozesse in der Organisation zu implementieren?

PIA:

Da kommen mir direkt zwei Dinge in den Kopf:

1. psychologische Sicherheit priorisieren,
2. transparenten und häufigen Informationsfluss gewährleisten

Psychologische Sicherheit priorisieren:

Agile Methoden ändern Prozesse, Rollen oder Verantwortlichkeiten von Mitarbeitenden. Von Natur aus machen Neuerungen Menschen jedoch eher Angst oder führen zu Ablehnung. Es ist also wichtig, Vertrauen in die Neuerung zu fördern – hier kann das Konzept der „Psychologischen Sicherheit“ helfen.

Psychologische Sicherheit bezeichnet ein Umfeld, in dem Teammitglieder ihre Gedanken, Ideen und Bedenken offen äußern können, ohne Angst vor negativen Konsequenzen zu haben. Typisch für Mitarbeiter:innen mit psychologischer Sicherheit sind z. B. folgende Gedanken:

• „die anderen haben das Beste für mich im Sinn“
• „ich bin sicher“
• „ich darf meine Kritik äußern und werde trotzdem jederzeit wertgeschätzt“
• „ich kann zu 100 % ich selber sein“

Wenn agile Methoden oder ganz grundsätzlich die Umstrukturierung gewisser Prozesse in einer angstgeprägten Organisationskultur implementiert werden wollen, fehlt schlichtweg die Basis – nämlich das Vertrauen, dass die Neuerung langfristig zur Verbesserung des Individuums führt. Diese Skepsis hemmt jegliche erfolgreiche Implementierung agiler Methoden.

Transparenten und häufigen Informationsfluss gewährleisten:

Das Ziel dieses Tipps ist, das betroffene Team zu jedem Zeitpunkt der Planung und Umsetzung „im Loop“ zu halten. Je eher wir Menschen über Veränderungsinitiativen informieren, desto eher erzielt man einen sogenannten „Buy-In“, also die Unterstützung des Teams.

Damit eine Veränderungsinitiative auf Resonanz stößt, muss sie 3 Fragen überzeugend beantworten:

1. Warum diese Veränderung?
2. Warum jetzt?
3. Warum dieses Vorgehen?

Nur wenn Menschen informiert sind, haben sie die Möglichkeit, mit der Idee zu wachsen, kritische Fragen zu stellen, sich auszuprobieren und Feedback zu geben (eine der wichtigsten Säulen in der agilen Organisationsentwicklung).

FRACHTWERK:

Vielen Dank, Pia, dass wir dir zuhören durften und du uns Einblick in die Agile Organisationsentwicklung gewährt hast.

The post Zwischen Selbstständigkeit und agiler Organisationsentwicklung – ein Interview mit Pia von Frachtwerk appeared first on Frachtwerk.

FRACHTWERK:

Hallo Julian, schön, dass wir dich ab sofort öfter sehen werden. Du warst bisher Werkstudent und steigst jetzt fest mit ein – warum hast du dich dazu entschieden, auch weiterhin bei Frachtwerk zu bleiben?

JULIAN:

Einen großen Einfluss auf meine Entscheidung haben die Menschen und die Unternehmenskultur bei Frachtwerk gehabt. Ich arbeite unglaublich gerne mit meinen Kolleg:innen zusammen. Es herrscht ein echtes Gefühl von Zusammenarbeit auf Augenhöhe und meine Arbeit wird wirklich wertgeschätzt. Das ist leider keine Selbstverständlichkeit, wie ich aus anderen Erfahrungen weiß. Dieses Gefühl, dass meine Beiträge zählen und gesehen werden, macht für mich einen großen Unterschied in der Motivation.

Was ich ebenfalls sehr schätze, ist die Flexibilität, die mir bei Frachtwerk gegeben wird. Ich kann selbst entscheiden, wann und wo ich arbeite und wie ich meine Aufgaben angehe. Das erlaubt mir, auf die Weise zu arbeiten, die für mich am besten funktioniert – und nicht, wie es jemand anders für mich vorschreibt.

Und nicht zuletzt möchte ich mit meiner Arbeit etwas bewirken. Bei Frachtwerk habe ich die Möglichkeit, an Projekten zu arbeiten, die einen positiven Einfluss haben. Das gibt meinem Job noch eine zusätzliche Bedeutung, die mir sehr wichtig ist.

FRACHTWERK:

Auf was freust du dich am meisten?

JULIAN:

Ich werde in ein spannendes Projekt einsteigen, bei dem wir zusammen mit der Stadt Bonn eine Smart-City-Plattform betreiben. Dabei arbeite ich mit neuen Kolleg:innen zusammen und setze moderne Technologien ein. Das ist für mich die perfekte Gelegenheit, das Wissen aus meinem Studium in einem großen, realen Projekt anzuwenden.

Außerdem werde ich unser Team bei der internen Systemadministration unterstützen. Da gibt es immer spannende Herausforderungen, und ich freue mich darauf, da meinen Teil beizutragen.

Besonders freue ich mich aber darauf, endlich mehr Zeit für Dinge zu haben, die während meiner Zeit als Werkstudent oft zu kurz gekommen sind. Ich möchte mich stärker in interne Aufgaben einbringen, Verantwortung übernehmen und an Aufgaben arbeiten, die die Organisation voranbringen.

FRACHTWERK:

Wie schafft ihr es, als DevOps-Team bei Frachtwerk über 200 Anwendungen zu betreiben und gleichzeitig ein so hohes Servicelevel zu bieten?

JULIAN:

Der Schlüssel liegt in einem guten Mix aus Struktur, Technik und Teamarbeit. Wir setzen auf einen einheitlichen Tech-Stack, der uns Effizienz und Übersichtlichkeit bringt. Jede Software, die wir betreiben, läuft in Docker und wird über Portainer eingerichtet. Das hilft uns enorm, denn je standardisierter die Umgebung, desto schneller können wir Probleme lösen und neue Anwendungen integrieren.

Ein weiteres wichtiges Element ist unser Monitoring. Wir haben Systeme, die uns sofort benachrichtigen, wenn ein Server Probleme macht oder eine Applikation nicht mehr korrekt läuft. So können wir im besten Fall schon eingreifen, bevor es unsere Kund:innen oder Mitarbeiter:innen überhaupt bemerken.

Und natülich das Team. In unserem kleinen Team treffen wir uns jede Woche, um gemeinsam Probleme zu besprechen und die Infrastruktur kontinuierlich zu verbessern. Diese enge Zusammenarbeit sorgt dafür, dass wir nicht nur reagieren, sondern auch proaktiv dafür sorgen, dass alles reibungslos läuft.

FRACHTWERK:

Wie funktioniert so ein Monitoring eigentlich vereinfacht gesagt?

JULIAN:

Monitoring lässt sich gut mit einer Smartwatch vergleichen. So wie die Uhr deinen Puls, die Herzfrequenzvariabilität und andere Werte misst, überwacht ein Monitoring-System kontinuierlich verschiedene Komponenten einer Software.

Bei der Software werden Metriken wie Serverauslastung, Speicherverbrauch oder die Reaktionszeit einer Anwendung gesammelt. Diese Werte werden von einem System ausgewertet, das dann automatisch Benachrichtigungen an uns sendet, wenn etwas nicht stimmt – zum Beispiel, wenn ein Server überlastet ist oder eine Anwendung nicht mehr richtig läuft. Es ist quasi wie ein Gesundheitscheck für Software, nur dass wir hier nicht direkt zum Arzt müssen, sondern das Problem oft schon beheben können, bevor es wirklich kritisch wird.

FRACHTWERK:

Ist dabei schonmal was so richtig schief gegangen?

JULIAN:

Natürlich, Fehler passieren – auch bei uns. Aber keine Sorge, wir haben noch nie das halbe Internet lahmgelegt wie Facebook oder weltweit Windows-Rechner abstürzen lassen wie andere große Namen. Dennoch gibt es bei uns regelmäßig kleinere Pannen, die uns herausfordern.

Die Kunst dabei? Idealerweise zu Zeiten arbeiten, in denen sonst niemand arbeitet, sodass niemand etwas mitbekommt Aber Spaß beiseite: Unsere offene Fehlerkultur ist entscheidend. Wenn etwas schiefläuft, suchen wir gemeinsam nach schnellen, aber auch nachhaltigen Lösungen, um zu verhindern, dass so etwas in Zukunft nochmal passiert.

Eigentlich gibt es jeden Tag etwas, das schief geht. Drei Beispiele sind mir aber besonders hängen geblieben:

• Das gelöschte GitLab-Projekt: Beim Testen eines neuen Tools habe ich aus Versehen ein ganzes GitLab-Projekt gelöscht. Zum Glück hatten wir ein Backup und konnten es innerhalb kurzer Zeit wiederherstellen.
• Das Wiki-Fiasko: Wir wollten unser Wiki umstrukturieren und haben dafür ein Tool geschrieben, was das vereinfachen sollte. Leider hat es das komplette Wiki zerschossen. Ich war mir sicher, gründlich getestet zu haben – Unit Tests waren top, aber End-to-End-Tests hatte ich wohl unterschätzt. Nach einer sehr langen Nachtschicht war das Wiki wieder nutzbar, sogar in der neuen Struktur.
• Das fehlgeschlagene Mattermost Update: Bei einem Update ist unser Chat-System, Mattermost, ausgefallen. Der unerwartete Vorteil daran? Wenn der Chat nicht funktioniert, kann sich auch niemand über den Chat beschweren! So hatten wir zumindest Ruhe, um das Problem zu lösen.

FRACHTWERK:

Vielen Dank, Julian, dass du dir die Zeit für uns genommen und uns einen Einblick in deinen Arbeitsalltag gewährt hast!

The post Vom Werkstudenten zum Festangestellten – ein Interview mit Julian von Frachtwerk appeared first on Frachtwerk.

Eine Entscheidung zu treffen, ist kompliziert

Sich für oder gegen verschiedene Architekturstile zu entscheiden, ist kompliziert. Wenn etwa in einem Projekt mit sehr dynamischen Anforderungen Änderungen an diesem – aus welchen Gründen auch immer – längere Zeit oder komplett ignoriert werden, dann ist es ziemlich wahrscheinlich, dass die entwickelte Softwarearchitektur nicht zu den aktuellen Anforderungen passt. Ähnlich dynamisch können auch die Anzahl und Skillsets der verfügbaren Entwickler im Projekt sein. Wenn mitten im Projekt einige Senior-Devs das Projekt verlassen, dann kann das zu großen Schwierigkeiten führen.

Derweil sind dynamische Anforderungen und Fluktationen innerhalb des Dev-Teams nur zwei von vielen Möglichkeiten, weshalb man als Softwarearchitekt die getroffene Architekturstilentscheidung regelmäßig hinterfragen sollte. Auch argumentieren Mark Richards, Neal Ford und Jørgen W. Lang in ihrem Buch „Handbuch moderner Softwarearchitektur: Architekturstile, Patterns und Best Practices“ in der aktuellen Ausgabe von 2020, dass das „Warum“ wichtiger sei als das „Wie“. Die Begründung für eine Architekturentscheidung ist also wichtiger also die Entscheidung an sich. Natürlich fallen Entscheidungen am Anfang eines Projekts anders aus als gegen Ende, weil man zu Beginn eines Projekts viel weniger weiß als zum Projektende. Man sollte aber trotzdem zu jedem Zeitpunkt einen sinnvollen Plan haben, in welche Richtung man die Softwarearchitektur entwickeln möchte.

Anlehnend an den NoSQL Decision Tree haben wir deshalb eine Entscheidungshilfe gesucht, mit deren Hilfe wir einen Architekturstil schnell und fundiert auswählen können, ohne dabei wichtige Punkte zu vergessen. Dazu haben wir uns überlegt, wie wir ein möglichst vollständiges Bild von verschiedenen Klassen an Anforderungen bekommen und abbilden können, um zu jedem Zeitpunkt im Projekt gut dokumentiert und begründet eine Architekturstilentscheidung treffen und danach die Entscheidung sinnvoll begründen zu können.

Unser Ergebnis ist der Architekturentscheidungstrichter.

Warum ein weiteres Vorgehensmodell für Architekturstile?

In der Literatur zu Softwarearchitektur gibt es bereits unzählige und beliebig komplexe Vorgehensmodelle. Doch genau hier liegt das Problem: Der nötige Zeitinvest, um ein ausreichendes Verständnis für diese Methodiken zu erreichen, ist hoch.

Die zwei wohl bekanntesten Schulen für Softwarearchitektur sind das TOGAF-Framework und ISAQB. Sie sind jeweils nicht nur eine eigene Methodik, sondern eine Sammlung aus einer Vielzahl von Vorgehensweisen. Wer ein Zertifikat in einer dieser beiden Schulen erworben hat, kennt den hohen Zeitaufwand, der hierfür nötig ist.

Aus unserer Sicht ist der Zeitaufwand gerechtfertigt, wenn man eine Karriere als Softwarearchitekt anstrebt und sich dafür fundiertes und breites Know-How aneignen möchte. Wir empfehlen für Softwarepraktiker insbesondere die ISAQB Zertifizierung. Denen von euch allerdings, die akut in einem Projekt eine Hilfestellung brauchen, um eine Architekturentscheidung zu treffen, bleibt meist keine Zeit für eine umfangreiche Schulung.

Wir als Autoren dieses Artikels waren in den letzten Monaten in genau dieser Situation und suchten nach einer Hilfestellung, die mit begrenztem Zeitinvest verständlich und gleichzeitig ausreichend vollständig ist. Leider vergeblich. So haben wir uns selbstständig einen Werkzeugkasten gebaut, der uns ohne aufwändige Zertifizierung bei Architektur-Themen tatkräftig geholfen hat. Und genau den möchten wir mit euch teilen.

Update: Wir haben in diesem Zuge an dem Thema Softwarearchitektur Freude gefunden. Manche von uns haben später selbst u. a. die ISAQB Zertifizierung durchgeführt. Vielleicht fühlt ihr euch dazu auch ermutigt, wenn ihr dazu weiterlest!

Wie funktioniert der Architekturentscheidungstrichter?

Zur Erstellung des Vorgehensmodells haben wir aus unseren Erfahrungen die wesentlichen Fragestellungen geclustert, die für eine Architekturentscheidung betrachtet werden sollten. Wesentlich dafür war u. a. die DIN ISO/IEC 25010 über nicht-funktionale Anforderungen, denn diese Qualitätskriterien sind für den Erfolg einer guten Softwarearchitektur sehr wichtig.

Unser Modell umfasst vier Cluster an Anforderungen, die vom Abstrakten bis ins Detail alles Wesentliche betrachten:

1. regulatorische,
2. organisatorische,
3. produktbezogene und
4. technische Anforderungen.

Jeder Cluster besteht aus einer Reihe an Fragen, die der Reihe nach beantwortet werden. Diese Antworten sind der Input für den Entscheidungstrichter:

Anhand der Antwort werden im Trichter alle möglichen Architekturstile dahingehend bewertet, ob sie für das vorliegende Projekt mehr oder weniger geeignet sind. Im Ergebnis fällt unten am Ausgang des Trichters dann der eine Architekturstil heraus, der am besten passt. Das kann auch eine Mischung aus zwei Stilen sein, wie wir später noch sehen werden.

In der Praxis sehen wir, dass sich Anforderungen im Projektverlauf noch ändern. Wir haben das Modell deswegen als zyklisches Modell entworfen: Es erlaubt also Iterationen. Teilschritte, die sich nicht geändert haben, können dabei einfach auf dem alten Stand belassen werden, ohne dass man Informationen vergisst.

Ein weiterer Vorteil: Die Beantwortung der Fragen der vier Cluster unterstützt die Dokumentation und Begründung von Entscheidungen. So lässt sich später im Projektverlauf jederzeit nachvollziehen, warum (!) eine bestimmte Entscheidung getroffen wurde. Die sich daraus ergebenden Vorteile kann man nur unterschätzen:

• So erhält man nach der Analyse der regulatorischen Anforderungen bereits eine fundierte Erkenntnis darüber, ob ein Projekt rein gesetzlich umsetzbar ist oder ob es bspw. gegen den Datenschutz verstoßen würde und so das Produkt von vornherein nicht gebaut werden darf.
• Ein Nebenprodukt des Durcharbeitens der organisatorischen Anforderungen ist die Stakeholderanalyse, welche im gesamten Projekt sehr nützlich ist. Darüber hinaus erhält man hier bereits eine grobe Preisindikation auf Basis der Anforderungen, welche im weiteren Verlauf auch wichtig sein wird.
• Anhand der produktbezogenen Anforderungen erhält man darüber hinaus eine Endnutzeranalyse und eine grobe Skizze darüber, welche Kontexte und Use Cases bedient werden müssen. Das zu lösende Problem wird schon mal auf Basis der Anforderungen fachlich zerlegt und Anforderungen an die Qualität werden geschärft.
• Zuletzt bekommt man durch die Bearbeitung der technischen Anforderungen bereits eine High-Level-Sicht auf die Architektur: Einzelne Komponenten und deren Schnittstellen gliedern sich heraus, man bekommt Klarheit über die Programmiersprachen, Testing-Konzepte, das Deployment, etc.

Im folgenden Abschnitt gehen wir nun auf die einzelnen Cluster an Anforderungen im Detail ein.

Die vier Cluster des IT-Architekturentscheidungstrichters

Regulatorische Anforderungen/externe Rahmenbedingungen

Ohne regulatorische Anforderungen zu beachten, ist es sinnlos, Software zu bauen. Falls diese sich ändern oder die geplante Software direkt vor ihrer Entwicklung verboten ist, sollte sie nicht implementiert werden.

Regulatorische Anforderungen umfassen für das jeweilige Projekt relevante externe Rahmenbedingungen wie bspw. die Gesetzgebung im Rahmen von etwa Finanz-, Arbeits- und Datenschutzrecht.

Organisatorische Anforderungen/interne Rahmenbedingungen

Organisatorische Anforderungen betreffen stattdessen die internen Rahmenbedingungen. Diese haben wir folgendermaßen eingeteilt:

• Zeitliches Budget und Kosten. Wie viel Zeit und Geld habe ich zur Verfügung?
• Verträge und Partnerschaften. Sind zum Beispiel durch Partner gewisse Standards vorgegeben? Welche SLAs müssen beachtet werden?
• Prozesse. Gibt es beispielsweise Vorgaben oder Best Practices im Unternehmen wie Scrum?
• Personalressourcen und Arbeitskultur. Welches Skillset haben meine Entwickler, welche Stakeholder gibt es etc.?

Abhängig vom Kunden schlagen wir vor, die organisatorischen Anforderungen in angepasster Reihenfolge abzuarbeiten. Es gibt Projekte, in denen höherer Kostendruck bei Entwicklern mit sehr hohen Skills herscht, aber auch Projekte, in denen die Situation genau umgekehrt ist. Je nach Ausgangslage gilt es, die unterschiedlichen Anforderungen unterschiedlich zu priorisieren.

Produktbezogene Anforderungen

Wir unterteilen produktbezogene Anforderungen in zwei Unterpunkte: funktionale und nicht-funktionale Anforderungen. Wie aus der Literatur bekannt, umfassen dabei funktionale Anforderungen die Anforderungen, welche beschreiben, was die Software am Ende des Tages leisten soll.

Nicht-Funktionale Anforderungen umfassen hingegen generelle Faktoren, die im Entwicklungsprozess beachtet werden müssen. Aufgrund der großen Menge an nicht-funktionalen Anforderungen haben wir diese nochmal in drei Unterpunkte unterteilt: Sicherheit, Flexibilität und Einfachheit, welche Anforderungen wie bspw. Verfügbarkeit, Skalierbarkeit und Benutzbarkeit enthalten.

Technische Anforderungen

Technische Anforderungen sind unterteilt in:

• Technisch externe Umgebung: Beispielsweise muss hier geklärt werden, an welche Bestandssysteme die neue IT anschlussfähig sein muss und mit welcher Technologie?
• Deployment und Release: Wie ist zum Beispiel der automatisierte Deployment-Prozess gestaltet?
• Betrieb: Auf welcher Hardware soll die Software laufen und wer ist für deren Betrieb verantwortlich?
• Qualitätssicherung: Das umfasst zum Beispiel Punkte wie welcher Automatisierungsgrad und welche Testabdeckung angestrebt werden.

Nachfolgend werden diese Fragestellungen weiter detailliert:

Schwächen des Architekturentscheidungstrichters

Der vorgeschlagene Architekturentscheidungstrichter ist nur für grundlegende Architekturstilentscheidungen gedacht. Für Detailentscheidungen sollten zum Beispiel Architectural Decision Records (https://adr.github.io/) genutzt werden. Außerdem sind die genutzten Anforderungen mit Sicherheit nicht vollständig oder könnten anders klassifiziert und genutzt werden. Darüber hinaus haben wir das Modell noch nicht für ein neues Projekt „from scratch” genutzt, sondern nur anhand von zwei aktiven Projekten ge-backtestet.

Ausblick

Der Architekturentscheidungstrichter bietet eine Möglichkeit, um geordnet und zügig zu einer Architekturentscheidung zu kommen. Durch seine iterative Bauweise kann man ihn im Projektverlauf jederzeit erneut durchlaufen, die einzelnen Anforderungen abarbeiten und die getroffene Architekturstilentscheidung kritisch hinterfragen. Um seinen Nutzen noch besser zu validieren, sollte er für ein neues Projekt von Beginn an in regelmäßigen Abständen verwendet werden. Die saubere Dokumentation während der Nutzung vorausgesetzt, können somit Projektzwischenstände dokumentiert und die Architekturstilentscheidung jederzeit stichhaltig begründet werden. Und genau das ist im Bereich Softwarearchitektur essenziell. Denn es zählt nicht das „Was“, sondern das „Warum“.

The post Der Architekturentscheidungstrichter: Hilfestellungen für Software-Architekturentscheidungen. appeared first on Frachtwerk.