Der @hikhvar schneidet hier ein weiteres sehr unangenehmes Thema an:

Wenn man mit mehreren externen Dienstleistern arbeitet, dann ist es auf viele Weisen schwieriger einen Projekterfolg zu haben.
Denn der Dienstleister arbeitet nicht für den Projekterfolg, sondern primär für den Vertrag.

Er muß das tun, um sich abzusichern, siehe @hikhvar.
Ändern sich die Anforderungen des Projekts oder sind in Teilprojektphasen Learnings aufgetaucht, die man in den folgenden Projektphasen einfließen lassen möchte, dann ist das alles schwierig.
Also, im Sinne von "eigentlich ist das eine Vertragsänderung, mindestens eine Anpassung des Statement of Work, aber eigentlich müssen wir auch das Finanzielle nachregeln."

Das Projekt wird dadurch schwieriger steuerbar, und jede Anpassung ist ein Verwaltungsakt.
Die Projektrisiken steigen mit jeder administrativen Grenze ("hier mein Amt, da Dein Dienstleister") überproportional an, denn Zeitverzögerungen, Nachrichtenverfälschung durch Stille Post und dergleichen mehr akkumulieren sich hier.
Mit einer steigenden Anzahl von Projektpartnern ("administrativen Einheiten") steigen die Kommunikationsbeziehungen, der Verhandlungsbedarf und die auszugleichenden Interessen an - quadratisch (n*(n-1)/2 -> n^2).
Einer Hauptgründe für Kostenexplosionen und Zeitverzögerungen bei solchen Projekten:
Vertragsstrukturen und Kommunikations+Verhandlungsaufwand machen es schwer, die Ziele aller Projektbeteiligten kohärent zu halten oder das Projekt schnell auf geänderte Anforderungen anzupassen.
Nun kann ich nicht für jede Art von Projekt sprechen, sondern nur für IT-Projekte, denn nur dort habe ich in den letzten 35 Jahren Erfahrungen sammeln können.

Dort ist es aber meiner Erfahrung nach /immer/ so, daß sich die Anforderungen im Laufe des Projektes ändern.
Und man dann das Projekt anpassen muß.

Selbst bei so simplen Sachen wie baercode.de, den ich ehrenamtlich beratend begleitet habe, und die technisch korrekt und im Zeit- und Kostenbudget waren, ist es so…
… daß die zusammenbrechende Kontrollpraxis zeigt, daß man einen wirksamen Test- und Covid-Paß eigentlich grundsätzlich anders gestalten muß.

In einer weiteren Iteration (die nicht geplant ist) würde man grundsätzlich anders und viel aufwendiger an das Problem herangehen müssen.
Das ist aber etwas, das zum Zeitpunkt des Requirement Engineerings nicht absehbar war, und daß nicht durchsetzbar gewesen wäre, hätte jemand zu diesem Zeitpunkt die Anforderung eingebracht.
In meinem Hauptberuf ist es so, daß mein Arbeitgeber deswegen unfertige Features so schnell als möglich in der Produktion testet.

slideshare.net/isotopp/8-roll… und folgende.

Es geht darum, die Requirements zu validieren. "Ist diese Idee wirklich geeignet, das Problem zu lösen?"
Als Webanwendung und als Anwendung, die nicht mit hoheitlichen oder medizininschen Daten arbeitet sind wir da in einer privilegierten Position, weil dann mit relativ wenig Aufwand früh experimentieren können, solange wir uns aus PII und PCI raus halten.
Weil wir das eigentliche Feature implementieren, wenn wir wissen, daß es uns reicher macht (19 von 20 Ideen scheitern in der Experiment-Phase)

und weil wir dann wissen, /wieviel/ es uns reicher macht,
können wir dann den Einsatz der Softwarenentwickler besser steuern: Sie arbeiten nur an Dingen, von denen wir wissen, daß sie Einnahmen generieren und /wieviel/ Einnahmen sie generieren, sodaß wir Engineering gegen Gewinn abwägen können.
Das geht nur im Haus - das kann man nicht outsourcen - denn nur dann ist eine informale, enge Steuerung mit Umsetzungszeiten für Steuerungsinput im Bereich von Stunden, nicht Tage oder Wochen, möglich.
Expertise im Haus ist nicht nur wichtig, um beurteilen zu können, was Dienstleister machen.

danluu.com/in-house/

Eigene Experten sind noch wichtiger, wenn man neue Dinge ausprobiert und man das Projekt eng steuern muß, weil man neuartige Dinge ausprobiert.
slideshare.net/isotopp/go-awa…

Das ist auch alles kein Hexenwerk, sondern lange bekannt.
en.wikipedia.org/wiki/Cynefin_f…
Wenn man neue, unerprobte Dinge macht, ist man im Chaotischen Quadranten des Cynefin Models und macht Forschung.

Dazu braucht man eine kleine Gruppe von Experten, die sich darauf konzentriert, Regeln und Gesetzmäßigkeiten ("überhaupt Practice") zu finden
In der deutschen Pipeline ist das ein Uni-Projekt, in dem Professor/innen irgendwelche Ideen ausprobieren, von denen die Mehrheit auf irgendeine nichtoffensichtliche Weise egal oder falsch ist, aber das herauszufinden ist genau Sinn der Sache.
"Complex" ist der Engineering-Quadrant, in der wir versuchen, als funktionierend bekannte Grundideen hoch zu skalieren und in der Masse anwendbar zu machen.
Hier braucht es mehr als ein Team, mit einem der Theoretiker aus der vorigen Phase als Beratung und vielen Praktikern ("Ingenieren") in den Teams, die immer noch so klein als möglich sein sollten.
Idealerweise hat man zwei oder drei konkurrierende Ansätze mit überlappenden Zielsetzungen, von denen dann hoffentlich einer diese Phase überlebt.

Aus dieser bekommt man dann einen Satz Handlungsanweisungen ("Wiederholbare Practice") und gute Ratschläge ("das da ist kritisch!")
Das kann man dann schrittweise Ausrollen und mit Feinkorrekturen in die Fläche bringen. Dabei kommen auch Dienstleister und deren Training ins Spiel.
en.wikipedia.org/wiki/Capabilit…

Das geht halt aber erst genau dann, wenn man Prozesse /mit Metriken/ hat, also Erfahrung hat, was man messen muß und wie - auf beiden Seiten der Vertragsgrenze.
Besteht diese Einigkeit nicht, weil der Prozeß noch nicht reif genug ist und man gar keine Metriken hat, sie nicht sinnvoll sind, der Prozeß noch zu schnell wächst um ohne grundlegende Änderungen wiederholbar zu sein oder man schlich uneinig ist...
Wenn man aus welchem Grund auch immer also solche Metriken nicht hat oder nicht haben /kann/, weil es noch nicht so weit ist,

/dann kann man nicht outsourcen/, also keinen Dienstleister verwenden.
Warum ist das so?

Weil man gar keine Grundlage hat, auf der beide Parteien beurteilen können, was verkauft und was geliefert worden ist und ob das so okay ist.
Solange das Projekt oder Prozeß-Produkt noch so weich ist, weil es noch in der Forschungs- oder Engineering-Phase ist, kann man nicht richtig sinnvoll mit externer Expertise arbeiten, weil /niemand was wie es geht/.

Da ist Expertise /im Haus/ absolut notwendig.
Der @hikhvar weist dann noch auf einen weiteren Baustein hin, der absolut zwingend notwendig ist und der über Vertragsgrenzen hinaus nur sehr, sehr schwer zu realisieren ist:

Blameless Postmortem
Wenn irgendwo ein Flugzeug ein Unglück hat,
wenn irgendwo ein Patient verstirbt,
wenn irgendwo in einer gut geführten Softwarefirma eine Outage war,

dann setzen sich alle Gruppen zusammen und versuchen herauszufinden, wie /der Prozeß/ defekt ist, der dazu geführt hat.
Die Annahme ist, daß alle Beteiligten mit den besten Absichten und im Rahmen ihrer Fähigkeiten und zum Zeitpunkt der Entscheidung verfügbaren Informationen gehandelt haben.
Wenn also die Produktion ausfällt, weil Du (aufgrund der Monitoringdaten, des Runbooks und Deiner Erfahrungen) angenommen hast, daß (A) der Fall war und deswegen (H) gemacht hast, aber in Wahrheit lag (B) vor und (H) hat alles gecrashed...
Dann ist es ein Problem, wenn die Monitoringdaten zu langsam aufbereitet worden sind, wenn nie alle wichtigen Dinge gemessen worden sind, wenn das Runbook unvollständig oder unklar ist, oder wenn wir Du unzureichend ausgebildet worden bist.
Es ist außerdem zu prüfen, ob diese Entscheidung überhaupt manuell zu treffen ist und dann eine manuelle Handlung initiiert werden muß.
Kurz: Der Blameless Postmortem konzentriert sich nicht darauf, /wer/ die Produktion gecrashed hat, sondern welche Kette von Entscheidungen dazu geführt hat, daß die gerade Dienst habende Person die Produktion crashen mußte.
So eine Diskussion über die Grenzen von Firmen, Verträgen, Statements of Work und mögliche Schadensersatzforderungen durchzuführen ist nahezu unmöglich, oder jedenfalls im Haus sehr viel einfacher.
Wieder braucht es dazu aber auch in der öffentlichen Verwaltung eine andere Kultur:

einem grundlegendem Wandel, einem Bekenntnis zu Offenheit, Transparenz, Kooperation und Open Source.

Solange sich das nicht ändert, wird sich die Tragödie vom Scheitern der Digitialisierung in der deutschen Verwaltung wieder und wieder und wieder wiederholen.
Und wenn ich jetzt klinge wie @HonkHase, dann deswegen weil er Recht hat und sich deswegen wieder und wieder und wieder mit der deutschen Verwaltung anlegt.

Gut so.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Kristian Köhntopp (but spooky)

Kristian Köhntopp (but spooky) Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @isotopp

2 Oct
So many things to unpack.

Also:

1. 99%, LOL.
2. Der CCC ist mein Sicherheitscheck.
3. Wir werden sowieso gehackt, Aufgeben ist eine Option
4. Hackerterrorcybercyberversicherungen!!11elf!eins!

Aber der Reihe nach:
1. 99%, LOL.

pluspora.com/posts/6bd0e460…

"Sicherheit ist relativ", "perfekte Sicherheit gibt es nicht".

Stimmt.

Aber es gibt... besser und schlechter konfigurierte Systeme. Und bei digital-enabling.eu und esatus.com gab es eher... weniger gute. Image
bsi.bund.de/SharedDocs/Dow…

Es gibt allgemein anerkannte Best Practices, in englischer und deutscher Sprache. Von denen wird erwartet, daß man sie umsetzt.

Das nennt die deutsche Rechtsprechung nicht ohne Grund "Grundschutz" und "Stand der Technik".
Read 21 tweets
29 Sep
“Im DIDCOM v1 Protokoll wurde bisher das Problem von MitM-Attacken nicht ausreichend berücksichtigt, was der SSI-Community scheinbar bekannt ist und wofür es auch noch keine Lösung im Standard gibt.”
Der Angriff ist auf DIDCOMM 1 selbst, und entspricht demselben Angriff, den IMSI Catcher verwenden um das Mobilfunknetz zu kompromittieren, indem sie sich als Basisstation ausgeben, ohne es zu sein.

Lilith Wittmann und Flüpke haben einen IMSI Catcher für Ausweise gebaut.
Das ganze Projekt und sein Ablauf sind noch ein Hinweia auf weitere Dinge:

Dies ist ein Projekt des Bundeskanzleramtes mit der Bundesdruckerei, externen Dienstleistern, darunter Esatus und weiteren Stakeholdern, darunter Endanwender (ohne Repräsentation im Projekt).
Read 38 tweets
28 Sep
@HonkHase Das braucht wesentlich mehr Kontext.

Intel stellt zur Zeit eine sehr kleine einstellige Anzahl Millionen Xeon CPUs her. Davon gehen 85% an weniger als 10 Kunden - Hyperscaler in den USA und China.
@HonkHase 12% oder so gehen an ca. 150 Kunden, die zwischen messbare Stückzahlen der Produktion aufkaufen und der Rest ist Kleinscheiß an Kasperkunden.
@HonkHase Das ist eine sehr ungesunde Marktstruktur, und Intel hasst diese Position wie die Pest, schon bevor Apple mit ARM los ging und AMD mit dem EPYC auf den Markt kam. Diese beiden Ereignisse haben die Situation aber noch verkompliziert.
Read 20 tweets
27 Sep
Nachdem vor einigen Tagen der Supersichere Sovereign Identity Führerschein online ging wurden ja einige Probleme im Setup, in der App, in den Operations und in der Qualität des Hostings gefunden.

Die gesamte Webpräsenz des Security-Spezialisten esatus.com ist weg.
Als Security Spezialist haben die garantiert ein Incident Management am Start, das auch Krisenkommunikation abdeckt und Notfallpläne bereit hat.

Wo kommuniziert deren Krisen-PR-Mensch denn gerade und wie handhabt esatus.com den Notfall nach eigener Aussage gerade?
Es gibt zur Zeit einen Haufen Gerüchte, aber keine belastbaren Aussagen.

"Offener Name Server, offener Metrik Server, vermutlich fliegen keys zu wildcard Zertifikaten frei rum" ist halt eine tall order für einen Security Spezialisten und würde gern irgendwo deren Aussage sehen.
Read 4 tweets
27 Sep
Mal eine Beispielaufgabe (hier Seniro DBA/SRE Kontext):

Es ist 2010 und Booking hat eine Datenbankstruktur, bei der je 5 Frontend-Zellen mit einer Datenbank reden.

Writes und Reads sind bereits getrennt: Writes gehen zum Primary, dann Replikation. Image
Reads gehen zum festen Replica der Zelle.

Leider ist das wenig effektiv: Es gibt 10 Zellen in einem RZ, aber wenn eine Zelle ihre DB überlädt kann sie nicht auf Kapazität anderer Zellen ausweichen.

Außerdem ist das RZ nicht redundant.
Wir wollen:

1. Datenbank queries load balancen.
2. Die Replikationshierarchie auf 2-3 Rechenzentren (oder AZs) aufbohren

und optional

3. gehen Ausfall von Datenbanken, oder ganzen AZs resilient sein.
Read 15 tweets
27 Sep
Ich drehe in der Firma also gerade mal wieder Interview-Runden, und da ist ein ganz seltsames Pattern drin, in den Kandidaten.

Interview 2, "Systems Design" für SRE, das Interview nach dem Coding-IV. Es geht darum, irgendein PoC auf Produktion zu bürsten.
Das ist ein guter Teil Skalierung ("Wie viel Instanzen wird das fressen, bei der Load?"), ein guter Teil Resiliency ("Finde und identifiziere alle SPoF, und was sind gängige Patterns, die zu vermeiden?") und ein Teil Monitoring/Fehlersuche/Incident Analyse.
Das scheitert oft schon an grundlegenden Fragen.

"Hier ist ein System, das im Test auf dieser Instanzgröße lief und 5000 Requests/s geschafft hat. Wir wollen 250.000 Requests/s schaffen, und die Meßdaten 6 Monate halten."
Read 33 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(