Herauszufinden, wie Kunden auf welchen Kanälen auf Marketingkampagnen reagieren, ist nicht trivial. Noch komplizierter ist es zu ermitteln, wie eine bestimmte Kampagne verändert werden muss, damit positive Reaktionen entstehen. Doch Marketing-Verantwortliche wollen noch mehr. Sie wollen auch wissen, welche Kunden wie auf Kampagnen reagieren und wann sich positives Feedback in Umsatz niederschlägt. Ohne Big Data Analytics lassen sich solche Fragen nicht zweifelsfrei beantworten.

Das Cross Business Architecture Lab (CBA Lab, früher bekannt als SOA Innovation Lab) hat ein Framework entwickelt, das Anwendern helfen soll, Big-Data-Projekte richtig aufzusetzen. Es orientiert sich einerseits an der Richtung - also am Produkt, Kunden oder der eigenen Organisation - und andererseits am Ziel. Ein Ziel kann es sein, ein Produkt zu personalisieren, den Kunden besser zu verstehen oder die Effizienz der eigenen Organisation zu verbessern. Im hier beschriebenen Szenario geht es zunächst darum, den Kunden besser zu bedienen, aber auch, das eigene Marketing effizienter aufzustellen. In beiderlei Hinsicht soll die Big-Data-Lösung Vorteile bringen. Das Framework hilft etwa dabei herauszufinden, welche Datenquellen angezapft, welche Schnittstellen geschrieben und wie die später eingesetzten Visualisierungstools gestaltet werden müssen, mit denen die Analyseergebnisse den Beteiligten präsentiert werden.

Hier können COMPUTERWOCHE-Leser den kostenlosen Big Data Guide downloaden!

Ob eine neue Big-Data-Anwendung erfolgreich eingeführt werden kann, hängt stark davon ab, ob die Entscheider die diesbezüglichen Fähigkeiten (Capabilities) ihres Unternehmens realistisch beurteilen. Fällt die Bewertung des vorhandenen Know-hows zu optimistisch aus, kann sich die Umsetzung eines Projekts stark verzögern. Dann kann es passieren, dass im Verlaufe des Projekts spontan Know-how zugekauft werden muss oder nachträglich Fehler zu beseitigen sind. Das CBA Lab spricht vom Big-Data-Reifegrad (siehe Grafik).

Reifegrad Modell für Big Data

Der Reifegrad bezieht sich auf die fünf Themenbereiche Strategie & Roadmap, Governance, Referenzarchitektur, Infrastruktur sowie Development, Testing und Maintenance. Diese Kategorien werden in die fünf Reifestufen Ad-hoc, Repeatable, Defined, Managed und Optimized unterteilt. Alexander Hildenbrand ist im CBA Lab Leiter der Arbeitsgruppe Industrial Analytics, in der der Big Data Guide entwickelt wurde. Er erklärt das Capability-Modell wie folgt: "Wenn eine Organisation der Meinung ist, dass ihre Big-Data-Strategie voll entwickelt ist, aber in Wahrheit erst damit beginnt, eine Strategie zu formulieren, ergeben sich in der Folge große Schwierigkeiten. So kann weder bewertet werden, ob einzelne Anwendungsfälle zur Strategie passen, noch ob die eingesetzte Technologie der Roadmap, der Architektur und den Unternehmenszielen entspricht. Das führt bestenfalls zu Fehleinschätzungen und Doppelarbeit, schlimmstenfalls zum Abbruch der Projekte."

Bevor ein Use Case umgesetzt werden kann, muss die bestehende IT-Landschaft auf ihre Eignung dafür überprüft werden. Das beginnt beim Infrastruktur-Stack und reicht über die Betrachtung der Prozesse, Applikationen und Interfaces bis hin zur Infrastruktur für Entwicklung. Darüber hinaus ist es nötig, die vorhandenen Skills in der IT-Abteilung zu bewerten sowie Verantwortlichkeiten festzulegen. Hildenbrand ist überzeugt: "Bei allen Big-Data-Projekten liegt der größte Aufwand im Erstellen des Datenmodells und dem Aufbereiten der Daten. Ohne dieses Modell können die Algorithmen nicht arbeiten."

Dieser "Eignungstest" basiert auf dem Big Data Capability Model des CBA Lab (siehe Grafik). Es weist sieben Schichten auf, die von Datenquelle über Datenzugang bis hin zu Business-Szenarien reichen und sich auf fünf betroffene IT-Bereiche beziehen. Diese reichen von System-Management & Operation über Data Governance, Data Security bis hin zur Big-Data-Integration.

Data Source bezieht sich auf alle möglichen Datentypen, strukturiert bis unstrukturiert, intern oder extern. Für den Use Case Kampagnenanalyse müssen die Beteiligen beantworten, welche Datenquellen ihnen zur Verfügung stehen und inwieweit sie in der Lage sind, diese für die vorgesehene Analyse zu verarbeiten. Social Media sind in diesem Zusammenhang zum Beispiel eine zunehmend wichtige Quelle. Dabei handelt es sich in der Regel um unstrukturierte Daten, die anders gehandhabt werden müssen als strukturierte, die aus einer internen relationalen Datenbank stammen. Daraus leitet sich die Frage nach der Speicherung dieser Daten ab. Sind die entsprechenden Speicher- und File-Systeme für das Unternehmen verfügbar? Welche Systeme fehlen noch, um die Daten "artgerecht" zu speichern? Welche Konsequenzen ergeben sich aus der Datenhaltung für angrenzende Systeme, für die Data Governance, Security und das System-Management?

Die nächste durchzuspielende Frage ist die nach dem Datenzugriff. Im Batch-Verfahren sind die Abläufe und Anforderungen natürlich ganz andere als bei Streaming oder Continuous Event Processing. Selbstverständlich werden verschiedene Prozesse und Applikationen mit unterschiedlichen Mechanismen auf die Daten zugreifen. Also müssen sich die Betreiber entscheiden, welche und wie viele verschiedene Data-Access-Möglichkeiten sie zulassen wollen. Auch das hat wieder Konsequenzen auf die IT-Landschaft und das benötigte Skillset der IT-Mannschaft.

Solche Fragestellungen und Bewertungen setzen sich auf den weiteren Ebenen des Models wie Analysetechniken, Aufbereitung und Business Senzarios fort. "Es ist immer ein Spiel mit mehreren Dimensionen", erklärt Hildenbrand. "Unser Capability Model gibt die notwendige Struktur und die richtigen Denkanstöße für diesen Prozess." In diesem Zusammenhang betont Hildenbrand, dass Big Data für das CBA Lab in erster Linie Datenhaltung und -zugriff bedeutet. Die Auswertungen sehen die Verantwortlichen im Bereich von Analytics angesiedelt.

Referenzarchitektur für Big Data

Nachdem die Verantwortlichen geklärt haben, welche Capabilities sie brauchen und welche davon noch aufgebaut werden müssen, istdas Schaffen einer Big-Data-Referenzarchitektur der nächste Schritt. Deren Ziel ist die Verbesserung der Kommunikation unter den Betroffenen, in dem sie einen visuellen Überblick verschafft und eine gemeinsame Terminologie etabliert. Die Referenzarchitektur legt fest:

• Technologie-Entscheidungen

• Produkt-Entscheidungen

• Security-Prinzipien

• Regeln für die Datenintegration

• Verantwortlichkeiten und Gremien

• Steuerungskreis und Prozesse

Sie sollte Abhängigkeiten von anderen benutzten Referenzarchitekturen berücksichtigen. Beispielsweise dürfte eine vorhandene Cloud-Architektur die zu entwickelnde Big-Data-Architektur auf der Infrastrukturseite deutlich beeinflussen. Um eine solche Referenzarchitektur zu entwickeln, hilft eine Checkliste, auf der folgende Fragen nicht fehlen sollten:

• Soll eine dezentrale oder eine zentrale Big-Data-Instanz geschaffen werden?

• Wie sollen die Daten verwaltet werden? In einem Data Lake, einem Datensilo etc.?

• Verfügbarkeit von Big-Data-Services für welche Nutzergruppen?

• Art und Menge der Daten-Inferfaces zu den Datenquellen?

• Wie viele Nutzer sind geplant?

• Welche Lizenzen werden benötigt?

• Was soll gekauft, was selbst entwickelt werden?

• Wie hoch dürfen die Lifecycle-Kosten sein? Wie lassen sie sich ermitteln?

Fünf Dimensionen und 13 Module

Insgesamt besteht der How-to-Guide für Big Data und Analytics des CBA Lab aus fünf Dimensionen und 13 Modulen. Die Dimensionen umfassen die Bereiche Strategie, Technologie, IT-Prozesse und Policies sowie Security und Compliance. Jede ist unterteilt in Module, die als Arbeitspakete verstanden werden können.

"Strategie" besteht aus den Modulen...

• Alignment: Gemeinsame Entwicklung der (Big Data) Strategie mit der Business-Seite, um Kundenerwartungen und -verhalten besser zu verstehen und zu nutzen. Ein erster Schritt in diese Richtung ist der Aufbau eines crossfunktionalen Teams aus Data-Subject-Matter-Experten, die herausfinden, welche gemeinsamen Anforderungen die verschiedenen Abteilungen an Daten stellen und welche der Requirements abteilungsspezifisch sind.

• Uses Cases und Datenidentifizierung: Identifizierung und Priorisierung passender Use Cases und die Entwicklung von Big-Data-Szenarien aus technischer und wirtschaftlicher Perspektive.

• Capabilities und Maturity: Hier stellen sich Fragen nach den für Big Data/Advanced Analytics benötigten und vorhandenen Fähigkeiten.

• Strategie und Roadmap: Entwickeln von Strategie und Umsetzungsplan

"Technology" besteht aus den Schritten...

• Entwickeln einer Referenzarchitektur, ohne die Big Data nicht funktioniert. Verschiedene Anwendungsfälle können unterschiedliche Architekturen bedingen. Es kann daher eine grobe Referenzarchitektur geben, die konkreten Ausprägungen können jedoch architektonisch unterschiedlich sein.

• Aufbau der nötigen Plattform und Infrastruktur: Technologie (Hardware, Software, Tools) für den Betrieb der Big-Data-Analysen.

• Aufbau der Big-Data-Entwicklungsumgebungen und des dazu gehörigen Know-hows.

Die Dimension "IT-Processes und Policies" besteht aus...

• Entwickeln eines Data Governance Modells,

• Entwickeln von Big-Data-Entwicklungsprozessen und ihrer Steuerung,

• Entwickeln eines Big-Data-Betriebsmodells,

• Entwickeln eins Big-Data-Support-Prozesses.

Zur Dimension "Security and Compliance" zählen die Schritte...

• Bewerten zusätzlicher Risiken und Auswirkungen,

• Überprüfen der rechtlichen Verpflichtungen und der vertraglichen Stati.

"Natürlich muss auch bewertet werden, welcher Use Case den größten Nutzen für Unternehmen und Kunden aufweist. Daran bemisst sich der Aufwand", erklärt Hildenbrand. Dazu eigenen sich verschiedene Bewertungsverfahren. Allerdings, so Hildenbrand weiter, lässt sich nicht immer ein eindeutiger Business Case rechnen.

"Big Data braucht einen Vertrauensvorschuss. Wir können zwar gut voraussagen, dass die Analyseergebnisse zusätzliche Erkenntnisse bringen, aber rechnen wird sich das für ein Unternehmen erst dann, wenn die Erkenntnisse zum Beispiel in Vertrieb und Marketing oder in anderen Fachabteilungen sinnvoll verwendet werden und entweder den Umsatz steigern, Kosten senken oder eine kürzere Time-to-Market ermöglichen." Hildenbrand weist darauf hin, dass die Module nicht sequenziell bearbeitet werden müssen. "Es kann zum Beispiel hilfreich sein, erste Erfahrungen zu sammeln, bevor man eine Strategie definiert."