Never give up. The sky is the limit.

01Wer ich bin

Every life counts. Nicht 999 von 1.000.

Bevor ich Software gebaut habe, habe ich zwei Berufe erlernt, in denen es keine 99,9 % gibt: Linienpilot bei Austrian Airlines und Fluglotse bei Austro Control. Die Aufnahmetests für beide gehören zu den schwersten der Welt – der DLR-Test in Hamburg mit seiner Durchfallquote nördlich von 98 %, das mehrtägige Assessment bei Austro Control, in dem Menschen erfahren, wie belastbar sie wirklich sind. Zehntausende bewerben sich, ein paar Dutzend kommen durch. Ich habe beide bestanden.

IQ misst, wie schnell jemand denkt. Der Cockpit-Test misst, wie ruhig jemand bleibt, wenn die Anzeige rechts oben schon fünf Sekunden lang etwas Falsches meldet und man es als Erster merken muss. In der Fliegerei zählt das zweite. Und über allem steht ein Prinzip: Es zählt jedes Leben. Every life counts. Nicht 999 von 1.000. Alle.

Ob das eine Berufs-Pose oder ein Betriebssystem ist? Als ich im Herbst 2025 nach dreißig Jahren Pause wieder mit Tennis begonnen habe, habe ich mir einen Trainer gesucht, der jahrzehntelang ATP-Top-10-Spieler betreut hat. Nicht, weil ich auf die Tour will – sondern weil ich, wenn ich etwas ernst nehme, wissen will, wo mein Deckel wirklich ist.

02Zu Hause

Drei Kinder, ein Vater, kein Autopilot.

Ich bin alleinerziehender Vater von drei Kindern. Die beiden Jüngeren sind im Schulalter, der Älteste ist volljährig. Wer das kennt, weiß: Es gibt keinen Dienstplan, der hält, und keinen Tag, der so endet, wie er geplant war. Man lernt, Prioritäten in Sekunden zu setzen – und sie am nächsten Morgen neu zu sortieren.

Mein ältester Sohn ist schwer behindert. Er lebt mit einem seltenen Gendefekt, einer Mikrodeletion. Er hat mir mehr über Geduld, Verlässlichkeit und das Wesentliche beigebracht als jedes Assessment und jedes Projekt.

Meine drei Kinder sind mein Lebensmittelpunkt und meine Motivation – jeden einzelnen Tag.

Wenn ich „Every life counts“ sage, ist das kein Satz aus dem Cockpit mehr. Es ist Alltag. Und es ist der Grund, warum ich Software baue, die Menschen Zeit zurückgibt – Zeit, die woanders dringender gebraucht wird.

Mein Leben hat sich durch all das massiv verändert. Ich bin noch strukturierter geworden, als ich es aus dem Cockpit gewohnt war – und genau deshalb passt in die frühen Morgenstunden, bevor das Haus aufwacht, jeden Tag eine Stunde Sport: Kettlebell, Rope Skipping, Boxen. Nicht trotz der Verantwortung, sondern wegen ihr.

Ich bin überzeugt: Das Wichtigste ist die tägliche Routine.

Große Ziele erreicht man nicht mit großen Tagen, sondern mit vielen gewöhnlichen, die verlässlich gleich beginnen. Genau so bauen wir Software: Sie soll die tägliche Routine tragen – unspektakulär, verlässlich, jeden Tag –, damit für das Unplanbare Kopf und Zeit bleiben.

Never give up.
The sky is the limit.

Mein Motto. Kein Poster an der Wand – eine Entscheidung, jeden Morgen.

03Ein Satz in Hamburg

Wie aus KSIC die CloudDNA wurde.

Ich habe die CloudDNA vor über zehn Jahren gegründet – ursprünglich nicht unter diesem Namen. Ich kam von SAP, wo ich Jahre in einem der größten Softwarekonzerne der Welt verbracht hatte. Ein sicherer Hafen. Ich habe ihn trotzdem verlassen.

Am Anfang stand ein sperriger Name: die KSIC GmbH – Koch Security, Integration and Cloud Consulting. Vier Buchstaben, die niemand aussprechen konnte. Die Rettung kam bei einem Abendessen in Blankenese, Hamburg, in einem Fischlokal an der Elbe. Mein alter SAP-Kollege Jörg hörte sich zum dritten Mal meine Erklärung an, hob das Glas und sagte einen einzigen Satz:

„Martin, du hast die Cloud in deiner DNA.“

Zwei Wochen später hieß die KSIC GmbH nicht mehr KSIC. Mit dabei war damals schon Daniel, mein erster Mitarbeiter – auf seiner allerersten Dienstreise. (Den Steinbutt, Daniel, tut mir bis heute leid.)

Angefangen haben wir in einem winzigen Büro in Oberwart. Heute sitzen wir in der ehemaligen Raiffeisenbank in Loipersdorf, mitten in der Thermen- und Weinregion Südburgenland, und schöpfen aus zwei Talentschmieden, die man auf keiner Weltkarte findet: der HTL Pinkafeld und der FH Burgenland. Aus dem Duo ist ein Team von 24 Menschen geworden, und wir haben siebzehn Bücher bei SAP Press veröffentlicht – immer aus der Praxis, nie aus dem Marketing.

04Der Umbruch

Individualsoftware war ein rotes Tuch. Bis 2023.

Ich habe die CloudDNA aufgebaut, um für Konzerne SAP-Integrationen zu bauen – schwere Software, in Monaten getaktet. In dieser Welt mied man Individualsoftware wie der Teufel das Weihwasser: zu teuer, zu langsam, zu riskant.

Dann kamen die Sprachmodelle.

Mir wurde klar: Das ist keine graduelle Verbesserung, das ist der Umbruch, der unser Handwerk umschreibt. Also habe ich mich selbst hingesetzt und Software gebaut – nachts, am eigenen Editor, mit denselben Werkzeugen, die ich meinem Team empfehle. Man kann niemandem mit einer PowerPoint erklären, wie KI-gestützte Entwicklung funktioniert. Man muss es vorleben.

Was früher drei Monate und ein sechsstelliger Betrag war, geht heute in Wochen. Nicht, weil Programmierer zaubern, sondern weil Copiloten die Fleißarbeit übernehmen und Entwickler wieder werden, was sie sein sollten: Handwerker mit Kopf.

05Wir bauen das

Von „We deliver“ zu „Wir bauen das“.

Über zehn Jahre lang hieß unser Versprechen „We deliver“: Ein Kunde beschreibt, wir liefern. Das hat uns groß gemacht. Aber es hat eine Grenze: Wer nur liefert, was bestellt wird, baut selten das, was gebraucht wird.

Deshalb bauen wir uns um. Aus Beratern und Entwicklern werden Forward Deployed Engineers und Product Owner. Forward deployed heißt: Sie sitzen dort, wo das Problem entsteht – in der Hausverwaltung, im Weingut, in der Kanzlei – und bauen vor Ort. Product Owner heißt: Sie bleiben, bis es gelöst ist, und verantworten das Produkt, nicht das Ticket.

„Wir bauen das.“ Drei Wörter, die man einem Kunden nur sagen darf, wenn man sie auch meint.

06Wir sprechen KI

In der KI-Blase und vor allem draußen.

In der KI-Blase reden alle über Modelle, Benchmarks und Agenten. Draußen – bei der Hausverwalterin mit tausend Tops, beim Winzer im Südburgenland, beim Wirt mit zwanzig Tischen – zählt eine andere Frage: Spart mir das morgen eine Stunde, und kann ich mich darauf verlassen?

Wir übersetzen zwischen diesen Welten. Wir bauen täglich mit Claude von Anthropic und sind auf dem besten Weg, Partner von Anthropic zu werden. Aber was beim Kunden ankommt, ist kein Modell, sondern ein Ablauf, der funktioniert:

• Die KI schlägt vor, ein Mensch entscheidet. Mehr Selbstständigkeit gibt es erst nach bestandener Probezeit.
• Jede Aktion steht im Prüfpfad. Was die KI getan hat, lässt sich nachlesen.
• KI muss sich rechnen. Eigener Schlüssel, feste Kostengrenze je Mandant.
• Daten bleiben, wo sie hingehören. Mandanten bis in die Datenbank getrennt.

Anthropic und Claude sind Marken der Anthropic PBC. Die Nennung beschreibt unsere Arbeitsweise.

07Die Familie der Tailors

Maßgeschneidert statt Standard mit hundert Kompromissen.

Statt nur über KI-gestützte Entwicklung zu reden, haben wir Branchen ausgesucht, die ich gut genug kenne – oder in denen ich Freunde habe, die mir das Problem so lange erklären, bis es sitzt. Jeder Tailor teilt mit seinen Geschwistern dasselbe Fundament, aber spricht die Sprache seiner Branche:

• iFlowTailor – für SAP-Integration, die ich seit 2006 baue: Die Werkzeuge für Entwicklung und Betrieb haben mir nie gereicht – also bauen wir die Werkbank für Entwicklung, Betrieb und Administration in einem.
• ProbeTailor – für Abnahmetests in SAP-Projekten und Fachsoftware, weil ich in all den Jahren SAP-Beratung zu viele Abnahmen in Excel-Listen und zu viele Screenshots in Mails gesehen habe.
• JournalTailor – für die Kreditorenbuchhaltung vor SAP, BMD und DATEV, weil ich in SAP-Projekten zu oft gesehen habe, wie Rechnungen abgetippt werden, obwohl die Buchung dahinter längst Routine ist.
• DocumentTailor – für SAP-Häuser, weil ich selbst fünfzehn Jahre lang Formulare auf den SAP Adobe Document Services gebaut habe und die Nachfolgefrage nicht länger unbeantwortet lassen wollte.
• RecordTailor – für alle, die ein DMS brauchen, das nicht nur speichert, sondern liest – weil ich zu oft gesehen habe, wie jemand heimlich Excel öffnet, weil das DMS zu langsam ist.
• ImmoTailor – für Hausverwaltungen und Projektentwickler, weil sich dort Buchhaltung, Technik und Portale besonders oft im Weg stehen.
• TaxTailor – für Steuerkanzleien, weil ein Freund mir bei einem Glas Wein von seinem Windows-Terminal-Server erzählt hat.
• DineTailor – für die Gastronomie, weil ich seit Jahren an fremden Tischen sitze und Champagner an Wirte verkaufe.
• StayTailor – für die Hotellerie, weil die Thermenregion voller Betriebe steckt, die sich unter dem Konditionen-Diktat der Portale ducken.
• MeetingTailor – für Sitzungen und Gremien, weil Stiftungsräte, Gemeinderäte und Vereinsvorstände in meinem Freundeskreis immer wieder dieselbe Nachtszene beschreiben.
• Weintailor – für Winzerinnen und Winzer, weil wir mitten in einer Weinregion sitzen und jede zweite Reise ohnehin zur Weinreise wird.
• BuildTailor – für Bau und Handwerk, weil Mängel, Pläne und Regieberichte auf der Baustelle entstehen – nicht im Büro.
• AuthTailor – für Single Sign-on, weil in meinen SAP-Projekten immer wieder eine Anmeldung scheitert, ohne zu sagen, warum. Den Tracer haben wir zuerst für uns selbst in iFlowTailor gebaut – jetzt stellen wir ihn allen gratis zur Verfügung.

Die CloudDNA ist deshalb kein reiner SAP-Zulieferer mehr, sondern eine Werkstatt mit einer wachsenden Produktlinie. Wirtschaftlich mutiger. Menschlich das Ehrlichste, was wir tun konnten.

08Warum AuthTailor

Single Sign-on funktioniert. Bis es nicht mehr funktioniert. Und dann sagt es nicht, warum.

Mit Siegfried Zeilinger habe ich die Bücher zu Sicherheit und Berechtigungen, Cloud Connector und Administration der SAP BTP¹ geschrieben. Darin steht, wie das Vertrauen zwischen SAP BTP und Identity Provider eingerichtet wird, wie Principal Propagation durch den Cloud Connector läuft und welche Rollensammlung welchen Scope bringt. Was in keinem Buch steht: wie es ist, wenn alles richtig eingerichtet scheint und die Anmeldung trotzdem scheitert. Eine Anmeldung hat viele Stationen, und an jeder kann sie hängen bleiben:

1. Browser
2. App
3. Identity Provider
4. SAML Response oder Token
5. Rollensammlung
6. 403 Forbidden

Die Fehlermeldungen sind dabei erstaunlich wortkarg: „invalid_grant“. „Assertion is not valid“. Eine Fehlernummer im Identity Provider, dessen Protokoll in einem anderen Tenant liegt, der einem anderen Team gehört. Und die App sagt einfach 403.

Jeder sieht seinen Teil. Den ganzen Ablauf sieht keiner.

Die Entwicklertools des Browsers zeigen die Anfragen, aber nicht, was sie bedeuten. Eine SAML Response ist Base64, oft noch komprimiert; ein JWT sind drei Teile Buchstabensalat, getrennt durch Punkte. Wer sie lesen will, kopiert sie von Fenster zu Fenster – und gibt das Token einer echten Anmeldung dabei aus der Hand. Für jemanden, der ein Buch über Sicherheit auf der SAP BTP geschrieben hat, ist das kein Arbeitsablauf, den man empfehlen kann.

In der Fliegerei gibt es für solche Momente den Flugschreiber. Nach einem Zwischenfall rät niemand, man liest die Aufzeichnung: jeder Schritt, in der richtigen Reihenfolge, mit Zeitstempel. Genau das wollte ich für eine Anmeldung.

Also haben wir den Flugschreiber für Single Sign-on gebaut.

Zuerst für uns selbst: als SAML- & OIDC-Tracer in iFlowTailor², der Werkbank für SAP Cloud Integration – dort steckt er bis heute. Dann wurde klar, dass das Problem nicht nur hat, wer mit SAP Cloud Integration arbeitet. Jede App mit SAML oder OpenID Connect hat es, mit SAP oder ohne. Deshalb gibt es AuthTailor als eigene Extension.

Und warum gratis? Weil uns Single Sign-on in unseren eigenen SAP-Projekten immer wieder Probleme bereitet – und weil es allen, die Anmeldungen einrichten, betreiben oder im Support erklären müssen, genauso geht. Ein Werkzeug, das wir selbst brauchen, hinter eine Bezahlschranke zu stellen, hätte sich falsch angefühlt. AuthTailor ist kostenlos, ohne Konto und ohne Lizenz³. Fünf Gedanken, nach denen es gebaut ist:

1. Gedanke 1 · Der Flugschreiber

   Erst aufzeichnen, dann urteilen.

   Ein Fehler zeigt sich selten dort, wo er entsteht. AuthTailor schneidet die ganze Anmeldung live mit⁴, in einem beliebigen Tab, und prüft state, nonce und PKCE über alle Schritte hinweg – nicht nur die letzte Anfrage, die rot ist.

2. Gedanke 2 · Kein Server

   Ein Token gehört auf kein fremdes Gerät.

   Wer Anmeldungen untersucht, hat echte Tokens vor sich. Deshalb hat AuthTailor keinen Server und keine Telemetrie⁵, hält Mitschnitte nur im Arbeitsspeicher⁶ und maskiert Geheimnisse schon beim Mitschneiden⁷.

3. Gedanke 3 · Freigabe für einen Flug

   Zugriff nur, solange er gebraucht wird.

   Als Fluglotse gibt man eine Freigabe für genau einen Flug, nicht für den ganzen Tag. So arbeitet auch AuthTailor: Der Zugriff auf Websites wird erst beim Mitschneiden erfragt und danach wieder abgegeben⁸.

4. Gedanke 4 · Ursache vor Symptom

   „403“ ist kein Befund.

   Ein Statuscode sagt, dass etwas fehlt, aber nicht, was. Die Ampel⁹ zeigt, in welchem Bereich es hakt, und auf der SAP BTP beantwortet „Warum 403?“ die Frage Scope für Scope¹⁰.

5. Gedanke 5 · Verstehen statt kopieren

   Wer den Ablauf kennt, findet den Fehler selbst.

   Das wollten wir mit den Büchern erreichen, und das soll auch das Panel können: 13 Abläufe von OAuth 2.0, OpenID Connect und SAML¹¹ zum Durchklicken, Schritt für Schritt, mit Glossar und Fehlerkatalog.