Zentrales Multisitemanagement mit dem TYPO3 CMS

Darstellung der Navigation innerhalb von TYPO3

Manchmal gibt es Anforderungen an ein Content Management System (CMS) welche lauten: Das System soll OpenSource sein, also frei von Lizenzkosten Das CMS soll in der Lage sein, mehrere eigenständige Webauftritte innerhalb einer Instanz zu verwalten Es muss möglich sein, … Weiterlesen

TYPO3 CMS: Neues in Version 6

Aufgeräumtes Benutzerbackend

Die aktuellste TYPO3 Version wurde Ende November 2012 veröffentlicht. Zeit, einen kurzen Blick auf die interessantesten Neuerungen zu werfen. Der Namen: Nach TYPO3 Version 4.7 kommt die Version 6.0? In der Tat, so ist es. Ich war ebenfalls ein wenig … Weiterlesen

A Study in … Viagra

Sherlock Holmes zum Zweiten. Der Blogpost von Jürg über gehackte TYPO3-Seiten hat viel Staub aufgewirbelt worauf mehrere SOS-Rufe von betroffenen Seitenbetreibern bei uns eingetroffen sind. Das Problem war, dass einige ältere TYPO3 Betreiber plötzlich unwissentlich potenz-steigernde Pharmazeutika verkauften. Seit wir auf dieses Problem aufmerksam geworden sind, stossen wir regelmässig auf neue Opfer des „Pharmahacks“. TYPO3 ist dabei übrigens bei weitem nicht das einzige geplagte System. Perfiderweise ist der Hack auf den ersten Blick nicht sichtbar – er wird nur wirksam, wenn der Surfer via Google auf die Seite stösst. Dann wird server-seitig neuer Text in die Webseite gerendert und beim Klick auf den Link von Google aus, gelangt der Kunde nicht auf die eigentliche Seite, sondern wird auf eine (meist russische) Seite weitergeleitet. Die verkauft Viagra – oder etwas anderes blaues.
Neulich erhielten ich erneut den Auftrag, den Verkauf blauer Pillen auf der Seite eines Dritten zu unterbinden. Diesmal wurde das Problem mit „Medikamentenhack“ beschrieben.

Hier folgt ein Bericht meiner Spurensuche in der Hoffnung, dass Anderen mit den selben „Krankheitssymptomen“ geholfen werden kann.
Als erstes habe ich mich auf dem System, im TYPO3 Backend und auf dem Server etwas umgesehen. Dabei handelte es sich nicht um eine „verwahrloste“ Webseite sondern um eine recht gut ausgebaute Plattform mit einem relativ aktuellen TYPO3 Core und einem sauberen Aufbau und umfangreicher Funktionalität. Ein eher grosser Auftritt.

Gefährliche Extensions

Auf Anhieb sind mir jedoch einige potenziell (sehr) gefährliche Extensions aufgefallen, die auf einem Live-System nichts verloren haben: „t3quixplorer“ – erlaubt die Navigation auf dem Filesystem mehr oder weniger uneingeschränkt und ermöglicht das Bearbeiten von PHP-Scripts direkt über das Webinterface – der reinste Security-Alptraum. Es ist nicht auszuschliessen, dass diese Extension von einem der Angreifer installiert wurde. „devlog“ ist eine Extension welche zu Entwicklungszeiten nützlich sein kann – jedoch nicht in einem Live-System. Ein anderer Kandidat, welcher jedoch nicht installiert war, ist die „phpmyadmin“ Extension, welche oft aus Bequemlichkeit installiert wird. Auch diese Extension stellt ein beträchtliches Sicherheitsrisiko dar. Im übrigen beinhaltete das System einige „handgemachte“ Extensions – schnell zu erkennen an fehlenden Icons und der aussagekräftigen Versionsnummer 0.0.0 – Stable? Ja genau!

Backend-User

Ich habe ausserdem alle Backend-User überprüft und mit dem Kunden zusammen sichergestellt, dass keine unbekannten Nutzer registriert waren. Sollte dies der Fall sein, würde ich empfehlen, alle User neu anzulegen und neue, sichere Passwörter zu vergeben.

Spurensuche im Dateisystem

Danach habe ich mich etwas vertieft auf die Spurensuche gemacht. Aus Erfahrung weiss ich mittlerweile, wonach ich suchen muss. Eine Suche im Filesystem nach „base64_decode(“ führt meist zu verdächtigen Code-Zeilen oder Dateien:

find . -name "*.php" -print | xargs grep "eval(base64_decode("

Meist sind infizierte Dateien im Ordner typo3conf/ zu finden. Darin befinden sich die von TYPO3 auszuführenden Extensions. Der Code darin kann potenziell schädlich sein.
Auf diese Weise bin ich auf zwei verdächtige Dateien gestossen. Eine Datei war in einer nicht öffentlichen, für Kundenbedürfnisse entwickelten Extension enthalten. Die andere im ./uploads/ Ordner der bekannten Newsletter-Extension tx_directmail.

./uploads/tx_directmail/trololo.php:<?php eval(base64_decode("ZXZhbChiYXNlNjRfZGVjb2RlKCJaWFpoYkNoaV
lYTmxOalJmWkdWamIyUmxLQ0phV0Zwb1lrTm9hVmxZVG14T2FsSm1Xa2RX
YW1JeVVteExRMHBoVjBad2IxbHJUbTloVm14WlZHMTRUMkZzU20x…

In beiden Fällen war es dem Angreifer möglich, über ein ungenügend geschütztes Formular PHP-Dateien auf das System zu laden. Geschieht dies, und sind diese Dateien auch ausführbar, hat man verloren.
Bei genauerem Hinsehen habe ich in der handgestrickten Extension gleich noch mehr zerstörerische Dateien gefunden welche die unscheinbaren Namen „class.php“ und „footer.php“ trugen. Ich musste erst beim Dienstleister des Kunden nachfragen, um sicher zu stellen, dass es sich wirklich um bösartige Dateien handelte. In diesen Fällen hatten die Angreifer ganze Arbeit geleistet – auch das Erstelldatum war ein weit zurückliegendes. Oft kann man im System auch einfach nach Files suchen, die im Zeitraum des Hacks verändert wurden. Ich konnte diesen durch verdächtige Files auf etwa 76 Tage zurückliegend vermuten und bin mit dem Befehl

find . -iname "*.cache" -mtime -77 -mtime +75 -type f

auf weitere verdächtige Dateien gestossen. Da im Ordner typo3conf während dem Betrieb eigentlich keine Dateien geändert werden sollten, sind dies zumindest dort, nur eine Hand voll. Mein Tipp: in typo3conf/ext/ darf auf einem Live-System gar nichts geändert werden können. Dem Server (Apache) sollen also alle Schreibrechte auf typo3conf/ext/ entzogen werden. Auch localconf.php darf nie verändert werden – damit wird es für einen Angreifer sehr schwer, nachträglich Extensions zu installieren, ohne dass er Serverzugriff hat.

Bereits erwähnte class.php war mehrfach base64 encoded und nachdem ich diese mehrfach decodiert hatte wurde ihr Zweck offensichtlich. Sie leitet die Benutzer welche von viagra-verseuchten Google-Resultaten kommen auf die russischen Verkaufsseiten weiter:

Ja ist denn heut‘ schon Weihnachten?

Bei der Analyse von ./uploads/tx_directmail/trololo.php wurde ich leicht überrascht. Ebenfalls nach mehrmaligem encoden kam folgendes zum Vorschein:


Ein ausgewachsenes Backdoor! Inklusive Passwortschutz. Klar russischen Ursprungs. Mit diesem Tool kann man auf einem Server so ziemlich alles machen. Dateien erstellen, löschen, bearbeiten, Rechte setzen. Damit kann man die localconf.php auslesen – dort steht (meist) der MySQL User und das Passwort im Klartext. Somit kann der Angreifer auch auf die Datenbank zugreifen. Doppelt dumm, wenn der gleiche User auf mehrere Datenbanken Zugriff hat. Wenn man localconf.php nicht schreibgeschützt hat, kann er ausserdem ein neues Install-Tool Passwort erstellen. Damit kann er sich dann einen Backend-Administrator erstellen – etwas einfacher als direkt über die DB. Netterweise nennt TYPO3 bei einer missglückten Anmeldung am Install-Tool auch gleich den dazu benötigten MD5 Hash den man dann nur noch im localconf.php eintragen braucht.
Das Backdoor in Action:

Und weiter geht’s…

Nachdem ich die Suche bereits abbrechen wollte – es war mittlerweile schon spät – bin ich im fileadmin/ in den Templates der Webseite auf eine weitere mysteriöse Datei gestossen – eine PHP Datei unter den CSS Files; en.php
Diese enthielt neben den verdächtigen base64 Codes auch noch folgenden aufschlussreichen Text:

Codz by angel(4ngel)
Make in China
Web: http://www.4ngel.net

Die Chinesen waren also auch am Werk! Nach erneut mehrmaligem Encodieren und Entfernen eines Passwortschutzes wurde offensichtlich, dass die Chinesen den Russen mittlerweile – zumindest im Design – voraus sind. Ebenfalls eine mächtige Hintertüre – einmal in schön.

Fazit, Suche, Massnahmen

Abschliessend konnten wir den Grossteil des Hacks wohl innerhalb einiger Stunden finden und entfernen. Nach dem der übliche Selbstheilungsprozess von Google eingesetzt hatte sind nun die Suchresultate wieder frei von Viagra. Für die Suche nach infizierten Files benutzen wir die Dateisystemsuche nach den Begriffen eval() und base64_decode(), Datumsangaben, verdächtige PHP-Dateien an unüblichen Orten – PHP-Files im uploads Ordner oder in andern Ordnern mit normalerweise statischen Inhalten. Auch eine Hilfe für das schnelle Finden von Schadcode kann sein, wenn die TYPO3 Temp-Files im typo3conf/ Ordner nach base64_decode durchsucht werden. Diese Dateien werden von Typo3 geladen und enthalten einen Zusammenzug vieler ausgeführter Dateien. Oft sieht man dort schnell, ob, und wo ungefähr, ein System vom „Pharmahack“ befallen ist. Handgemachte Extensions die nie den Weg ins TYPO3 Repository gefunden haben sind ein erhöhtes Sicherheitsrisiko. Alle Formulare mit Upload-Funktionalität sind ein möglicher Angriffspunkt. Auch in die Datenbank sollte man einen Blick werfen. Es kann sein, dass in den Tabellen von RealURL unerwünschte Weiterleitung enthalten sind. Auch in tt_content oder in der pages Tabelle kann nach Viagra gesucht werden. Ausserdem sollte man alle Cache-Tabellen leeren.

Die befallenen Dateien und Extensions werden gesäubert oder entfernt. Nicht (mehr) benötigte Extensions sollten vom System gelöscht werden – nicht nur deaktiviert! Unnötige Backend- und Frontend-User sollten ebenfalls gelöscht und die Passwörter sicherheitshalber angepasst werden.
Alle Schreibrechte für den Server sollten auf typo3conf/ext und auf der localconf.php entfernt werden. Dies gilt selbstverständlich auch für den ganzen TYPO3-Core. Sicherheitshinweise von TYPO3 sollten ernst genommen werden:

Das Install-Tool kann auf dem Live-System entfernt werden und der Zugriff auf das Backend nur für einen bestimmten IP-Range, vielleicht über eine spezielle Sub-Domain und zusätzlich mit einem .htaccess Schutz, versehen werden. Auch HTTPS für das Backend schadet kaum.
Natürlich sollte darauf geachtet werden, dass TYPO3 und verwendete Extensions auf einem aktuellen Stand sind. TYPO3 Bug-Fix Releases sollten wenn möglich immer installiert werden da diese Security-Fixes enthalten und normalerweise problemlos zu installieren sind.

Neuer Webauftritt der Schaffhauser Kantonalbank mit TYPO3

shkb-1

Für die Schaffhauser Kantonalbank durfte Namics den Webauftritt der shkb.ch von Grund auf neu konzipieren, gestalten und entwickeln. Die SHKB setzte dabei zur Realisierung ihrer öffentlichen Webseiten auf das Open Source Content Management System TYPO3. Weiterlesen

Ergebnis der CMS Evaluation, Showtime!

**Für mich kommt nun der spannendste Teil der CMS Evaluation, schliesslich haben in den vorangehenden Schritten Theorie, teilweise abstrakte Anforderungen und viele Zahlen in Bewertungstabellen das Bild geprägt.**

Das Bedürfnis nach einem neuen CMS, Workshops zur Erhebung von funktionalen, nicht-funktionalen und Business Anforderungen sowie die eigentliche Bewertung und Evaluation der CMS haben wir bereits in den vergangenen Posts behandelt. Nun haben wir eine Rangfolge von Produkten und deren Erfüllungsgrad der Kundenanforderungen.

Wie weiter?
Die Rangfolge der Systeme kann nun interpretiert und erklärt werden. Aufgrund der Standardabweichung in den Ergebnissen lassen sich die Ausreisser-Systeme identifizieren und die Stärken und Schwächen der einzelnen Produkte argumentieren.

2602-Ranking-thumb-500x329-2601.png

So kommen wir zu einer Short-Short-List von maximal drei Produkten, welche die Kundenanforderungen nahezu optimal erfüllen. Auf dieser Basis lassen sich nun durch uns und den Kunden TCO Berechnungen erstellen, was die Einführung des einzelnen CMS über 3 Jahre hinweg unter Annahme eines bestimmten Projektvolumens kostet. Hier kommen nun zum ersten Mal auch die Lizenzkosten der einzelnen Content Management Systeme ins Spiel. Das Bild der Short-Short-List kann sich also auch sehr schnell wieder ändern, falls Lizenzkosten schlussendlich den Ausschlag für oder gegen ein Produkt geben.

Nach der TCO Berechnung ist die Evaluation eigentlich abgeschlossen. Es gibt aber noch zwei Variablen, die wir bisher noch nicht näher berücksichtigt haben: Die Projektkomplexität und den Hersteller an sich.

Warum also nicht anhand eines konkreten Lastenhefts für das vorliegende Projekt den Hersteller sein Produkt präsentieren lassen? Und zwar auf Basis von konkreten (und möglicherweise komplexen) Anforderungen, welche später durch das gewählte CMS erfüllt werden müssen? So lernen sich unser Kunde und der Hersteller bereits kennen, und man erhält einen detaillierteren Einblick in das System. Und zwar auf Basis von echten Anforderungen.

Gerne möchte ich an dieser Stelle zur Diskussion auffordern: erkennt sich jemand anhand des gezeigten Vorgehens oder der gezeigten Situationen wieder? Wer steht vor der Entscheidung für ein neues Content Management System? Hat jemand diesen Prozess bereits durchgemacht und was waren die Erfahrungen?

Vielleicht können meine Kollegen und ich an der einen oder anderen Stelle in Zukunft bei konkreten Fragestellungen helfen!

Sie haben einen Teil unserer Serie ‚CMS Evaluation‘ verpasst? Hier finden Sie nochmals alle Beiträge dazu:

* Ein neues CMS?
* Business Requirements an ein CMS
* Funktionale und nicht-funktionale Requirements an ein CMS
* Bewertungs-Prozess einer CMS Evaluation

Opensource CMS: Drupal und TYPO3 – Ein Vergleich

Namics hat in der Vergangenheit im Opensource Content Management Umfeld verschiedene CMS Systeme wie TYPO3, Drupal, Magnolia sowie Webapplikationen mit dem Framework Ruby on Rails erfolgreich umgesetzt.

Bekanntester Vertreter im Opensource CMS Umfeld (LAMP Architektur) ist dabei oft TYPO3. Neuerdings erreichen uns aber auch vermehrt Anfragen für Drupal. Die Auswahl des „richtigen“ Systems ist eine Kernkompetenz von Namics und basiert auf einer Systemevaluation – in diesem Falle einer sogenannten CMS Evaluation. Auf eine genauere Erläuterung des Vorgehens verzichte ich in diesem Post explizit. Mein Ziel ist es, die Systeme Drupal und TYPO3 bezüglich 3 Punkten zu vergleichen. Eines vorneweg: Beides sind „vollwertige“, freiverfügbare Opensource Content Management Systeme.

1 Community Sites vs. Corporate Websites
TYPO3 wie auch Drupal verwalten im Kern Inhalte von Websites. Drupal fokussiert dabei klar auf Community-Sites, also überall dort wo User aktiv mit Kommentaren oder eigenen Beiträgen den Inhalt einer Website beeinflussen.

Bei TYPO3 handelt es sich im Gegensatz dazu um ein „klassisches CMS“. Speziell ausgelegt auf das Verwalten grösserer Corporate Websites (selbstverständlich auch denkbar für Intra- oder Extranets). Es bestehen umfangreiche Möglichkeiten, eine oder mehrere Sites zu verwalten. Am Beispiel des Energieproduzenten Repower sind „Sites“ als eigene Länderauftritte zu verstehen . Also jeweils 1 unabhängiger Seitenbaum für Schweiz (ch), Deutschland (de), Gruppe (group) und Mittel- und Osteuropa (cee):
repower.com/de/ch
repower.com/de/de
repower.com/de/group
repower.com/de/cee

In jedem Land können Inhalte beliebig verwaltet werden. Dies gilt natürlich auch für Sprachen und Funktionen.

2 Wo werden Inhalte erstellt und editiert? Frontend vs. Backend
Wie bereits erwähnt ist Drupal massgeschneidert für Community Sites, d.h. ein Grossteil des Inhalts entsteht in der Regel durch die User selber. Demnach gibt es eine Verschmelzung zwischen Front- und Backend, wie man dies von Community Sites wie Facebook und co. gewöhnt ist. Ein Backend sucht man bei Drupal in der Basisinstallation vergebens: Alles spielt sich im Frontend ab, was für einfache inhaltliche Anpassungen sehr angenehm ist. Backend Themes für Autoren können bei Bedarf installiert werden.

TYPO3 unterscheidet deutlich zwischen einem Front- und Backend. Autoren verwalten Inhalte zu einem grossen Teil direkt im Backend. Neuere TYPO3 Releases folgen dem Trend, Inhalte direkt auf der Seite, also im Frontend zu editieren.

3 Hierarchische Seiten vs. kategorisierter Inhalt
TYPO3 basiert auf Seiten (Pages) die in einer hierarchischen Strukur einen Seitenbaum (=Site) ergeben. Am Beispiel einer Versicherung wären dies beispielsweise einzelne Produktseiten. Hier am Beispiel Page „Hausrat-Versicherung“. Einzelne Pages können wiederum Seitenelemente wie z.B. eine Spalte für Teaser im rechten Randbereich umfassen. Ein Seitenbaum sieht in TYPO3 wie folgt aus:

2684-Typo3-backend-thumb-500x508-2683.jpg

Drupal fährt einen stark modularen Ansatz. Im Gegensatz zu TYPO3 kommen sogenannte Nodes zum Einsatz. Zurück zu unserem Beispiel der Versicherung: Für die Abbildung der Produktseite „Hausrat-Versicherung“ wird ein Node „Hausrat“ eingesetzt. In diesem Node sind relevante Informationen wie der Titel, Produktinformationen, Bilder, Preisinformationen etc. gespeichert. Nodes sind nicht hierarchisch angeordnet. Die Struktur ist flach resp. ergibt sich über die Kategorisierung einzelner Nodes, Eine Seitenbaumansicht gemäss TYPO3 gibt es demnach nicht, vielmehr werden Nodes über Filter kategorisiert (siehe Screenshot).

2681-Drupal_kategorisierung-thumb-500x358-2680.jpg

Im Kern geht es also darum,

> wer (User oder Autoren) hauptsächlich die Inhalte eines Webauftritts erstellt,
> wie oft Inhalte an verschiedenen Stellen wiederverwendet werden und natürlich
> welche Art von Webauftritt (Tendenz zu vielen Community Features oder Corporate Website mit weniger dynamischen Inhalten) realisiert werden soll?

Fahren Sie lieber Mercedes oder BMW?

Bewertungs-Prozess einer CMS Evaluation

**Der Prozess hinter einer CMS Evaluation klingt oftmals nach Voodoo und Willkür, vor allem wenn Zahlen und Bewertungen im Spiel sind. Da am Ende der Evaluation aber das für den Kunden individuell passende Content Management System stehen soll, beziehen wir unsere Kunden in den Bewertung-Prozess ein.**

Auf Basis der gemeinsam erhobenen Anforderungen und Bedürfnisse werden funktionale und nicht-funktionale Cluster der Anforderungen erstellt. Der Kunde nimmt nun aus Sicht seiner Stakeholder eine Bewertung der Anforderungen vor. Jede erhobene Anforderung wird dabei in drei Dimensionen bewertet.

2600-Kriterienbewertung-thumb-500x211-2599.png

Die tatsächliche Wichtigkeit der Anforderung beschreibt, wie hoch deren Stellenwert innerhalb der Evaluation ist. Beispielsweise kann die Integration eines Shop-Systems als business-kritisch bewertet werden, wenn dies den Zielen entspricht. Auf der anderen Seite kann visuelles Bearbeiten von Digital-Assets als ‚nice-to-have‘ in die Bewertung einfliessen, wenn dies entsprechend weniger wichtig erscheint.

Ein weiterer Schritt ist die Gewichtung der Anforderungs-Cluster. Dabei wird innerhalb der funktionalen, nicht-funktionalen und Business Anforderungen eine weitere Priorisierung festgelegt. Sollen Community-Funktionalitäten wie Benutzerprofile und User Generated Content bei der Produktwahl wichtig sein, wird dieser Cluster im Verhältnis zu den anderen Anforderungen sehr hoch bewertet.

Schlussendlich werden Soll- und Muss-Kriterien festgelegt, ohne deren Erfüllung ein CMS Produkt nicht die Endauswahl erreichen kann.

Auf Basis unserer Erfahrung aus vielen CMS Projekten und dem Knowhow unterschiedlichster Produkte bewerten wir die zur Evaluation stehenden Produkte im Hinblick auf die oben erwähnten Anforderungen. Um Unabhängigkeit und Objektivität sicherstellen zu können, wird diese Bewertung unter Leitung eines Namics Consultant und Hinzunahme von Namics Produkt-Spezialisten vorgenommen. Der Hersteller bleibt hier absichtlich aussen vor. Die Bewertungen erstrecken sich von ‚nicht realisierbar‘, über ‚mit Aufwand machbar‘, ‚out-of-the-Box‘ bis hin zu ‚ausgewiesene Produktstärke‘. Wichtig ist uns, dass die Bewertungen durch ein und dieselbe Person durchgeführt werden, da die Auslegung des Erfüllungsgrades einzelner Anforderungen nie komplett objektiv erfolgen kann.

Welche Content Management Systeme werden überhaupt evaluiert und bewertet? Grundsätzlich nur solche, die wir kennen und unseren Kunden Mehrwert bieten. Und natürlich sollten bereits grundlegende, nicht-funktionale Anforderungen erfüllt werden. Doch schlussendlich bestimmt der Kunde, wie sich die zu evaluierende Produkte-Longlist bei der CMS Evaluation überhaupt zusammenstellt. Und oft ist das Spektrum wesentlich breiter, als zunächst angenommen.

Verpasst, was es sich mit den ganzen Anforderungen auf sich hat? Hier der Rest unserer Serie zur CMS Evaluation:

* Ein neues CMS?
* Business Requirements an ein CMS
* Funktionale und nicht-funktionale Requirements an ein CMS

Funktionale und nicht-funktionale Requirements an ein CMS

Heute geht es weiter mit unserer Serie ‚CMS Evaluation‘. Was sind eigentlich funktionale und nicht-funktionale Requirements? Und wie wirken sie sich auf die Evaluation eines CMS aus?

Im letzten Post haben wir die Business Requirements beschrieben und die Bereiche funktionale und nicht-funktionale Anforderungen angesprochen. Funktionale Anforderungen sind allgemein die Funktionalitäten eines CMS, die für die Benutzer sichtbare Elemente beschreiben. Nicht-funktionale Anforderungen beschreiben die Rahmenbedingungen eines CMS, welche über die funktionalen Anforderungen hinaus erfüllt werden müssen.

Nicht-funktionale Anforderungen
So ordnen wir folgende Bedingungen den nicht-funktionalen Anforderungen zu:

* Was ist die Kunden-Strategie hinsichtlich Technologie (z.B. Microsoft- oder Java-Technologie)?
* Welche Betriebssysteme, Applikationsserver oder Datenbank-Systeme werden vom CMS unterstützt?
* Wie erweiterbar soll das Produkt sein (z.B. Umsetzung beliebig vieler Mandanten)?
* Welche Schnittstellen zu Umsystemen soll das neue CMS unterstützen?
* Welche Ansprüche werden an Wartungsintervalle oder die Zuverlässigkeit gestellt?
* Welche Anforderungen werden an die Bedienbarkeit und Administration gestellt?
* Wie werden Digital Assets (z.B. Bilder, Filme, Dokumente) vom CMS behandelt?

In der Praxis müssen die oben genannten Fragen natürlich den richtigen Personen im Unternehmen gestellt werden. In erster Linie sollen die grössenteils IT-lastigen Requirements von den IT Verantwortlichen des Kunden identifiziert und zusammen mit Namics eingestuft werden.

Funktionale Anforderungen
Der Enduser hingegen (beispielsweise Editoren, Redaktoren oder Administratoren) haben komplett andere Anforderungen an das CMS als die IT. Natürlich holen wir auch deren Anforderungen und Wünsche an das Content Management System ab. Viele der nachfolgend genannten Anforderungen klingen vielleicht banal, können aber bei der nachfolgenden Bewertung grossen Einfluss auf das Ergebnis haben:

* Wird auf Basis von Templates gearbeitet, wie granular ist die Strukturierung der Inhalte?
* Kann auf Inhalts- und Navigationselemente out-of-the-box zurückgegriffen werden?
* Wie flexibel ist die Seiten- und Inhaltsgestaltung für die Editoren mit dem CMS?
* Werden Workflows unterstützt, wie komplex können diese sein und wie sind sie administrierbar?
* Stehen ‚Web 2.0′ Funktionalitäten zur Verfügung?
* Können Inhalte über mehrere Mandanten automatisiert verteilt oder zumindest vererbt werden?

2584-1423599488_62e49ead92-thumb-500x333-2583.jpg

Bild: CannedTuna

Am allerliebsten frage ich meine Kunden in den gemeinsamen Meetings aber das Folgende:

Ich: Wie gehen Sie eigentlich mit Lastspitzen um? Zum Beispiel wenn Quartalszahlen oder der Geschäftsbericht veröffentlicht werden?

Business Nutzer: Da kümmert sich unsere IT drum!
IT CMS-Verantwortlicher: Wir halten für solche Fälle extra Hardware vor, diese schalten wir vor der Veröffentlichung des Geschäftsberichts jeweils auf…
Business Nutzer: Bei der letzten Social Media Kampagne hatten wir trotzdem einen Ausfall von mindestens vier Stunden, die Kampagnen-Landingpage war nicht erreichbar!

Ich: Haben Sie schon einmal darüber nachgedacht, zumindest einen Teil des CMS z.B. zu Amazon auszulagern oder mit einem Content Delivery Network zu arbeiten?

Auch dieses oder ähnliche Szenarien sind nicht selten und der Markt bietet heute Produkte, Lösungen und Referenzen, welche diese Fragestellungen mit Bravour lösen und beantworten.

Kommen diese Statements über neue CMS bzw. deren Evaluation dem einen oder anderen bekannt vor?

Zum Weiterlesen:

* Ein neues CMS?
* Business Requirements an ein CMS

Business Requirements an ein CMS

Heute fokussiere ich mich auf das Thema Business Requirements im Kontext von Systemevaluationen. Dabei sind die Erkenntnisse grundsätzlich unabhängig von der Art des Systems, sprich ob es sich dabei um ein Web Content Management System, ein Intranet- oder ein Collaboration-System handelt. Was genau verstehen unsere Kunden und wir unter Business Requirements? Welche besonderen Eigenschaften weisen diese auf? Wie können sie am einfachsten erhoben, respektive wie lassen sich diese zusammen mit anderen Anforderungen bewerten und interpretieren?

Was sind Business Requirements?
Neben den funktionalen Requirements (z.B. bietet das System Downloadcenter-Funktionalitäten?) und nicht-funktionale Requirements (z.B. lässt sich das System in einem LAMP-Stack betreiben?), die typischerweise direkt von den Systembetreibern und Systembenutzern gefordert werden, stellen die Business Requirements Anforderungen dar, die von verschiedenen Business-Stakeholdergruppen ausgehen. Diese Stakeholder stammen typischerweise aus unterschiedlichen Unternehmensbereichen wie zum Beispiel Geschäftsleitung, Marketing, Kommunikation, IT, HR oder dem Einkauf und sind im Rahmen einer umfassenden Evaluation ein fester Bestandteil des Requirement-Katalogs. Dieser setzt sich somit aus den folgenden Anforderungsarten zusammen:

* Funktionale Requirements
* Nicht-funktionale Requirements
* Business Requirements

2518-CMS_Evaluation_Requirements-thumb-500x287-2517.png

Aus Überlegungen und Fragestellungen wie zum Beispiel Lock-in Risiken, Produktmarktanteile, Entwickler-Arbeitsmarktsituation, Distributoren- und Implementierungspartnerdichte werden die Business Requirements abgeleitet und anschliessend priorisiert und bewertet.
Typischerweise werden im Rahmen einer Evaluation alle Requirements gruppiert. Dabei trifft man im Bereich der Business Requirements immer wieder auf die folgenden Anforderungsgruppen:

* Allgemeine Marktanforderungen, z.B. Verbreitungsgrad in der Branche XY > 50%
* Hersteller, Produkt & Support Anforderungen, z.B. Verfügbarkeit von Schulungsangeboten
* Implementierungspartner bezogene Anforderungen, z.B. Anzahl und Grösse der Partner in der Schweiz
* Personalanforderungen, z.B. Existenz eines Arbeitsmarkts für Entwickler mit Knowhow in XY
* Kostenanforderungen, z.B. für Lizenzen, Implementierung, Infrastruktur, Wartung & Betrieb, etc.

Wie werden Business Requirements erhoben?
Business Requirements werden wie die anderen Anforderungen am einfachsten direkt mit den Stakeholdern zusammen erhoben. In einem ersten Schritt gilt es diese Anspruchsgruppen zu identifizieren und zu bestimmen, um im zweiten Schritt mit ihnen zusammen die Anforderungen zu erarbeiten. Je nach Organisationsform, -grösse oder Präferenz können dafür verschiedene Methoden eingesetzt werden wie zum Beispiel geführte Interviews oder Workshops.
Nachdem die Anforderungen aller Stakeholder in einer Rohform vorliegen, müssen diese in priorisier- und bewertbare Anforderungen überführt werden. Diese Transformation ist für Business Requirements häufig schwieriger vorzunehmen als beispielsweise für funktionale Anforderungen, welche sich per se einfacher in eine Form bringen lassen, in welcher man sie sinnvoll bewerten kann.
So kann aus einer vermeintlich einfachen Aussage eines HR-Managers ein ganzer Strauss an Business Requirements abgeleitet werden (fiktives Beispiel):

„Deutschsprachige erfahrene Entwickler muss ich binnen 2-3 Wochen rekrutieren können.“

Daraus ableitbare Business Requirements sind zum Beispiel:

* Es existieren bewährte Plattformen zur raschen und einfachen Personalrekrutierung
* Auf dem betroffenen Arbeitsmarkt sind genügend Personalressourcen verfügbar
* Freelance-Personalressourcen sind neben anderen Ressourcen verfügbar
* Der Arbeitsmarkt ist in den Ländern Schweiz, Deutschland oder Österreich existent
* Der Hersteller bietet Zertifizierungsmöglichkeiten

Alle Requirements der Business-Stakeholder werden neben den anderen Anforderungsarten in einem sogenannten Evaluationsraster zusammengetragen und nachfolgend gruppiert. Eine Vermengung der auf diesem Weg erhobenen Requirements mit aus anderen, bereits bekannter Anforderungen, stellt eine gängige Praxis dar, um aus der bereits vorhandenen Evaluationserfahrung zu profitieren.

Teil 1 unserer Post-Serie, ‚Ein neues CMS?‚, führt in die Thematik CMS-Evaluation ein.

Zum Weiterlesen:

* Ein neues CMS?
* Funktionale und nicht-funktionale Requirements an ein CMS

Ein neues CMS?

Der nachfolgende Dialog ist frei erfunden. Ähnlichkeiten zu realen Personen und Situationen sind rein zufällig…

Produkt Marketing: Wir benötigen mehr Flexibilität zur Darstellung unserer Produkte auf der Webseite.

CMS Plattform Owner: Was genau meinst du mit mehr Flexibilität?

PM: Wir wollen unseren Besuchern ermöglichen, zu einzelnen Angeboten Kommentare und Ratings zu hinterlassen. Und es soll möglich sein, unsere Produkte bei Facebook zu ‚liken’!

CMS PO: Sind diese Funktionen wichtiger als die Produkt-Videos, von denen du mir letzte Woche erzählt hast? Und auch das Suchmaschinen-Package?

PM: Wir brauchen das alles ganz schnell, und wir brauchen ein flexibles Template um unsere Microsite Landing-Page umsetzen zu können…

CMS PO: …?!?

Content Management Systeme (CMS) zur Pflege von Webseiten sind einem Lebenszyklus unterstellt. Daher dürfte diese Konversation zwischen Marketing und IT bereits schon einmal so oder so ähnlich stattgefunden haben. Ich habe sie genau genommen schon des Öfteren erlebt.

Jedoch muss es nicht unbedingt nur die mangelnde Flexibilität eines Systems sein, dass Anforderungen von Marketing oder Business an das CMS nicht mehr Folge geleistet werden kann. Oft fällt mangelnde Flexibilität direkt auf das eingesetzte Poduktes bzw. die Version zurück. Starre Seiten- und Inhaltsstrukturen erlauben wenig Freiraum bei der Gestaltung von Inhalten. Und die starren Strukturen machen eine Weiterentwicklung oft kostspielig und aufwändig, um das geforderte Ergebnis zu erreichen.

Zeitgemässe Funktionen sind gefordert
Wenn wir heute im privaten Umfeld das Internet nutzen werden wir mit den neuesten Technologien konfrontiert. Zum Beispiel findet man vielfach anspruchsvolle Benutzeroberflächen mit In-Place Editing sowie Drag&Drop Anwendungsfällen, welche Abläufe vereinfachen und schneller gestalten. Oft stellt sich einem dann die Frage, weshalb diese Technologien nicht auch im geschäftlichen Umfeld für die tägliche Arbeit eingesetzt werden können.

Technische Rahmenbedingungen haben sich verändert
IT-seitig stehen oft grundlegendere Fragestellungen im Raum: die bestehende Lösung wurde vor vielen Jahren implementiert und hat mehrere Releasewechsel mitgemacht, ist veraltet und funktional nicht mehr aktuell. Das Produkt wird möglicherweise eingestellt, wird nicht mehr weiterentwickelt oder die Unterhaltskosten sind mittlerweile unverhältnismässig hoch. Möglicherweise sieht man sich mit einer geänderten Unternehmens-Startegie konfrontiert, die andere Technologien fordert. Um Kundenbedürfnissen gerecht zu werden, sollen Umsysteme in die Content Management Lösung integriert werden. Immer häufiger ist das bestehende System Lastspitzen ausgesetzt, die nur durch das Vorhalten von zusätzlicher (teurer) Hardware bedient werden können, und das in Zeiten von Cloud Computing?

Eines ist sicher: der Markt für Content Management Systeme ist fragmentiert und unübersichtlich. Anhand von Anforderungen an eine Content Management Lösung und die Bewertung der daraus abgeleiteten Anwendungsfällen kann die Vielzahl von Systemen mit unterschiedlichsten Merkmalen im Markt bewertet und aussagekräftige Vergleiche gezogen werden.

Und da mir solche Situationen in der Praxis schon oft begegnet sind, teile ich hier meine Erfahrungen in einer kleinen Serie. Das war der Auftakt, weitere Informationen zum Thema stehen parat.

Zum Weiterlesen:

* Business Requirements an ein CMS
* Funktionale und nicht-funktionale Requirements an ein CMS