Das lange Wochenende habe ich genutzt, um Radarcharts im ISMS-Dokumenten-Workflow zu integrieren.1 Auditoren schätzen diese Darstellungsform sehr, da sich der organisatorische Reifegrad auf einen Blick erfassen lässt. Letzten Monat habe ich hier im Blog gezeigt, wie sich Piecharts in Markdown erzeugen lassen.2 Mit Radarcharts funktioniert das genauso einfach. Einfach im Markdown die nachfolgende Zeile schreiben: {{snippet: radarchart name="id1" labels="Unit1, Unit2, Unit3" values="3,3,3" max=5 }} Das Ergebnis in einer PDF sieht dann so aus: Read more

… wer sein Hauptprodukt als solches in den Terms of Use spezifiziert:1 Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don’t rely on Copilot for important advice. Use Copilot at your own risk. Das Medienecho der vergangenen Tage fiel entsprechend deutlich aus. Ich wurde bereits gefragt, warum ausgerechnet ich, mit meiner speziellen Geschichte mit Microsoft,2 noch nichts dazu geschrieben habe. Zugegeben: Es fällt mir schwer, bei etwa aus Redmond nicht polemisch zu werden. Zudem ist es für mich keine wirkliche Neuigkeit. Microsoft attestiere ich noch nicht einmal mehr die Qualität eines Spielzeugs. Mein Quote vom letzten Jahr nach der Installation von Steam auf Linux und den sofortigen Leistungsgewinn auf gleicher Hardware bringt es auf den Punkt:3 Read more

Die vergangenen Wochen habe ich die Gelegenheit gehabt, mich eingehend mit der NIS2 auseinanderzusetzen und ganz praktisch Checks und einen Fragenkatalog zu erarbeiten. Wer NIS2 sagt,1 meint normalerweise die Richtlinie (EU) 2022/2555 vom 14. Dezember 2022 für ein hohes gemeinsames Cybersicherheitsniveau in der Union.2 In Abgrenzung zu EU-Verordnungen, entfalten Richtlinien ihre volle Wirkung erst durch Umsetzung in nationales Recht. Die NIS2 ist eine sogenannte Mindestharmonisierungsrichtlinie.3 Mitgliedstaaten dürfen abweichend strengere Regeln erlassen, müssen aber die formulierten Mindeststandards erfüllen. Read more

Epyy, das ist der Name des neuen Icons und Maskottchens meines freien ISMS-Dokument-Workflows auf Codeberg.1 Sein Name ist abgeleitet vom griechischen ἐπισκοπεῖν (episkopeîn), was übersetzt inspizieren oder überwachen heißt. Ein freundliches und vor allem “lebendes” Dokument, das einen durch den ISO27001- und TISAX-Wust begleitet. Der ISMS-Workflow ist frei und Open Source. Für professionellen Support oder individuelle Anpassungen einfach eine Anfrage an mich stellen. PRs are welcome! Read more

In den letzten Tagen bin ich wieder einmal im sprichwörtlichen Kaninchenbau versackt. Aber ganz von vorne: Am Samstag habe ich einen Blogbeitrag geschrieben, um einen automatisierten und deterministischen Dokumenten-Workflow zu veranschaulichen.1 Zur besseren Nachvollziehbarkeit habe ich außerdem ein Codeberg-Repository angelegt.2 Das Feedback war überraschend überwältigend und enthielt viele berechtigte Punkte. Tatsächlich war das Repo ursprünglich eher schnell als gründlich zusammengestellt, so dass ich es deutlich überarbeitet und im Zuge dessen auch umbenannt habe. Jetzt ist es mehr als nur ein Anschauungsobjekt. Es bildet nun einen vollständigen, sehr flexiblen und zugleich sehr einfachen Dokumenten-Workflow ab. Read more

Zum Wochenende habe ich auf Codeberg ein Beispiel-Repository veröffentlicht.1 Es enthält den methodischen Vorschlag, eine ISMS-Dokumentation wie Code zu behandeln. Konkretes Beispiel ist die ISO 27001 Risikobewertung von Assets in Organisationen. Im Mittelpunkt steht dabei weniger das konkrete Dokument als vielmehr das dahinterstehende Konzept. Geschrieben ist alles in einem universellen Text-Only-Format, das garantiert auch noch in 50 Jahren in jedem Editor bearbeitet werden kann: Markdown.2 Markdown hat dabei einige praktische Eigenschaften: Read more

“Ship fast, fail fast” oder manchmal auch “fail cheap” ist ein Credo aus dem agilen Umfeld.1 Es adressiert ein echtes Problem mit starren Prozessen, Hierarchien oder Technologie-Stacks. Die heutige Industrie verspricht seit Jahren mit agiler Arbeitsweise ein höheres Tempo, was sich richtig anfühlt. Doch wenn ich gefragt werde, ob ich agil arbeiten würde, antworte ich lieber ausweichend. Viele verwechseln Tempo mit Reife und vergessen dabei, dass eine falsch eingeschlagene Richtung sich nicht mit Geschwindigkeit korrigieren lässt. Geschwindigkeit als Kompensationsmechanismus für fehlende Klarheit. Read more

In Ergänzung zu meinem Blog “Woran sich IT-Erfolg wirklich messen lässt” schreibe ich heute über ein verwandtes Thema.1 Es handelt von den Versprechungen von Cloud- und Service-Anbietern und wie diese mit Verfügbarkeiten jenseits von 99% locken. Anexia/Netcup, der Infrastruktur-Anbieter bei dem ich u.a. meinen Mailserver, VPN-Gateway und ein paar andere Hosts betreibe, spricht auf seiner Homepage von 99,6% Verfügbarkeit.2 Das bedeutet einen rechnerischen Ausfall von bis zu 40 Minuten in der Woche oder bis zu 35 Stunden im Jahr. Read more

Destruktive Kommunikation ist selten laut. Sie klingt höflich, sachlich, mitunter sogar freundlich. Und trotzdem bleibt bei mancher Mail ein “Geschmäckle” zurück. Das unbestimmte Gefühl: Liege ich wirklich so falsch neben der Sache? Der heutige Blogbeitrag ist ein Erfahrungsbericht aus über zwei Jahrzehnten IT Operations und Projektarbeit samt der typischen Signalwörter und Phrasen, die vermutlich schon jeder in Mails oder Chats gelesen hat. Alles nicht ohne den von mir gewohnten Disclaimer: Kein Anspruch auf Vollständigkeit oder Richtigkeit. Wahrnehmung ist immer subjektiv. Der Kontext ist immer entscheidend. Eine einzelne Formulierung kann noch komplett harmlos sein. Manifestiert sich ein bestimmter Kommunikationsstil über Wochen oder Monate, so ist das schon ein deutlich stärkeres Indiz. Your mileage may vary. Read more

Alltag in einem mittelständischem Unternehmen. Im Vorbeigehen bekommt der ohnehin schon hart im Crunch1 arbeitende Entwickler den Hinweis: “Machst Du bitte für dieses Projekt in der Übersicht aller Kunden auch noch die offenen Rechnungen sichtbar?” Er kann nur pflichtbewusst nicken, weiß er doch, dass es sich um ein wichtiges Projekt handelt, die Aufgabe keine technische Herausforderung ist und der Chef immer schnelle und unkomplizierte Lösungen mag. Also irgendwie “zwischendrin” am späten Nachmittag die UI “aufbohren”, zusätzliche Abfragen im Frontend “packen”, die entsprechende Logik im Backend “anpassen”, mit den ermittelten Ergebnissen neue Listen in Views “zimmern”. Die extra Meile geht er mit dem Anklickbar machen und Öffnen der Rechnungen. Zufrieden lehnt der Entwickler sich kurz vor Mitternacht mit dem guten Gefühl zurück, die Anwendung weiter gebracht zu haben. Read more