Womit die eigene Softwarelandschaft überblicken?

[Marscel]

Ich hab hier eine ganz interessante Situation, zum wahrscheinlich dritten Mal in meiner Karriere, wo ich mal wissen möchte, was man eigentlich am besten machen könnte, wobei dieses Mal der Scope am größten ist.

Es geht nicht um Code, der ist fein, und auch nicht um Hosting-Infrastruktur, à la welche AWS-Instanz macht eigentlich was, sondern um eine große Inhouse-Software-Landschaft. Ein paar Randbedingungen:


Basiert auf 20 Jahren Background, mit Zeug, das vor 15-20 Jahren geil war (XML all the things) bis zum neuesten Shit.
Leute, die (genauso) lange da sind, aber nur sehr in ihrer Ecke verweilt haben bis dato.
Leute, die (genauso) lange da sind, aber nicht technisch genug drin waren.
Leute, die deutlich kürzer da sind, aber hierarchisch höher, um Sachen zu verantworten, mit tw. anderem Background, und auch begrenzter Übersicht, weil genauso vor meinen Fragen stehen.
Die Gesamtzahl der Leute, die historisch dort gearbeitet haben, ist eine Größenordnung über der aktuellen Teamgröße.
Organisationstools: Kamen und gingen genauso.
Es gibt ganz viele Vorägnge, die ähnlich aber nie identisch sind.
Es gibt ganz viele externe Anbindungen, die z.T. ein ziemlicher Pain in Bezug auf SLA-Einhaltung sind, alle ähnlich aber nie identisch sind.
Über den Daumen gab es jährlich zwei große Neuerungen, wie auch alle paar Jahre Sachen wieder abgestellt wurden.
Es ist tatsächlich ganz gut dokumentiert - allerdings immer eher lokal, also was macht diese oder jene Unit, dieser oder jene Dienst, und davon gibt es viele.
Vier größere Kern-Migrationen, von denen vermutlich schon die erste hier und da halbherzig und unter Zeitdruck war.
Riesige ältere Konfigurationslandschaften, um ähnlich-aber-nicht-identisch so abzubilden ohne Code zu stark zu duplizieren.
Branche ist nicht gesondert reguliert.


Viele Fragen drehen sich im Alltag um so Sachen wie:


Was ist eigentlich die gesamte Kausalkette?
Wann über den Tag, die Woche, den Monat geht was los?
Woher kommen welche Faktoren oder Einstellungen? Datenquellen, Parameter, Hardcodings ...
Was sind Grundannahmen, die man erfüllen muss, damit man irgendwas sinnvoll mit anderem Input verwenden kann?
Wenn in X was schief läuft, wohin muss man zurückgehen, damit es beim nächsten Mal wieder klappt?
Wird dieser Code noch tatsächlich verwendet, dieser RPC-Endpunkt, diese Daten, diese Migrationsspiegelung, ...?
Was fragen wir eigentlich alles extern ab, und wofür intern?


Was ich aktuell mache - so lange bin ich da noch nicht:


Alles aufzeichnen, was primär erstmal meinem Gedächtnis und Übersicht hilft. Das ist dann aber auch ein Haufen UML-artiges Zeug, von dem ich noch gar nicht weiß, wie sachdienlich das unter dem Strich für den nächsten ist, und man eigentlich alle zusammen braucht, um ein ausreichendes Medium-Level-Verständnis zu kriegen.
Kram mittels Tools visualisieren und im Raum aufhängen, dass alle davor stehen und eruieren und auch zeichnen können.
Das hauseigene Wiki SEO-optimieren, damit Suchbegriffe und Fragen von der Suche eine größere Chance auf Gefundenwerden haben.


So, und nun die Frage, welche Methodik hilft hier noch weiter? Welche Tools nutzt ihr, was macht ihr?


Ich möchte kein menschliches Superbrain etablieren, das plötzlich lange ausfallen oder gehen wird, sodass der Zyklus zu einem ungünstigen Zeitpunkt von vorne beginnt.
Ich habe etliche Dokutools, die aber gleichermaßen um Übersichtlichkeit wie auch notwendiger Detailtiefe konkurrieren.
Unsere Ressourcender Manpower sind natürlich eher begrenzt, um das zeitlich in aller Schönheit und Eleganz zu lösen.


Naturgegeben muss man sich ständig viel zusammensuchen, um dann doch überrascht zu werden, was passiert oder nicht passiert. Aber diese Erkenntnisse müssen irgendwie sinnvoll abgelegt werden.

[Monger]

Klingt erstmal nach ganz normaler Arbeit. Was ich in deiner Auflistung vermisst habe: was sind die Schmerzpunkte? Du redest über die Mittel, aber nicht den Zweck.
Immer wenn Resourcen begrenzt sind, läuft es auf Risikomanagement hinaus. Und da wäre halt erstmal wichtig zu verstehen, was denn überhaupt brennt. Wenn dein Projekt pünktlich und im Budget fertig ist, und alle Kunden zufrieden sind, dann darf die technogische Landschaft ruhig scheiße aussehen.

[Marscel]

Brennen tut akut nichts. Es geht mir eher um allgemeine Methoden die Chancen zu reduzieren, dass man selbst oder irgendwer im Team unnötig Prozessketten bricht, Daten falsch behandelt, dass Code für gelöste Probleme untergeht.

Bei vergleichsweise kleinen Projekten, bei denen ich früh dabei war, konnte ich jedes Byte erklären, das irgendwo landet. In so einem Kontext wie jetzt ist das natürlich utopisch, aber zum einen um zu verhindern, dass Wissen und Überblick mit jedem Vorhaben und Personalwechsel weiter leichtfertig erodiert, aber zum anderen auch um Mittel zu finden, so gut wie möglich Leuten einen Eindruck zu vermitteln, die das erste Mal drauf gucken und damit produktiv werden sollen.

[Monger]

Wissensverteilung ist echt knifflig. Das hat halt ganz wesentlich mit den Gewohnheiten der Mitarbeiter zu tun. Macht keinen Sinn ne Wiki einzurichten, wenn alle Kommunikation per Mail läuft. Oder wenn aus Ressentiments heraus gar nicht kommuniziert wird.

Was wir z.B. gemacht haben: wir haben zwei Mitarbeiter im Team identifiziert, die wirkliche tiefe Silos sind. Sie werden zu allem gefragt, und wissen auch alles,ertrinken ergo in Gefälligkeiten.
Wir haben dann ein Supportpostfach eingerichtet, und erstmal alle darauf gedrillt, dass der Erstkontakt immer über diese Adresse läuft. Im Team haben wir dann gelost: jede Woche ist jemand anderes mit Support dran.
Und so ganz allmählich wird das Wissen breiter.

[Monger]

Wenn du neue Tools suchst, empfehle ich dir sehr, dir mal die Kombination aus Markdown und einer Quellverwaltung anzuschauen. Vereint mMn das beste aus beiden Welten: sehr gute Nachvollziehbarkeit, leicht zu lernen, kann leicht automatisiert werden, und lässt sich relativ einfach weitergeben.
Nachteil ist ne Schwäche bei Grafiken. Gibt zwar unzählige Markdown Erweiterungen, aber sicherzustellen dass die auf allen Clients auch gerendert werden, ist nicht einfach.

[TheRaven666]

Wissensverteilung ist echt knifflig. Das hat halt ganz wesentlich mit den Gewohnheiten der Mitarbeiter zu tun. Macht keinen Sinn ne Wiki einzurichten, wenn alle Kommunikation per Mail läuft. Oder wenn aus Ressentiments heraus gar nicht kommuniziert wird.

Was wir z.B. gemacht haben: wir haben zwei Mitarbeiter im Team identifiziert, die wirkliche tiefe Silos sind. Sie werden zu allem gefragt, und wissen auch alles,ertrinken ergo in Gefälligkeiten.
Wir haben dann ein Supportpostfach eingerichtet, und erstmal alle darauf gedrillt, dass der Erstkontakt immer über diese Adresse läuft. Im Team haben wir dann gelost: jede Woche ist jemand anderes mit Support dran.
Und so ganz allmählich wird das Wissen breiter.

Arbeiten wir in der selben Firma? Das kommt mir alles schwerst bekannt vor...

Ich bin eines dieser sog. Silos in unserem Haus. "Ertrinken ergo in Gefälligkeiten" - Besser hätte ich es nicht ausdrücken können.

Stichwort "Supportpostfach". Das haben wir vor einigen Jahren alles schon so hinter uns gebracht aber abgesehen von etwas mehr "Struktur" zum dran festhalten wurde das vom unteren Level eigentlich primär als Abschieberampe für Verantwortlichkeit genutzt. Das liegt aber zum Teil auch an der dürftigen Personalpolitik. Hauptsächlich billige Arbeitskräfte, Hiwis und Quereinsteiger im ersten Level einzustellen ist nicht zweckdienlich.

[dreas]

klingt für mich alles nach fehlenden oder intransparenten prozessen und fehlendem wissensmanagement. folgende fragen:

gibts schon wissensmanagement wie confluence oder ähnliches?
gibts schon sowas wie pocessmaker oder ähnliches?
wird wissen nur per mail gesilot oder in tasks transportiert?
sind die strukturen allen beteiligten bekannt?
ist das setup der einzelnen teams für verteiltes wissen optimal?
gibt es globale, einheitliche repositories?
wer verwaltet wie automatisierungen?

viele grüsse
dreas

[Exxtreme]

Das Problem mit den "tiefen Silos", die dann in Gefälligkeiten ertrinken bekommt man nicht wirklich weg. Dieses Problem wird nämlich nicht von den "tiefen Silos" verursacht sondern von den Mitarbeitern drumherum. Die werden sich da subtil querstellen. Denn wenn sie kein "tiefes Silo" mehr haben wo sie schnell darauf zugreifen können dann müssen sie bestimmte Dinge selbst können und auch machen. Unvorstellbar! Und ja, ich kenne das Problem weil ich auch so ein Silo bin. Es ist manchmal amüsant zu sehen wie sich schlaue Leute plötzlich total blöde anstellen nur damit man ihnen bestimmte Arbeiten nicht (mehr) gibt. "Soll Herr x das machen. Der kennt das und macht das in 3 Minuten. Ich kenne das nicht und muss mich da einarbeiten ... blablabla ... kann sein, dass ich das erst übermorgen schaffe ... blablabla ...".

Das ist aber eher ein kulturelles Problem, das man mit Technik nicht wegbekommt. Man kann sicherlich Wikis aufsetzen etc. Aber meiner Erfahrung nach werden diese weitgehend ignoriert werden. Viel wichtiger ist IMHO ein Chef, der die Leute auch zur Informationsbeschaffung zwingt und nicht dem Gejammer nachgibt und dann macht es doch wieder ein Silo.

[Monger]

Spinnen wir mal die Gegenseite: wozu sind Silos gut? Warum sind die so wertvoll, dass jede Firma sie hat?

Einzelpersonen als Silos sind wertvoll, weil man sie als Helden verkaufen kann. Schon wieder in letzter Minute den Tag gerettet, geil. Aber schau mal, selbst unser Held ist unter Wasser. Wenn der es nicht kann, kann es niemand. Es sei denn, wir bekommen viel mehr Geld.
Jeder Chef hält sich gerne so einen. Aber nur einen: zwei wären teuer und aufmüpfig.

[RaumKraehe]

"Soll Herr x das machen. Der kennt das und macht das in 3 Minuten. Ich kenne das nicht und muss mich da einarbeiten ... blablabla ... kann sein, dass ich das erst übermorgen schaffe ... blablabla ...".



Wir hatten mal ein paar Studierte die daran scheiterten einfach mal in Vertretung ein Protokoll weiterzuführen, mit der Aussage das habe ich ja noch nie gemacht. Worauf ich meinte: Du schreibst das erste mal in deinem Leben?

Ja, bin leider auch so ein "Silo". Die hier geschilderten Situationen kenne ich zur genüge. Ich sage dann immer: ich habe jetzt keine Zeit frag jemanden anderen.

[Monger]

Auch Teams sind als Silos nützlich. Du wärst gerne Projektleiter, hast aber an Personal nur die Resterampe gekriegt? Kein Problem.

1. Such dir einen Aspekt aus der notwendig ist, aber keiner machen will: Security, QA, Integration oder so.

2. Such dir einen Technologiestack aus, den garantiert niemand sonst in der Firma beherrscht. Am besten mit komplexen Lizenzbedingungen. Trainiere nur deine treusten Mitarbeiter auf eben diese Technologien.

3. Schränke den Zugang zu deiner Arbeit so gut es geht ein. Errichte eigene Subnetze, nimm eigene Server, vermeide Klartextfomate.

4. Mache deine Arbeit zur Plattform. Sorge dafür, dass deine Technologie genutzt wird, immer. Auch wenn sie nicht gebraucht wird. Sei so invasiv wie möglich. Nichts darf kompilieren, solange deine Plattform nicht installiert ist.

5. Sobald deine Plattform unverzichtbar ist, lass die Firma das spüren. Nutze Qualitätsprobleme, um jedes Jahr ein größeres Budget zu erpressen.

[Exxtreme]

Spinnen wir mal die Gegenseite: wozu sind Silos gut? Warum sind die so wertvoll, dass jede Firma sie hat?

Ich würde sagen, der Grund ist reine Bequemlichkeit. Meine Erfahrung aus einigen Firmen ist, dass die Silos nicht von sich aus gerne Silos sind sondern extern dazu gemacht werden. Seitens der Mitarbeiter, die dann ihre Arbeit ans Silo weiter delegieren weil sie es angeblich nicht können. Und auch für die Chefs sind sie bequem. Weil eigentlich müsste der Chef den Mitarbeitern Feuer unter dem Hintern machen, die für die Arbeit eigentlich zuständig sind. Aber dank Silo klappt das auch so und man spart sich unangenehme Mitarbeitergespräche.

Und deshalb wird Technik dagegen auch nicht anstinken können. Selbst wenn man ein Wiki oder so aufsetzt und alles transparent dokumentiert. Es werden sich schnell Ausreden finden warum man die eigene Arbeit ans Silo delegiert und nicht das Wiki benutzt. Entweder funktioniert es nicht oder der Rechner spinnt oder man findet nichts oder man weiss nicht wie man ein Wiki bedient etcpp. Hier braucht's halt Chefs, die auf den Tisch hauen und dafür sorgen, dass die Silos wieder arbeiten können und nicht in irgendwelchem Kleinmist untergehen.

Ironischerweise zementieren diese Wikis sogar die Silo-Situation in gewisser Weise. Weil dann können die Silos das Wiki nutzen und werden ein noch effizienteres Silo. :freak:

Und Marschels Anforderungen scheinen echt heftig zu sein. Alleine das up-to-date zu halten wird Arbeit ohne Ende machen. Bei sowas ist eine Komplexitätsreduktion IMHO erstmal viel naheliegender. Sprich, nicht: wie bekommt man den ganzen Wuschd möglichst transparent und einfach dokumentiert sondern den Wuschd erstmal massiv verkleinern damit man viel weniger dokumentieren muss.

[Marscel]

Wir haben dann ein Supportpostfach eingerichtet, und erstmal alle darauf gedrillt, dass der Erstkontakt immer über diese Adresse läuft. Im Team haben wir dann gelost: jede Woche ist jemand anderes mit Support dran.

Machen wir genauso, würde ich auch als dienlich einstufen.

Wenn du neue Tools suchst, empfehle ich dir sehr, dir mal die Kombination aus Markdown und einer Quellverwaltung anzuschauen. Vereint mMn das beste aus beiden Welten: sehr gute Nachvollziehbarkeit, leicht zu lernen, kann leicht automatisiert werden, und lässt sich relativ einfach weitergeben.
Nachteil ist ne Schwäche bei Grafiken. Gibt zwar unzählige Markdown Erweiterungen, aber sicherzustellen dass die auf allen Clients auch gerendert werden, ist nicht einfach.

Hast du ein konkretes Tool als Beispiel?

gibts schon wissensmanagement wie confluence oder ähnliches?
gibts schon sowas wie pocessmaker oder ähnliches?
wird wissen nur per mail gesilot oder in tasks transportiert?
sind die strukturen allen beteiligten bekannt?
ist das setup der einzelnen teams für verteiltes wissen optimal?
gibt es globale, einheitliche repositories?
wer verwaltet wie automatisierungen?


Wissensmanagement: Vorhanden und aktiv genutzt, ob nun Wiki/Confluence, SVG-Diagrammzeichner, shared Office-Suiten. Schwerpunkte sind dabei aber unterschiedlich, andere vergraben sich tief und händisch in Parametern, die irgendwann outdated sind, ich wiederum versuche da eher Highlevel zu arbeiten und für Details in z.B. Repositories oder einzelne Dateien zu verlinken. Daher hier z.B. was ist ein guter Weg für beide? Wie kann man den zusätzlich gut etablieren?
Processmaker: Nein, in der Form nicht
Wissentransport: Alles in Tasks und Dokumente seit langer Zeit, da grundsätzlich mit zufrieden.
Strukturen: Was meinst du damit genau?
Teamsetup: Ich behaupte mal, dass es realistisch ist und den Kerninteressen entspricht und damit zufrieden sind.
Repositories: Sind in meinen Augen mittlerweile sauber getrennt, hängen am Dependency-Mangagement, CI und und.
Automatisierungen: Die in meiner Zeit geschaffenen werden regelmäßig präsentiert, d.h. erstmal haben alle was davon gehört. Eine echte Übersicht gibt es nicht. Blöd gesagt, man könnte im ersten Schritt mal einen Softwarekalender nutzen und dort alles erstmal zeitlich vermerken, was an Uhrzeiten und Tage gebunden ist - gesonderte Events sind dann wieder was anderes. Dashboards und Monitoring sind für alles kritische geregelt.


Ironischerweise zementieren diese Wikis sogar die Silo-Situation in gewisser Weise. Weil dann können die Silos das Wiki nutzen und werden ein noch effizienteres Silo.

In gewisser Weise stimme ich da zu, dass Brain-Silo sich damit erstmal, und nicht selten mit gutem Zeiteinsatz, mit seinem eigenen mentalen Modell beschäftigt, Wiki-Silo hin und her zu managen. Da würde ich persönlich erstmal nicht reinreden, und das Kritische reviewen wir aktuell dann einfach erstmal, dass jemand anderes dann "Versteh ich (nicht)", "Wo find ich dieses und jenes?" fragen soll, sodass da nicht die Betriebsblindheit oder Tunnelblick liegen bleibt. Auch hier: Andere Ansätze sinnvoll?

[Monger]

Hast du ein konkretes Tool als Beispiel?

Konkret: wir benutzen Visual Studio, VsCode und TFS mit nem Git Repository. Die ersten beiden haben sehr gute Markdown Plugins verfügbar, die z.B. auch den Dialekt Mermaid unterstützen, mit dem man Diagramme basteln kann. Die TFS Web App kann Markdown rendern, aber eben kein Mermaid, was echt schade ist, weil die Arbeit direkt im Browser am Repository halt irre praktisch ist.

[Darkstar]

Womit die eigene Softwarelandschaft überblicken?Ich würde dafür ab einer gewissen Größe LeanIX (https://www.leanix.net/) verwenden.

[Trap]

Die TFS Web App kann Markdown rendern, aber eben kein Mermaid, was echt schade ist, weil die Arbeit direkt im Browser am Repository halt irre praktisch ist.
Seit ein paar Wochen gibt es das in der SaaS-Fassung: https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/wiki/sprint-158-update#mermaid-diagram-support-in-wiki

[lumines]

GitLab kann übrigens auch Mermaid.

[Marscel]

GitLab kann übrigens auch Mermaid.

Muss ich mir mal angucken, was damit so geht, und wenn ja, wo man das in Gitlab am besten unterbringt. Vielleicht ein Meta-Repository, und dann gleich schön versioniert.

Ich würde dafür ab einer gewissen Größe LeanIX (https://www.leanix.net/) verwenden.

Danke, da kann man echt mal nach einer Demo fragen.

Konkret: wir benutzen Visual Studio, VsCode und TFS mit nem Git Repository. Die ersten beiden haben sehr gute Markdown Plugins verfügbar, die z.B. auch den Dialekt Mermaid unterstützen, mit dem man Diagramme basteln kann. Die TFS Web App kann Markdown rendern, aber eben kein Mermaid, was echt schade ist, weil die Arbeit direkt im Browser am Repository halt irre praktisch ist.

Ah, ok. MS haben wir so gar nicht mehr im Umfeld.