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, ConnectedCars, Smartwatches und immer mehr InternetderDinge: 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 AppStore 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 MailClient 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 iBusinessHandlungsmatrix zeigt, wie langfristig die vorgestellten Aufgaben angegangen werden müssen.
TL;DR ContentManagementSysteme 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 MailClient sind fraglos weiterhin von Bedeutung. Doch ihre GatekeeperFunktion 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. SmartTVs 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 SingleSignInDiensten ausgestattet. Schon an dieser Auflistung zeigt sich, dass sich in äußerst kurzer Zeit die Anforderungen ans WebPublishing 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. ConnectedCars 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: ContentAggregatoren 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 ContentManagementSysteme tiefgreifend ändern würden. "Der Bedarf an MultichannelKommunikation 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: ContentMarketing 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 ContentManagementSysteme (CMS) lässt erahnen, wo die Lücke klafft: Zwischen Enterprise und WebCMS. Für die Bereitstellung von Wetterinformationen (z.B. für die SmartHome Steuerzentrale) oder Songtexten (z.B. für die MusikStreamingApp) 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 WebCMS schon deutlich besser. Doch auch sie weisen einige entscheidende Einschränkungen auf:
Bild: Atlantis Media
Michael Märtin, Atlantis Media: 'MultichannelKommunikation führt zu deutlich strukturierteren Datenzugriffen.'
Die Stärke von regulären ContentManagementSystemen 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 WebsiteManager dazwischen seine Arbeit richtig gemacht hat. Selbst viele WebsiteFunktionalitä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 ContentRepository (in dem die Inhalte verwaltet werden) ist die TemplateEngine 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 TemplateInformationen 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 WebCMS 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 TemplateInformationen 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 FrontendAnsicht. 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 RESTfulAPI. 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 RESTfulAPIs 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 FrontendFeatures 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 CachingKonzepten, 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 FrontEnd 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 PerformanceProblem zu bändigen, können zwar individuelle APIEndpunkte 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 APIErweiterung 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 TemplateEngine. Progressive Decoupling ebnet so den Weg in die neue CMSArchitektur ohne einen plötzlichen Bruch zu fordern. Entsprechende APIErweiterungen sind für viele ContentManagementSysteme 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 WebAuftritt 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 ContentBusiness umkrempelt 2. Teil: Dominik Grollmann: Erfolgskonzept für Shop und MarketingSoftware?
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 ECommerceSysteme. Das Unternehmen wurde 1994 in Hamburg gegründet und entwickelt heute anspruchsvolle Softwarelösungen für B2B und B2CKunden. Bei der Entwicklung und Umsetzung von Onlineshops, Webapplikationen und BusinessIntelligenceLö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
ContentManagement System
facebook.com
instagram.com
Content Management System
http://www.ibusiness.de/members/intranet/db/756175grollmann.html
6/7