Progressive Decoupling

Page 1

16.9.2016

API statt Apache: Warum Headless CMS das Content-Business umkrempelt

So verbessern Sie den Umsatz auf Ihrer Commerce-Plattform durch Merchandising Wie platzieren Sie die Produkte besonders verkaufsstark? Welche Tricks bieten Echtzeitund Personalisierungsfunktionen? Das Webinar zeigt Ihnen, wie Sie mit digitalem Merchandising Ihren Umsatz steigern.

Virtuelle Konferenz - Shopoptimierung 2016 Steigern Sie Ihren Gewinn durch bessere Abläufe. Praktiker und Experten zeigen Ihnen Stellschrauben und Tuning-Optionen unter der Oberfläche des Online-Shops. Zur Virtuellen Konferenz anmelden

API statt Apache: Warum Headless CMS das Content-Business umkrempelt von Dominik Grollmann

15.09.16 Das Internet entkoppelt sich immer mehr vom Browser - eine Herausforderung fürs ContentManagement. Der neue Trend 'Headless CMS' passt sich diesem Trend an und weist den Weg in die Zukunft. Doch der Umstieg will gut geplant und wohlüberlegt sein.

Bild: geralt / pixabay.com

Ein Stamm mit vielen Blüten: Moderne Content-Management-Systeme müssen vielfältige Anwendungen unterstützen.

http://www.ibusiness.de/members/intranet/db/756175grollmann.html

1/7


16.9.2016

API statt Apache: Warum Headless CMS das Content-Business umkrempelt

Weiterleiten

Artikel merken

Apps, Tablets, Messenger, Connected­Cars, Smartwatches und immer mehr Internet­der­Dinge: Keine Frage, im Internet haben sich die Nutzungsgewohnheiten in den vergangenen Jahren drastisch gewandelt. Wie tiefgreifend diese Änderung ist, zeigt ein Blick gerade einmal fünf Jahre zurück: 2011 ist in Deutschland das Facebook ­Fieber gerade ausgebrochen, jede Sekunde melden sich sieben neue Nutzer an, der Börsengang steht kurz bevor. Apple hat eben erst das iPad vorgestellt, der App­Store ist noch keine drei Jahre alt und verfügt über gerade 350.000 Programme. Das aktuelle Smartphone heißt iPhone 4, Siri ist der Welt noch nicht bekannt. Dafür sind Messenger schon längst erfunden: Die populärsten heißen Skype und CuSeeMe . Das Wichtigste jedoch: Vor fünf Jahren dominierten Webbrowser und Mail­Client beinahe unangefochten als universelle Zugangsmöglichkeiten zum Internet. "Internet" war quasi gleichbedeutend mit "Web".

HANDLUNGSRELEVANZ

Operativ Strategisch Visionär

Technik Medien Wirtschaft

heute

morgen

übermorgen

Die iBusiness­Handlungsmatrix zeigt, wie langfristig die vorgestellten Aufgaben angegangen werden müssen.

TL;DR Content­Management­Systeme müssen dafür gewappnet sein, eine unüberschaubare Vielzahl von Anwendungen, Applikationen und Geräten zu bedienen. Headless CMS ist eine gute Lösung.

Im Jahr 2016 sieht die Welt ganz anders aus. Webbrowser und Mail­Client sind fraglos weiterhin von Bedeutung. Doch ihre Gatekeeper­Funktion haben sie eingebüßt: Facebook ist für viele Nutzer zum neuen Einstiegspunkt geworden ­ natürlich nicht per Browser, sondern als App. Suchanfragen werden per Sprachassistent an die Server übertragen. Jede Sekunde rasen weltweit rund 350.000 Nachrichten allein durch's WhatsApp ­Netzwerk. Smart­TVs haben die Wohnzimmer erobert. Produkte und Bilder werden in Apps von Amazon und Instagram gesucht. Zeitungen und Zeitschriften publizieren nicht nur auf ihren Onlinekanälen, sondern ebenso in Social Media, auf dem Smartphone oder bei Aggregatoren wie Blendle oder Readly . Und immer mehr Services werden mit Schnittstellen zu Bezahldiensten (Paywall) oder Single­Sign­In­Diensten ausgestattet. Schon an dieser Auflistung zeigt sich, dass sich in äußerst kurzer Zeit die Anforderungen ans Web­Publishing rapide gewandelt haben. Und: Nichts deutet darauf hin, dass sich an dieser Entwicklung in Zukunft etwas ändern würde. Im Gegenteil: Messenger werden gerade als nächstes großes Ding gehypt. Smarte Bots sollen dort ­ von der Fahrplanauskunft über die Newsrecherche bis zum Geldtransfer ­ viele Aufgaben erledigen, wegen denen wir bislang den Browser bemühen. Connected­Cars und Smartwatches werden ihre Bedeutung als Einfallstore ins Internet ausbauen und immer mehr Alltagsgeräte ­ von der Küchenmaschine bis zur Heizungssteuerung ­ werden vernetzt. Es liegt auf der Hand, dass immer mehr Internetkommunikation in den kommenden Jahren nicht mehr von einem Webbrowser initiiert wird und keinen Webserver wie Apache zur Beantwortung erfordert. Die Vormachtstellung des Browsers ist gebrochen. Er ist nur noch eine Zugangsmöglichkeit unter vielen. Zugleich steigen die Ansprüche an die Vernetzung: Content­Aggregatoren fordern präzisen Zugang zu (Teil­)Informationen, verschiedene Endgeräte und Angebote werden über Kreuz verbunden und müssen sich gegenseitig autorisieren. Natürlich ist eine solche grundlegende Neustrukturierung nicht möglich, ohne dass sich auch die Ansprüche an Content­Management­Systeme tiefgreifend ändern würden. "Der Bedarf an Multichannel­Kommunikation und zentralen Redaktionsprozessen führt zu deutlich strukturierteren Datenzugriffen", hat etwa Michael Märtin , Geschäftsführer der Atlantis Media erkannt. "Nicht nur Websites, sondern auch Landingpages, Online­ Magazine und Apps müssen mit Inhalten versorgt werden." Sprich: Die Informationsbereitstellung muss kleinteilig erfolgen und eine Vielzahl von Anwendungsszenarien unterstützen. Mehr noch: Idealerweise ist die Informationsbereitstellung gänzlich unabhängig von der Applikation (siehe iBusiness: Content­Marketing ­ Diesen

http://www.ibusiness.de/members/intranet/db/756175grollmann.html

2/7


16.9.2016

API statt Apache: Warum Headless CMS das Content-Business umkrempelt

Anforderungen muss Ihr CMS in Zukunft genügen).

Die Antwort ist: Headless Schon die Klassifizierung herkömmlicher Content­Management­Systeme (CMS) lässt erahnen, wo die Lücke klafft: Zwischen Enterprise­ und Web­CMS. Für die Bereitstellung von Wetterinformationen (z.B. für die Smart­Home­ Steuerzentrale) oder Songtexten (z.B. für die Musik­Streaming­App) ist weder das eine noch das andere System geeignet. Erstere scheiden schon auf den ersten Blick aus, weil sie komplett unhandlich und überdimensioniert sind. Da scheinen die kleineren Web­CMS schon deutlich besser. Doch auch sie weisen einige entscheidende Einschränkungen auf:

Bild: Atlantis Media

Michael Märtin, Atlantis Media: 'Multichannel­Kommunikation führt zu deutlich strukturierteren Datenzugriffen.'

Die Stärke von regulären Content­Management­Systemen liegt darin, dass auf der einen Seite Inhalte hineingeschaufelt, systematisiert, organisiert und verwaltet werden und mit wenig Aufwand auf der anderen Seite eine individualisierte und personalisierte Website ausgeworfen wird ­ zumindest wenn der Website­Manager dazwischen seine Arbeit richtig gemacht hat. Selbst viele Website­Funktionalitäten (sei es Login, Kommentarfunktion oder Transaktionen) werden vom CMS bereitgestellt.

Dies bedeutet aber auch, dass die gespeicherten Daten mit einer ganzen Reihe vordefinierter Funktionen ausgeliefert werden. Neben dem Content­Repository (in dem die Inhalte verwaltet werden) ist die Template­Engine elementarer Bestandteil des CMS. Dort werden die Anfragen bearbeitet sowie Inhalt, Layout und Funktionalität zu einer fertigen Website gemischt. Das bedeutet: Der Content wird immer mit Template­Informationen aufbereitet. Ein Webserver gibt die formatierten Inhalte aus. Die Inhalte werden immer beim Webserver (durch einen View) angefordert.

Dieser Ablauf ist in den oben geschilderten Anwendungsfällen oft komplett hinderlich. Beispiel Wetterbericht in der Steuerzentrale des Smart Homes: Würde die Vorhersage von einem Web­CMS bereitgestellt, müssten die Daten http://www.ibusiness.de/members/intranet/db/756175grollmann.html

3/7


16.9.2016

API statt Apache: Warum Headless CMS das Content-Business umkrempelt

einerseits geparst und neu aufbereitet werden, damit die reine Information bereitsteht. Drückt der Anwender den "Mehr"­Button, der neben dem Wetterbericht des Tages angezeigt wird, müsste außerdem ein neuer View ausgelöst werden, damit die Wettervorhersagen für die weiteren Tage geladen werden. Ein Headless CMS ist dagegen weder auf einen View angewiesen, noch liefert es Template­Informationen mit. Es besteht ausschließlich aus dem Backend für Redakteure und Mitarbeiter, der eigentlichen Datenbank (Repository) sowie der Logik zur Verwaltung. Es fehlt: Das Frontend. Stattdessen gibt es eine API (meist RESTful), auf die die verschiedenen Applikationen zugreifen können. Beim Headless CMS greift das Frontend der Heizungssteuerung also direkt auf den Datensatz mit den Wetterinformationen zu. Das CMS liefert diese Daten personalisiert (Datum, Region) aus und die App verarbeitet sie mit anderen Daten (etwa Raum­ und Kesseltemperatur) und weiteren beliebigen Informationen zur kompletten Frontend­Ansicht. Werden neue Inhalte benötigt (Stichwort: "Mehr"­ Button), werden diese dynamisch nachgeladen. Es ist nicht nötig, einen neuen View abzurufen.

Ob es am Ende mehrere Applikationen, Webseiten oder andere Medien gibt, welche sich aus den Inhalten des Headless CMS bedienen, ist egal. Es muss nur noch eine Quelle bearbeitet werden, um mehrere Produkte gleichzeitig zu speisen. Vorteile: Daten und Inhalte werden über eine standardisierte API ausgeliefert. Die API lässt sich mit den unterschiedlichsten Programmiersprachen aus den verschiedensten Anwendungen ansprechen. Inhalte können serverübergreifend abgerufen und an anderer Stelle punktuell eingesetzt werden.

Ein weiterer Vorteil eines Headless CMS sind die dynamischen Abfragen der RESTful­API. Dadurch ist es möglich, auch nach dem Aufruf der Webseite Daten abzufragen und dynamisch einzubetten. Dieses Prinzip lässt sich zwar auch in einem Browser unter Verwendung von JavaScript erzielen. Allerdings müssen dann die kompletten Inhalte bereits beim ersten View übertragen werden. Das JavaScript speichert sie und zeigt sie erst bei Bedarf an. Werden zu wenige Informationen übertragen, ist ein erneuter Pageview erforderlich. Werden zu viele übertragen, leidet die Performance. Anders beim Headless CMS: Die Abfrage über RESTful­APIs ist jederzeit dynamisch möglich. Das Frontend kann den Content komplett flexibel anfordern und verarbeiten.

http://www.ibusiness.de/members/intranet/db/756175grollmann.html

4/7


16.9.2016

API statt Apache: Warum Headless CMS das Content-Business umkrempelt

Die Rückseite der Medaille So modern und zukunftsweisend Headless CMS auf der einen Seite sind, so fordern sie auf der anderen Seite auch einigen Tribut. Insbesondere ist in den vergangenen Jahren viel Knowhow in Frontend­Features geflossen. Dies können einerseits komplette Komponenten wie eine ECommerce­ Funktionalität sein, die das CMS mit abdeckt. Wird das CMS­ Frontend deaktiviert, müssen diese Funktionen selbst nachprogrammiert werden. Aber auch unter der Haube steckt meist viel Entwicklungsarbeit. In klugen Caching­Konzepten, optimiertem Seitenaufbau und smarten JavaSripts für's Bild: BMW Rendering steckt bereits viel Gehirnschmalz. Wird das Connected Car mit Smartwatch: Der Client muss wieder klüger werden. eingebaute Front­End aufgegeben, bedeutet dies für die Web­ Performance nicht unbedingt Gutes. Außerdem muss viel Zeit, Geld und Mühe in den Nachbau bereits gut funktionierender Features gesteckt werden. Hinzu kommt, dass auch REST (Representational State Transfer) nicht der Weisheit letzter Schluss ist. Gerade wenn eine Abfrage Inhalte aus mehreren Quellen benötigt, werden viele Ressourcen verbraucht. Um dieses Performance­Problem zu bändigen, können zwar individuelle API­Endpunkte definiert werden ­ doch auch dies kann zu Problemen führen. Allein die Verwaltung vieler Endpunkte kann zu einer Mammutaufgabe werden. Steht eine Aktualisierung an, muss zudem der gesamte Code angepasst werden, der die Daten des individuellen Endpunkts entgegennimmt. Dies bedeutet aber, dass alle Vorarbeiten im Backend abgeschlossen sein müssen, bevor das Frontend aktualisiert wird. In der Entwicklung entsteht ein Flaschenhals. Auch die Anforderungen an das Hosting ändern sich. Anfragen kommen nicht mehr nur von einer Webseite, sondern von mehreren Applikationen und Medien, die alle (mittelbar) auf die Datenbank zurückgreifen wollen. Der Server des Headless CMS muss dieser Aufgabe gewachsen sein und die Anfragen innerhalb kürzester Zeit abarbeiten. Bei einem Serverausfall sind die damit verbundenen Applikationen oft viel direkter betroffen, da sie oftmals gar nicht mehr arbeiten, wo zuvor nur eine Teilinformation ausgefallen ist.

Königsweg "Schrittweise Entkopplung" So verlockend auf der einen Seite die Vorteile einer Entkopplung von Frontend und CMS sind, so nachvollziehbar sind andererseits die Einwände. In der Praxis hat ein Unternehmen wenig davon, ein bestehendes System einzureißen, um ein neues, enorm solides Fundament zu errichten ­ auf dem dann aber eine Bretterbude entsteht, weil Zeit, Geld und Kapazitäten für einen Neubau fehlen. Dann lieber im Altbau noch zwei, drei Jahre länger ein­, aus­ und umbauen, bis das alte Fundament richtig ächzt ... . Um diesen Konflikt zu entschärfen, bietet sich eine schrittweise Entkopplung ("Progressive Decoupling") an. Die Idee dahinter ist es, das bestehende CMS in seiner Gänze beizubehalten, aber Teile oder Module parallel über eine API­Erweiterung anzubieten. Auf diese Weise kann das bewährte (Web­)Frontend bestehen bleiben, während andere Applikationen und Plattformen bereits aus der API mit Inhalten versorgt werden. So können einzelne Module oder Bereiche außerhalb der Webseite zugänglich gemacht werden und trotzdem der komplette Funktionsumfang auf der Website beibehalten werden ­ mit allen Vorteilen der Auslieferung kompletter Pages aus der Template­Engine. Progressive Decoupling ebnet so den Weg in die neue CMS­Architektur ohne einen plötzlichen Bruch zu fordern. Entsprechende API­Erweiterungen sind für viele Content­Management­Systeme erhältlich.

http://www.ibusiness.de/members/intranet/db/756175grollmann.html

5/7


16.9.2016

API statt Apache: Warum Headless CMS das Content-Business umkrempelt

Digitalisierung statt World Wide Web Insgesamt ist ein Headless CMS keine Investition ins Web, sondern in die Digitalisierung des Unternehmens. Rein für einen Web­Auftritt sind die Vorteile kaum spürbar. Deswegen sollten Sie bei der Planung auch über aktuelle Webprojekte hinaus denken und die gesamten digitalen Kanäle Ihres Unternehmens bewerten. Ist es profitabel, die digitalen Lösungen so umzubauen, dass sie alle digitalen Kanäle bedienen können? Welche Architektur kann auf lange Sicht das digitale Geschäft am besten unterstützen und aufrechterhalten? Es sind eindeutig eher langfristige, strategische Ziele, die durch die Einführung eines Headless CMS erreicht werden. Damit dabei aber kurzfristige Lösungen nicht aus dem Fokus geraten, bietet sich in vielen Fällen die schrittweise Einführung als Königsweg an. 1 |2 weiter

1. Teil: API statt Apache: Warum Headless CMS das Content­Business umkrempelt 2. Teil: Dominik Grollmann: Erfolgskonzept für Shop­ und Marketing­Software?

Marktzahlen zu diesem Artikel Funktionsweise eines traditionellen Content Management Systems

Funktionsweise eines Headless Content Management Systems

(13.09.16)

(13.09.16)

Ausgewählte Agenturen und Dienstleister zu diesem Themenbereich

atlantis media GmbH atlantis media ist eine Full Service Agentur für die Digitalisierung von Geschäftsprozessen und moderne E­Commerce­Systeme. Das Unternehmen wurde 1994 in Hamburg gegründet und entwickelt heute anspruchsvolle Softwarelösungen für B2B­ und B2C­Kunden. Bei der Entwicklung und Umsetzung von Onlineshops, Webapplikationen und Business­Intelligence­Lösungen zeichnet sich atlantis media durch langjähr...

In diesem Beitrag genannt: Personen: Michael Märtin Firmen und Sites: apache.org apple.de readly.com skype.com whatsapp.com Tags: Content

CMS

Headless

atlantismedia.de wikipedia.de

blendle.com

Content­Management System

facebook.com

instagram.com

Content Management System

http://www.ibusiness.de/members/intranet/db/756175grollmann.html

6/7


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.