Thought Leadership
Wer im Online-Handel Headless geht, erhofft sich vor allem, schneller und flexibler zu werden. Doch wer nicht aufpasst, tappt in die Entwicklerfalle und bremst sich dadurch ungewollt wieder aus.
Immer mehr Unternehmen, die digital in disruptiven Märkten unterwegs sind, stellen ihre Software-Architektur auf Headless um. Sie setzen nicht mehr auf einen Software-Monolithen, der vermeintlich alles kann, sondern puzzeln sich ihre Lösung individuell aus vielen verschiedenen Microservices zusammen. Dahinter steht die Hoffnung, durch einen API-first- / Cloud-Native-Ansatz schneller, skalierbarer und flexibler auf Veränderungen im Markt reagieren und Kunden stets die beste Customer Experience bieten zu können.
In der Software-Welt wird Headless als lange erwarteter Heilsbringer gefeiert. Doch so mancher Anwender wird spätestens im täglichen Business ernüchtert feststellen: Ein solches System aus kleinen Bauteilen macht zwar nach hinten hin flexibler. Das Nutzererlebnis nach vorne verbessert sich dadurch allerdings nicht automatisch. Denn nicht immer lassen sich alle Microservices geschmeidig wie perfekt gestanzte Puzzleteile nahtlos zusammenfügen. Stattdessen entstehen in der Praxis immer wieder Brüche, weil Datenströme nicht richtig funktionieren oder Systeme nicht richtig aufeinander abgestimmt sind und dadurch nicht richtig gemanagt oder orchestriert werden können.
Headless macht Entwickler glücklich – aber oft nur bis zum Live-Gang
Das Versprechen der Headless-Spezialisten, dass Unternehmen durch den Headless-Ansatz schneller Innovationen auf die Straße bringen und agiler auf neue Herausforderungen reagieren können, wird von der Realität oft konterkariert. Denn wenn die Entwickler vollends damit beschäftigt sind, das Orchester verschiedener Software-Solutions und Schnittstellen zu managen, fehlt am Ende die Zeit, echte Innovationen auf die Straße zu bringen.
Doch damit nicht genug: Auch die Business-Teams, darunter beispielsweise Marketing oder Vertrieb, werden in ihren täglichen Alltagsaufgaben durch die Umstellung auf Headless unverhofft ausgebremst. Denn wenn es viele Software-Systeme gibt, die alle miteinander reden müssen, wird es für die Mitarbeiter schwierig, mit dem ganzen System zu interagieren. Ein Business-User-Interface, über das sie Elemente verändern oder hin- und herschieben können, ohne entwickeln oder coden zu müssen, gibt es in der neuen Headless-Welt nicht. Stattdessen sind sie bei jedem Detail, das sie am Frontend ändern wollen, darauf angewiesen, dass ein Developer sich ihren Wünschen annimmt.
Mit einer gewissen Polemik lässt sich also sagen: Mit einem Headless-Ansatz macht man Entwickler bis zum Livegang glücklich. Doch das böse Erwachen ist vorprogrammiert. Da, wo das Business wirklich stattfindet, werden Teams langsamer, abhängiger und weniger flexibel. Das ändert auch die Integration eines der verfügbaren Headless-CMS nur in Ansätzen. Denn diese Lösungen sind in ihrem Funktionsspielraum sehr eingeschränkt. Damit lassen sich zwar bestimmte Bereiche einer Seite verändert. Doch wer Seiten komplett neu zusammenstellen will, kommt nicht daran vorbei, dem Entwickler ein Ticket zu schreiben.
Darüber hinaus stellt so manches Unternehmen, das auf Headless umsteigt, nach einer Weile überrascht fest, dass die Total Cost of Ownership (TCO) deutlich höher ist als sie das von ihrer bisherigen Lösung gewohnt waren. Das liegt nicht nur daran, dass die kumulierten Lizenzkosten aller Bausteine höher sein können als die Kosten für die Lizenz eines monolithischen Systems. Auch das Management und das Hosting dieser Baustein-Lösung wird komplexer – und somit kostenintensiver.
Headless braucht einen Zwischen-Layer, der Business-Teams und Entwickler verknüpft
Damit Headless funktionieren kann, brauchen Entwickler eine Arbeitsumgebung, die es ihnen ermöglicht, die Microservices aus Developersicht effizient zu managen und Komponenten und Experiences zu bauen, die die verschiedenen Datenströme aus den verschiedenen Microservices verarbeiten und in ein digitales Kundenexperience umsetzen können. Business User hingegen brauchen ein Interface, damit sie mit den Building Blocks, die ihnen die Entwickler zur Verfügung stellen, eigenständig arbeiten können.
