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.
• 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.
• 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.
• FrontTailor – für SAP-Fiori-Entwicklung und -Betrieb, weil ich in meinen Projekten zu oft zehn Tabs, drei Transaktionen und einen Netzwerk-Trace gebraucht habe, um eine einzige Frage zu beantworten: Warum tut die App das?

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 FrontTailor

Zehn Tabs für eine Frage. Warum tut die App das?

Mit Rene Glavanovits, Daniel Krancz und Maximilian Olzinger habe ich die Bücher zu SAPUI5, SAP Fiori Elements und Full-Stack-Entwicklung mit SAP¹ geschrieben. Darin steht, wie Bindings funktionieren, wie Annotationen eine Object Page bauen und warum ein Component-Preload den Start rettet. Was in keinem Buch steht: wie es sich anfühlt, an einem Dienstagmorgen vor einer App zu sitzen, die gestern noch lief.

So ein Morgen geht ungefähr so. Um 7:40 kommt die Mail: „Die Bestellfreigabe zeigt keine Positionen mehr.“ Der Transport ist gestern Abend nach PROD gegangen. Auf QA hat alles funktioniert. Also:

1. DevTools auf
2. Network-Tab filtern
3. $batch von Hand lesen
4. UI5 Diagnostics
5. SAP GUI: /IWFND/ERROR_LOG
6. ST22
7. SU53
8. Cache-Buster prüfen
9. QA zum Vergleich
10. Kollegin anrufen

Zehn Tabs. Drei Systeme. Und jedes Werkzeug zeigt ein Stück: Der Network-Tab hat den roten Request, aber der Fehlertext steckt im Multipart-Body. UI5 Diagnostics kennt das Control, aber nicht den Request. Das Gateway-Fehlerprotokoll hat die Ursache, aber in einem anderen Fenster, mit einer Transaktions-ID, die man abschreiben muss. Und ob PROD wirklich dieselbe App-Version ausliefert wie QA, sagt einem keiner davon.

Jedes Werkzeug sieht einen Teil. Den Zusammenhang sieht keins.

In der Fliegerei gibt es dafür ein Wort: Situational Awareness. Ein Cockpit zeigt nicht zwanzig Instrumente nebeneinander, damit der Pilot sie selbst zusammenrechnet – es zeigt, was zusammengehört, zusammen. Genau das fehlte uns bei Fiori.

Also haben wir das Cockpit für Fiori-Apps gebaut.

FrontTailor ist ein Panel neben der App. Es weiß, welche UI5-Version läuft, welcher App-Typ, welches Launchpad, welches Backend. Es verbindet das Feld mit dem Control, das Control mit dem Binding, das Binding mit dem Request und den Request mit dem Fehlerprotokoll im richtigen System. Und es hat eine Regel, die wir aus der Fliegerei mitgenommen haben: Auf PROD wird nichts verändert, was sich nicht ausdrücklich verändern darf – im Zweifel bleibt es gesperrt.²

FrontTailor ist aus der täglichen Arbeit hinter diesen Büchern entstanden. Jedes Kapitel braucht ein Beispiel, jedes Beispiel eine App, und jede App irgendwann einen Fehler, den man erklären will. Die Fragen, die wir beim Schreiben immer wieder von Hand beantwortet haben – welches Control, welches Binding, welche Annotation, welcher Request –, sind heute die Ansichten im Panel. Alle Bücher nach Thema.

Fünf Gedanken, nach denen FrontTailor gebaut ist:

1. Gedanke 1 · Ein Cockpit, nicht zehn Instrumente

   Was zusammengehört, steht zusammen.

   Vom Pixel zum Control, vom Request zum Control³, vom Fehler ins Fehlerprotokoll des richtigen Systems⁴. Die Übersicht⁵ sagt, wo du bist, bevor du suchst.

2. Gedanke 2 · Sterile Cockpit

   Auf PROD wird gelesen, nicht geändert.

   In kritischen Flugphasen spricht im Cockpit niemand über etwas anderes als den Flug. Auf PROD tut FrontTailor nichts anderes als lesen: Jede Änderung zur Laufzeit wird im Service Worker gegen das Host-Profil geprüft², und das Symbol wird rot⁶.

3. Gedanke 3 · Freigabe für einen Flug

   Zugriff erst, wenn du ihn gibst.

   Als Fluglotse gibt man eine Freigabe für genau einen Flug. FrontTailor bekommt Zugriff auf eine App erst nach deiner Freigabe für diese Domain⁷ – und sendet nichts an uns⁸.

4. Gedanke 4 · Checkliste statt Gedächtnis

   Was jeden Morgen gleich ist, macht die Maschine.

   Piloten arbeiten nach Checkliste, auch nach zehntausend Stunden. Der Morgencheck⁹ und die Release-Prüfung nach dem Transport¹⁰ sind unsere Checklisten für den Fiori-Betrieb.

5. Gedanke 5 · Ehrlich über die Grenzen

   Jede Zahl mit Quelle, jede Lücke beim Namen.

   Darum stehen auf dieser Website Fundstellen. Darum schreiben wir hin, dass die Extension die Ladezeit messbar beeinflusst¹¹, dass FrontTailor gerade erst die Beta verlassen hat¹² und dass das ABAP-Add-on noch kein echtes SAP-System gesehen hat¹³.