Insights
Beiträge zu den Themen, an denen Software-Vorhaben gewinnen oder scheitern.
Aus der Praxis
Konkrete Beispiele, Muster und Erfahrungen.
Entwicklung & DeliveryAus der Praxis
Revisionssicheres Logging: Warum Datenbank-Logs im Audit nicht zählen
Fast jedes System protokolliert. Trotzdem scheitern Prüfungen an der Frage, wer wann was geändert hat. Der Unterschied zwischen Log und Nachweis — und was ihn ausmacht.
Entwicklung & DeliveryAus der Praxis
Production Readiness in der AI Factory: Was man prüft, wenn Agenten den Code schreiben
Requirements sind agentenlesbar, das arc42 gepflegt, die Pipeline grün. Die alte Frage „läuft es?" ist trivial geworden. Die neue lautet: Woran erkennen wir, dass eine Änderung stimmt, wenn niemand mehr jede Zeile gelesen hat?
Entwicklung & DeliveryAus der Praxis
Production-Readiness-Checkliste: 12 Fragen, die erfahrene Teams im Kopf haben
Kaum ein Team hakt vor dem Deployment eine Liste ab — und das ist normal. Diese zwölf Fragen sind trotzdem nützlich: als Planungswerkzeug in der Architektur und als Gesprächsgrundlage nach dem nächsten Ausfall.
Entwicklung & DeliveryAus der Praxis
Wer hat die Kreditprüfung übersprungen? Auftragsabwicklung über fünf Systeme
Eine Falschlieferung, fünf Systeme, drei Stunden Suche — und eine simple neue Freigaberegel kostet acht Wochen. Ein Praxisbeispiel aus dem B2B-Handel, wie ein Ereignisfundament Nachvollziehbarkeit und Änderbarkeit gleichzeitig löst.
Entwicklung & DeliveryAus der Praxis
Monolith modernisieren, ohne alles neu zu bauen
Der große Rewrite ist fast immer die teuerste Option. Die meisten Monolithen lassen sich Schritt für Schritt modernisieren — wenn man den richtigen Schnitt findet und die Altlasten nicht gleichzeitig mit den Geschäftsprozessen ersetzen will.
Entwicklung & DeliveryAus der Praxis
Wer hat was zugesagt? Wenn niemand rekonstruieren kann, was passiert ist
Ein Kunde fragt nach einer Zusage, die vor Monaten gemacht wurde. Fünf Leute suchen zweieinhalb Stunden in sechs Werkzeugen — und das Ergebnis widerspricht sich. Ein Praxisbeispiel, wie eine einzige Quelle der Wahrheit diese Frage beantwortbar macht.
Marketing & PositioningAus der Praxis
Gute Technik, schlechte Story: Positionierung für IT-Dienstleister
Viele technische Dienstleister sind exzellent in der Umsetzung, aber schwierig zu vermitteln. Die Story, die ein Kunde versteht, ist selten die Story, die das Team über sich selbst erzählt. Positionierung ist die Brücke dazwischen.
Personal & KulturAus der Praxis
Ownership statt Rollen: wer nach dem Go-live wirklich zuständig ist
Ein System geht live. Drei Monate später weiß niemand, wer für einen kritischen Fehler zuständig ist. Der Unterschied zwischen Rolle und Ownership ist der Unterschied zwischen einem System, das läuft, und einem, das ankommt.
Entwicklung & DeliveryAus der Praxis
Multi-Tenancy mit Keycloak: Was im Token gehört und was nicht
Mandantenfähigkeit scheitert selten am Login, sondern am Modell dahinter. Ein praxisnaher Leitfaden zu Realms, Rollen, Token-Design und Migration bestehender Nutzer.
Entwicklung & DeliveryAus der Praxis
Event Modeling ist kein Architekturwerkzeug — es ist ein Adoption-Werkzeug
Event Modeling wird als Technik verkauft. Sein größter Effekt liegt woanders: Fachbereich und Team sehen zum ersten Mal dasselbe Bild und entscheiden gemeinsam, was gebaut wird.
Entwicklung & DeliveryAus der Praxis
Event Sourcing ohne Angst: wann es sich lohnt und wann nicht
Event Sourcing wird oft als Risiko wahrgenommen. In Wahrheit ist es ein Werkzeug mit einem sehr spezifischen Einsatzgebiet: dort, wo die Historie der Daten wichtiger ist als ihr aktueller Zustand.
Entwicklung & DeliveryAus der Praxis
Fractional CTO: Wann externe technische Führung sinnvoll ist — und wann nicht
Ein Leitfaden für KMU und Mittelstand: Was ein Fractional CTO tatsächlich macht, an welchen fünf Signalen Sie den Bedarf erkennen, was in den ersten 90 Tagen realistisch passiert — und wann die Rolle die falsche Antwort ist.
Fundament
Die Grundhaltung zu diesem Bereich — warum wir so arbeiten.
Entwicklung & DeliveryFundament
Mandantentrennung, die den Security-Fragebogen übersteht
Ein vergessener Filter ist ein meldepflichtiger Vorfall. Warum Isolation im Anwendungscode kein Nachweis ist — und welche Modelle Enterprise-Kunden akzeptieren.
AllgemeinFundament
Warum Digitalisierungsprojekte an den Übergängen scheitern
Projekte scheitern selten am Code. Sie scheitern an den Stellen, an denen Verantwortung wechselt: von Entscheidung zu Umsetzung, von Umsetzung zu Nutzung, von Nutzung zu Wirkung. Die Grundthese hinter Kaihito.
Personal & KulturFundament
Teams, die Transformation tragen: psychologische Sicherheit ist kein Wohlfühlthema
In Digitalisierungsvorhaben entscheidet nicht die Motivation eines Teams, sondern ob schlechte Nachrichten früh nach oben gelangen. Über psychologische Sicherheit, Führung und Recruiting in Transformationskontexten.
Sales & Go-to-MarketFundament
Komplexe Software verkaufen — zuerst nach innen, dann nach außen
Jedes Software-Vorhaben wird zweimal verkauft: einmal an den Kunden und einmal an die eigene Organisation. Der zweite Verkauf entscheidet über Adoption — und wird fast immer vergessen.
Entwicklung & DeliveryFundament
Software, die hält: Warum wir bei der Fachlichkeit anfangen — und nicht beim Stack
Die meisten Systeme scheitern nicht an der Technologiewahl, sondern daran, dass niemand die Fachlichkeit sauber verstanden hat. Über Event Modeling, Event Sourcing und Ownership als Grundlage langlebiger Software.
Marketing & PositioningFundament
Positionierung im Tech-Bereich: Substanz statt Floskeln
Der größte Wert von Software liegt oft im Unsichtbaren. Dieser Beitrag zeigt, wie IT-Unternehmen den Schritt von oberflächlicher Originalität zu echter Authentizität und spürbarer Wirkung meistern.
Entwicklung & DeliveryFundament
Die drei Übergänge: Architektur, Delivery, Adoption
Software-Vorhaben scheitern selten in der Mitte einer Phase. Sie scheitern an den Übergängen dazwischen — dort, wo Verantwortung stillschweigend den Besitzer wechselt.
Notizen
Kurze Gedanken, Links und Videos.
Entwicklung & DeliveryNotiz
Logging als Ballast — wo ist die Wahrheit?
AI nimmt uns die Last der menschlichen Unschärfe. Warum stellen wir unseren Kernprozessen dann eine zweite Unschärfe in Form eines Logs daneben?
Personal & KulturNotiz
Zwölf Rollen werden drei: was Gartners Teamzuschnitt für die Nachweisbarkeit bedeutet
Gartner erwartet kleinere Engineering-Teams. Die Rollenkarte dahinter streicht vor allem Übersetzungsrollen — und damit die Stellen, an denen Entscheidungen bisher nebenbei dokumentiert wurden.